/
Author: Мацяшек Л.А.
Tags: компьютерные технологии программное обеспечение информационные системы компьютерное моделирование
ISBN: 5-8459-0276-2
Year: 2002
Text
Анализ требований
и проектирование
систем
Разработка информационных
систем с использованием UML
Requirements
Analysis and System
Design
Developing Information Systems
with UML
LESZEK A. MACIASZEK
Macguarie University, Sydney, Australia
Addison-Wesley
An imprint of Pearson Education
Harlow, England London New York Reading, Massachusetts San Francisco Toronto Don Mills, Ontario Sydney
Tokyo Singapore Hong Kong Seoul Taipei - Cape Town - Madrid Mexico City Amsterdam Munich - Pans - Milan
Анализ требований
и проектирование
систем
Разработка информационных
систем с использованием UML
Лешек А. Мацяшек
Маккуарийский университет, Сидней, Австралия
Издательский дом “Вильямс”
Москва ♦ Санкт-Петербург ♦ Киев
2002
ББК 32.973.264)18.2.75
М36
УДК 681.3.07
Издательский дом “Вильямс”
Перевод с английского и редакция канд.техн.наук В.М. Неумоина
По общим вопросам обращайтесь в Издательский дом “Вильямс”
по адресу: info@williamspublishing.com, http://www.winiamspublishing.coni
Мацяшек, Лешек, А.
М36 Анализ требований и проектирование систем. Разработка информационных
систем с использованием UML. : Пер. с англ. — М. : Издательский дом “Вильямс".
2002- — 432 с.: ил. — Парал. тит. англ.
ISBN 5-8459-0276-2 (рус.)
В книге описывается методология и технология объектно-ориентированной разра-
ботки современных информационных систем (ИС) и предлагается итеративный подход к
разработке ИС с пошаговым наращиванием их возможностей. Весь комплекс вопросов
анализа и проектирования ИС рассматривается в контексте использования языка UML как
универсального средства моделирования проектных решений. Изложение ведется в соот
ветствии с подходом, который можно назвать “обучением на примерах”. Приведенные в
книге примеры тщательно анализируются применительно к каждому из этапов создания
ИС; доходчиво и убедительно демонстрируется путь преобразования неформальных тре-
бований заказчика в артефакты языка UML. Отличительной чертой книги является г.ц>
моничное сочетание практического акцента в объяснении материала с глубоким проник
новением в его теоретическую суть. Книга написана с позиций реального опыта.
Книга предназначена для разработчиков ИС, кроме того, она может служить о<
новой фундаментального курса обучения методам проектирования ИС и использова
ния языка UML.
ББК 32.973.26-018.2.75
Все названия программных продуктов являются зарегистрированными торговыми марками со
ответствующнх фирм.
Никакая часть настоящего издания ни в каких целях не может быть воспроизведена в какой бы то
ни было форме и какими бы то ни было средствами, будь то электронные или механические, включая
фотокопирование и запись на магнитный носитель, если на это нет письменного разрешения издатель
ства Addison-Wesley Publishing Company, Inc.
Authorized translation from the English language edition published by Pearson Education Linulcd.
Copyright © 2001
All rights reserved. No part of this book may be reproduced, stored in retrieval system or transmined
in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without eithet
the prior written permission о the Publisher.
Russian language edition published by Williams Publishing House according to the Agieeineiii with
R&I Enterprises International, Copyright © 2002
ISBN 5-8459-0276-2 (рус.) © Издательский дом “Вильямс”, 2002
ISBN 0-20170944-9 (англ.) © Pearson Education Limited, 2001
Оглавление
Предисловие 14
Диаграммы деятельности для книги 21
1 Процесс разработки программного обеспечения 30
2 Основания анализа требований 61
3 Установление требований 115
4 Спецификация требований 142
5 Углубленный анализ 192
6 Основания проектирования систем 234
7 Проектирование пользовательского интерфейса 283
8 Проектирование баз данных 315
9 Проектирование программ и транзакций 361
10 Тестирование и управление изменениями 390
Литература 412
Предметный указатель 417
Содержание
Предисловие 14
Краткое содержание книги 14
Отличительные особенности книги 15
Для кого предназначена эта книга 16
Структура книги 17
Вспомогательные материалы 18
Благодарности 19
Диаграммы деятельности для книги 21
Internet-магазин (наставление) 22
Запись на университетские курсы (разбор примера) 24
Магазин видеопроката (разбор примера) 26
Управление контактами с клиентами (разбор примера) 27
Телемаркетинг (разбор примера) 29
Глава 1. Процесс разработки программного обеспечения 30
1.1. Характер процесса разработки ПО 30
1.1.1. Инвариант разработки ПО 31
1.1.2. Участники проекта 32
1.1.3. Процесс 34
1.1.4. Язык и средства моделирования 37
1.2. Планирование разработки системы 39
1.2.1. Подход SWOT 40
1.2.2. Подход VCM 41
1.2.3. Подход BPR 42
1.2.4. Подход ISA 43
1.2.5. Системы для трех уровней управления 44
1.3. Этапы жизненного цикла программного обеспечения 46
1.3.1. Этап установления требований 47
1.3.2. Этап спецификации требований 48
1.3.3. Этап проектирования архитектуры 48
1.3.4. Этап детализированного проектирования 49
1.3.5. Этап реализации 50
1.3.6. Этап интеграции 50
1.3.7. Этап сопровождения 51
1.3.8. Планирование проекта в течение жизненного цикла ПО 52
1.3.9. Измерения в течение жизненного цикла ПО 53
1.3.10. Тестирование в течение жизненного цикла ПО t 54
Содержание 7
1.4. Подходы к разработке программного обеспечения 55
1.4.1. Структурный подход 56
1.4.2. Объектно-ориентированный подход 57
Резюме 59
Вопросы 60
Глава 2. Основания анализа требований 61
2.1. Основы объектной технологии 61
2.1.1. Объект-экземпляр 62
2.1.2. Класс 67
2.1.3. Ассоциации 70
2.1.4. Агрегация и композиция 74
2.1.5. Обобщение 75
2.1.6. Объект-класс 79
2.2. Наставление по моделированию анализа 80
2.2.1. Internet-магазин 80
2.2.2. Моделирование прецедентов 81
2.2.3. Моделирование видов деятельности 87
2.2.4. Моделирование классов 91
2.2.5. Моделирование взаимодействий 98
2.2.6. Моделирование состояний 104
2-3. Постановки задач для исследуемых примеров 108
2.3.1. Запись на университетские курсы 108
2.3.2. Магазин видеопроката 109
2.3.3. Управление контактами с клиентами ПО
2.3.4. Телемаркетинг 111
Резюме 111
Вопросы 112
Упражнения 113
Глава 3. Установление требований 115
3.1. Принципы установления требований 115
3.2. Выявление требований 116
3.2.1. Традиционные методы выявления требований 117
3.2.2. Современные методы выявления требований 120
3.3. Согласование и проверка обоснованности требований 123
3.3.1. Требования, выходящие за рамки проекта 124
3.3.2. Матрица зависимости требований 124
3.3.3. Риски и приоритеты требований 125
3.4. Управление требованиями 126
3.4.1. Идентификация и классификация требований 126
3.4.2. Иерархии требований 127
8
Содержание
3.4.3. Управление изменениями 3.4.4. Прослеживаемость требований 3.5. Бизнес-модель требований 3.5.1. Модель рамок системы 3.5.2. Модель бизнес-прецедентов 3.5.3. Модель бизнес-классов 3.6. Документ описания требований 3.6.1. Шаблоны документа 3.6.2. Предварительные замечания к проекту 3.6.3. Системные сервисы 3.6.4. Системные ограничения 3.6.5. Проектные вопросы 3.6.6. Приложения Резюме Вопросы Упражнения Глава 4. Спецификация требований 4.1. Принципы спецификации требований 4.2. Спецификации состояний 4.2.1. Моделирование классов 4.2.2. Моделирование ассоциаций 4.2.3. Моделирование отношений агрегации и композиции 4.2.4. Моделирование отношений обобщения 4.2.5. Моделирование объектов 4.3. Спецификация поведения 4.3.1. Моделирование прецедентов 4.3.2. Моделирование видов деятельности 4.3.3. Моделирование взаимодействий 4.3.4. Моделирование открытых интерфейсов 4.4. Спецификация изменения состояний 4.4.1. Моделирование состояний объектов Резюме 128 128 129 130 132 133 135 135 135 137 137 138 139 139 140 140 142 142 143 114 160 163 166 169 170 170 178 180 182 184 185 187
Вопросы Упражнения Глава 5. Углубленный анализ 5.1. Углубленное моделирование классов 5.1.1. Стереотипы 5.1.2. Ограничения 5.1.3. Примечания и дескрипторы 5.1.4. Видимость и инкапсуляция 187 188 192 192 193 194 195 197
Содержаниё
9
5.1.5. Производная информация 202
5.1.6. Квалифицированная ассоциация 204
5.1.7. Ассоциативный класс или материализованный класс 206
5.2. Иерархия классов 209
5.2.1. Сложность сетевых структур 209
5.2.2. Сложность иерархических структур 210
5.2.3. Пакеты 211
5.2.4. Подход ВСЕ 213
5.3. Углубленное моделирование обобщения и наследования 215
5.3.1. Обобщение и подставимость 215
5.3.2. Наследование или инкапсуляция 216
5.3.3. Наследование интерфейса 216
5.3.4. Наследование реализации 217
5.4. Углубленное моделирование агрегации и делегирования 224
5.4.1. Расширение семантики агрегации 225
5.4.2. Агрегация как альтернатива обобщению 227
5.4.3. Агрегация и голоны — интеллектуальное орудие 230
Резюме 231
Вопросы 232
Упражнения 233
Глава 6. Основания проектирования систем 234
6.1. Архитектура программного обеспечения 234
6.1.1. Распределенная архитектура 235
6.1.2. Трехзвенная архитектура 236
6.1.3. Программирование баз данных 237
6.1.4. Стратегия повторного использования 240
6.1.5. Компоненты 242
6.1.6. Развертывание 245
6.2. Кооперация 247
6.2.1. Обозначение кооперации 248
6.2.2. Диаграмма кооперации 248
6.2.3. Диаграммы последовательностей и диаграммы кооперации 255
6.2.4. Реализация прецедентов 255
6.2.5. Реализация операций 258
6.3. Наставление по проектному моделированию 259
6.3.1. Проектирование пакетов 260
6.3.2. Проектирование компонент 264
6.3.3. Проект развертывания • 267
6.3.4. Проектирование кооперативных взаимодействий 269
Резюме 278
Вопросы 279
Упражнения 280
10 Содержание
Глава 7. Проектирование пользовательского интерфейса 283
7.1. Проектирование интерфейса как междисциплинарная
деятельность 283
7.2. Интерфейс: от прототипа к реализации 284
7.3. Руководящие принципы проектирования интерфейса,
ориентированного на пользователя 286
7.3.1. Контроль — на стороне пользователя 286
7.3.2. Согласованность 287
7.3.3. Индивидуализация и настройка 288
7.3.4. Терпимость к ошибкам 289
7.3.5. Обратная связь 289
7.3.6. Эстетичность и удобство 289
7.4. Оконный интерфейс 290
7.4.1. Главное окно 290
7.4.2. Вторичное окно 296
7.5. Зависимость между окнами 302
7.5.1. Документ и его представление 302
7.5.2. Однодокументный интерфейс 303
7.5.3. Многодокументный интерфейс 303
7.6. Навигация по окнам 304
7.6.1. Введение навигационных стереотипов в диаграмму видов
деятельности 305
7.6.2. Диаграмма навигации по окнам 307
Резюме 311
Вопросы 312
Упражнения 312
Глава 8. Проектирование баз данных 315
8.1. Уровень постоянных объектов базы данных 315
8.1.1. Модели данных 316
8.1.2. Отображение объектов в базу данных 317
8.2. Модель объектной базы данных 318
8.2.1. Элементарные типы модели ОБД 319
8.2.2. Отображение в ОБД 325
8.3. Объектно-реляционная модель базы данных 331
8.3.1. Элементарные типы модели ОРБД 332
8.3.2. Отображение в ОРБД 336
8.4. Модель реляционной базы данных 342
8.4.1. Элементарные типы модели РБД 342
8.4.2. Отображение в РБД 351
Резюме 359
Вопросы 359
Упражнения 360
Глава 9. Проектирование программ и транзакций 361
9.1. Проектирование программы 361
9.1.1. Связность и увязка классов 362
9.1.2. Проектирование клиент-серверных кооперативных
взаимодействий 369
9.2. Навигация по программе 373
9.2.1. Стереотипы диаграммы видов деятельности для навигации по
программе 373
9.2.2. Диаграмма навигации по программе 374
9.3. Проектирование транзакций 376
9.3.1. Короткие транзакции 377
9.3.2. Длинные трайзакции 382
9.4. Замкнутое конструирование 383
9.4.1. Замкнутое конструирование для клиентских программ 383
9.4.2. Замкнутое конструирование для баз данных 384
9.4.3. Реинжиниринг реляционных баз данных в объектно-
реляционные 386
Резюме 388
Вопросы 389
Упражнения 389
Глава 10. Тестирование и управление изменениями 390
10.1. Тестирование системных сервисов 390
10.1.1. Сквозной контроль 391
10.1.2. Инспекция 391
10.1.3. Тестирование по отношению к спецификации 392
10.1.4. Тестирование по отношению к программному коду 393
10.2. Тестирование системных ограничений 393
10.2.1. Тестирование пользовательского интерфейса 394
10.2.2. Тестирование баз данных 395
10.2.3. Тестирование авторизации 396
10.2.4. Тестирование других ограничений 398
10.3. Документация по тестированию и управлению
изменениями 398
10.4. Управление изменениями 400
10.4.1. Отправка запроса на изменение 401
10.4.2. Отслеживание запросов на изменение 402
10.5. Прослеживаемость 403
12 Содержание
10.5.1. Прослеживаемость от системных возможностей
к прецедентам и прецедентным требованиям 403
10.5.2. Прослеживаемость от тест-плана к тест-прецедентам
и тестовым требованиям 405
10.5.3. Прослеживаемость от UML-диаграмм к документам
и требованиям 406
10.5.4. Прослеживаемость от требований-прецедентов
к тестовым требованиям 407
10.5.5. Прослеживаемость от требований к дефектам 408
10.5.6. Прослеживаемость от требований-прецедентов
к усовершенствованиям 409
Резюме 410
Вопросы 411
Литература 412
Предметный указатель 417
Моей матери.
В память о моем отце.
Моей семье.
14 Предисловие
Предисловие
Краткое содержание книги
Разработка информационной системы (ИС) — от становления идеи до первой вер-
сии, передаваемой заказчикам, — состоит из трех этапов: анализа, проектирования и
реализации, в результате итеративного выполнения которых происходит пошаговое
“наращивание” системы. В этой книге представлены методы и средства, используе-
мые на первых двух этапах. Вопросы реализации затрагиваются только в той мере, в
которой они необходимы при рассмотрении этапа проектирования. Тестированию и
управлению изменениями посвящена последняя глава.
Центральной темой книги являются вопросы объектно-ориентированной разработ-
ки программного обеспечения (ПО). Для описания артефактов при моделировании ис-
пользуется язык UML (Unified Modeling Language — унифицированный язык моделиро-
вания). Основное внимание уделяется разработке ИС с помощью метода последова-
тельного уточнения, при этом упомянутый язык моделирования (UML) используется па
протяжении всего жизненного цикла разработки. Аналитики, разработчики и програм-
мисты “говорят” на одном языке, хотя иногда в своих профессиональных интересах и
могут пользоваться диалектами (профилями) языка.
Поначалу объектная технология применялась для разработки графических ин-
терфейсов пользователя (GUI — graphical user interface) и была в основном направле-
на на ускорение разработки новых систем и ускорение выполнения программ. В этой
книге основной упор сделан на применение объектной технологии к разработке ИС,
На этом пути необходимо преодолеть такие трудности, как большие объемы и слож-
ные структуры данных, совместный доступ к информации со стороны многих пользо-
вателей, обработка транзакций, изменяющиеся требования и т.д. Основным преиму-
ществом применения объектной технологии в среде ИС является то, что она облег-
чает решение проблем, связанных с сопровождением и масштабируемостью.
Разработка информационной системы может служить синонимом анализа и проек-
тирования “в большом”. Проект ИС не может быть успешным при несоблюдении строго
определенного процесса разработки, а также в отсутствии понимания лежащей в осно-
ве системы архитектуры ПО. Подобную разработку можно охарактеризовать как круп-
номасштабную, объектно-ориентированную, итеративную и наращиваемую. Архитекту-
ра ПО основана на решениях клиент/сервер, где клиент представляет собой рабочую
станцию с GUI, а на сервере хранится база данных. Программы клиента и сервера вы-
полняются в рамках отдельных процессов и взаимодействуют через обмен сообщения-
ми между объектами. База данных сервера может быть реляционной, объектно-
реляционной или чисто объектно-ориентированной.
В книге предложен детализированный подход к анализу и проектированию ин-
формационных систем с использованием UML, и определены способы решения сле-
дующих задач.
Предисловие
1. Преодоление сложности моделей больших систем.
2. Усовершенствование архитектуры ПО.
3. Повышение уровня понятности, удобства сопровождения и масштабируемости.
4. Обеспечение многоуровневой структуризации объектов.
5. Управление интеграцией компонент.
6. Усовершенствование модели взаимодействия между GUI и перманентными
объектами базы данных и т.д.
Отличительные особенности книги
Книге присущи некоторые отличительные черты, сочетание которых делает ее
просто уникальной. Изложение ведется с позиций подхода, который можно назвать
“обучением на примерах”. В основу рассмотрения положены примеры, а также на-
ставление по анализу и проектированию. Примеры независимы друг от друга и отно-
сятся к пяти проблемным областям: Запись на университетские курсы (University Enroll-
ment), Магазин видеопроката (Video Store), Управление контактами с клиентами (Contact
Management), Телемаркетинг (Telemarketing) и Internet-магазин (OnLine Shopping). Примеры
построены в виде разбора конкретных ситуаций, которые можно расширить или мо-
дифицировать с помощью вопросов, приведенных в конце большей части глав в раз-
деле “Упражнения”. В некоторых из упражнений используется шестая проблемная
область — Оценка расходов на рекламу (AdvertisingExpenditure Measurement).
Чтобы облегчить самостоятельное изучение материала, наставление (Internet-
магазин) и анализ примеров излагаются в форме вопросов и ответов. В начале книги
помещен специальный раздел, “Диаграммы видов деятельности для книги”, содержа-
щий диаграммы, которые связывают шаги “вопрос/ответ”, используемые в наставле-
нии и при разборе ситуаций. Диаграммы видов деятельности могут служить в качест-
ве альтернативного “оглавления” для примеров, разбросанных по книге.
В данном пособии рассматриваются принципы, методы и приемы, способные обес-
печить надлежащий анализ и надлежащее проектирование. Особое внимание уделяется
этапу проектирования, трактовка которого далека от его понимания как простого пре-
образования результатов анализа. При этом в книге находит подтверждение факт суще-
ствования трудностей и сложностей на пути разработки крупномасштабных объектно-
ориентированных систем клиент/сервер. Во многих отношениях книга содержит све-
жий взгляд на проектирование “в большом”, итеративную пошаговую разработку боль-
ших систем, а также на возможности и ограничения, присущие средствам и методам,
которые применяются при создании крупных программных изделий.
Своим уникальным характером книга обязана в первую очередь гармоничному со-
четанию практического акцента в объяснении материала с проникновением в его
теоретическую суть. В качестве основной предпосылки является стремление избе-
жать ненужной сложности, не утратив необходимой строгости. Книга написана с по-
зиций опыта. Вопросы, не имеющие прямого отношения К индустрии ПО либо пред-
ставляющие сегодня чисто научный интерес, не вошли в книгу.
Книга отражает последние достижения в сфере информационной технологии; ис-
пользует самый последний стандарт в области моделирования систем — язык UML и об-
ращается к новейшим разработкам в технологии баз данных, включая объектно-
реляционные базы данных. В этом контексте в книге не могло не найти отражения та-
кое явление, как возврат от “толстого клиента” (т.е. мощного настольного компьютера)
16 Предисловие
к серверным вычислениям, происходящий под влиянием развития Internet. Рассматри-
ваемые в книге принципы анализа и проектирования в равной мере применимы как в
случае решений, основанных на архитектуре клиент/сервер, так и современных рас-
пределенных приложений, построенных с использованием компонентного подхода.
Разработка ПО не сводится к однозначным решениям типа “черное-белое“,
“истина-ложь”, “нуль-один”. Источником эффективных программных решений служат
идеи толковых бизнес-аналитиков, системных проектировщиков и программистов, а не
безоглядное применение алгоритмов. Здесь проводится линия, направленная на то,
чтобы предупреждать читателя о потенциальных трудностях, которые не могут быть пол-
ностью разрешены в рамках предлагаемого подхода. Благодаря этому можно надеяться,
что читатели станут применять приобретенные знания обдуманно и не будут рассчиты-
вать на то, что использование предлагаемого подхода не потребует от них усилий, в
противном случае они рискуют обмануться в своих ожиданиях.
Подводя итог, можно отметить следующие отличительные черты, свойственные
книге.
1. Книга устанавливает связь теории с действительностью — в виде практических
проблем и ограничений, на которые следует обращать внимание, применяя
пред лагаемый подход на деле.
2. Особое внимание в книге уделяется этапу проектирования. Проектирование не
рассматривается как простое преобразование результатов анализа, при этом
внимание читателей обращается на трудности и сложности, присущие разра-
ботке крупномасштабных систем клиент/сервер.
3. Книга изобилует нетривиальными примерами и упражнениями, которые при-
водятся вместе со всеми необходимыми решениями и пояснениями.
Для кого предназначена эта книга
Это пособие предназначено как для студентов, так и для практиков, что полностью
отвечает растущей потребности в университетских курсах, более приближенных к от-
раслевой практике. Его подготовка была непростой задачей, но есть основания наде-
яться, что ее удалось успешно решить. Чтобы полученные знания оставались актуальны-
ми в течение более продолжительного времени, относящиеся к разработке ПО аспекты реа-
лизации рассматриваются безотносительно к специфике тех или иных конкретных
программных продуктов, представленных сегодня на рынке (хотя коммерческие GASE-
средства используются в иллюстративных целях и в качестве примеров решений).
Книга призвана служить в качестве учебного курса по теории вычислительных сис-
тем и информационным системам. Поскольку она содержит как “высокоуровневые” те-
мы, относящиеся к системному моделированию, так и “низкоуровневые” вопросы про-
ектирования пользовательского интерфейса и баз данных, книга может оказаться по-
лезной для курсов по системному анализу, проектированию систем, программной инженерии,
базам данных, объектной технологии, а также курсов по программным проектам, которые
требуют от студентов разработки системы в соответствии с жизненным циклом разра-
ботки: начиная с определения требований и заканчивая реализацией GUI и баз данных.
Настоящее пособие задумано как односеместровый курс, однако потенциально может
быть использовано при чтении двух односеместровых курсов — одного по анализу тре-
бований, а другого по проектированию систем.
Предисловие 17
Для той части читателей, которые относятся к специалистам-практикам, пред-
ставленные теории увязываются с реальными проблемами. Источником большинства
постановок задач, примеров и упражнений послужил опыт работы автора в качестве
консультанта. Мы предупреждаем читателя о потенциальных трудностях и ограниче-
ниях, связанных с предлагаемым подходом. По нашему мнению, наибольшую пользу
от книги могут получить следующие категории специалистов-практиков: бизнес-
аналитики и системные аналитики, проектировщики, программисты, системные архитек-
торы, руководители и менеджеры проектов, специалисты по анализу решений, тестированию
и подготовке технической документации, инструкторы производственного обучения.
Структура книги
Книга полностью охватывает вопросы объектно-ориентированного анализа и
проектирования информационных систем. Материал представлен в порядке, соот-
ветствующем современным процессам разработки. Пособие состоит из десяти глав.
Охват материала равномерно распределен между анализом и проектированием. Пер-
вые пять глав касаются вопросов анализа, а вторые пять — проектирования и связан-
ных с ним сведений.
Читатели с различным базовым уровнем подготовки должны иметь возможность
по-разному работать с книгой применительно к своим потребностям. Две главы книги
посвящены объяснению оснований анализа и проектирования. Оставшиеся главы
предполагают понимание этих оснований. Читателям предоставляется выбор: изу-
чать главы, посвященные “основаниям” досконально, или же использовать их только
в качестве обзора.
Чтобы сделать изложение более ясным и нарушить его однообразие, в книге ис-
пользуется несколько приемов, перечисленных ниже.
Разделы сделаны небольшими по объему.
Примеры и постановки задач помещены в рамки, чтобы выделить их из
остального текста. Графические пиктограммы (см. ниже) на полях страниц также
отмечают начало каждого примера.
В книге используются пиктограммы, которые служат указателями примеров в
тексте, а также вопросов и упражнений, заключающих главы. Пиктограммы будут
представлены в следующем виде.
ПИКТОГРАММА
[0
М
[ё!
Примеры
Вопросы
Упражнения
18 Предисловие
Вспомогательные материалы
На Web-узлах, дополняющих книгу, в распоряжение читателей предоставляется об-
ширный комплект вспомогательных материалов. К большей части Web-документов чита-
тели имеют свободный доступ, но некоторые материалы защищены паролем в интересах
преподавателей, которые станут применять пособие в учебном процессе. Информацион-
ные страницы по книге одновременно поддерживаются на следующих Web-узлах
http: / / wiviv . books i tes. net/maciaszek
http://www.comp.mq.edu.au/books/maciaszek
Комплект вспомогательных материалов включает следующие Web-документы.
1. Instructor’s Manual (Руководство преподавателя), содержащее нижеприве-
денные материалы.
- Lecture Slides (Лекционные слайды) в форматах Power Point и Acrobat Read (.pdf).
- Answers and Solutions (Ответы и решения). Руководство, содержащее
аннотированные ответы и решения для всех вопросов и упражнений,
помещенных в конце каждой главы. Организация руководства соответствует
структуре учебника. Вопросы из учебника повторяются в руководстве.
Ответы и решения следуют за вопросами.
2. Student's Resources (Материалы для студентов), пригодные для печатания
лекционных слайдов в формате Acrobat Read.
3. Self-education Resources (Материалы для самообразования) — файлы моде-
лей, представленных средствами Rational Rose (.mdl) и PowerDesigner (.pdm).
содержащие решения задач из наставления, анализ ситуаций и все прочие при-
меры моделирования из учебника.
4. Errata (Список опечаток) — страница, предназначенная для исправления оши-
бок и описок, встретившихся в книге.
5. For More Information (Дальнейшие сведения) — страница, указывающая чи-
тателям на последние идеи и тенденции, относящиеся к предмету книги. Также
служит указателем на курсы, построенные на основе книги, которые подготов-
лены для совместного использования другими читателями с помощью WWW.
Ваши комментарии, исправления, предложения по улучшению и приглашения к
сотрудничеству будут приняты с большой благодарностью. Пожалуйста, направляйте
вашу корреспонденцию автору
Leszek A. Maciaszek
Department of Computing
Macquarie University
Sydney
NSW 2109
Australia
leszek@ics. mq. edu. au
http: //www. comp. mq. edu. au/ leszek/
телефон: +61 2 9850-9519
факс: +61 2 9850-9551
обычная почта: North Ryde, Herring Road, Bld. E6A, Room 319
19
Благодарности
Написание этой книги было бы невозможно без общения с моими друзьями, кол-
легами, студентами, ведущими специалистами отрасли и многими другими людьми,
которые сознательно или нет оказали влияние на формирование моих знаний о про-
блемной области. Я действительно в большом долгу перед ними. Попытка перечис-
лить всех могла бы показаться неблагоразумной и невыполнимой, поэтому — большое
спасибо всем. Однако, даже при отсутствии достаточного места для благодарностей
некоторых “товарищей” следует упомянуть особо.
Кейт Менсфилд (Keith Mansfield), Mary Lince (Мери Лине) и сотрудников Pearson
Education — за признание перспектив за этой книгой и выведение ее на
международный рынок.
Стефена Биллз (Stephen Bills) и его сотрудников из компании ACNielsen AdEx, Сидней,
Австралия, в частности, Стивена Гротте (Steven Grotte), Кевина Мати (Kevin Mathie),
Кемерон Мюррей (Cameron Murray), Джеймса Риз (James Rees), Джован Споа (Jovan
Spoa) и Эрика Цуркера (Eric Zurcher) — за предоставление в мое распоряжение
испытательной модели разработки производственных ИС для работы над этой книгой.
Моих друзей и коллег по факультету вычислительной техники (Department of
Computing) Маккуарийского университета (Macquarie University) в Сиднее,
Австралия — за их поддержку в создании этой книги.
Официальных (неизвестных мне) и неофициальных рецензентов — за их отзывы,
значение которых для улучшения книги трудно переоценить
Сотрудников компаний Rational, Oracle и Sybase— за предоставленные в мое
распоряжение CASE-средства и ПО баз данных, незаменимые при разработке
наставлений, анализе конкретных случаев и составлении примеров.
Издатели благодарят за предоставление разрешений на воспроизведение следую-
щих охраняемых авторским правом материалов.
Рис. 2.34 воспроизводится с разрешения Gateway, Inc. © Gateway, Inc.; рис. 7.1, 7.4,
7.6. 7.7, 7.8, 7.9, 7.11, 7.12, 7.13, 7.14, 7.15, 7.16, 7.17, 7.19, 7.20, 10.6, 10.7, 10.8, 10.9,
10.10, 10.11 и 10.12 воспроизводятся с разрешения ACNielsen; рис. 7.10 воспроизво-
дится с разрешения Маккуарийского университета.
20 Предисловие
Web-узел, дополняющий книгу Лешека А. Мацяшека Анализ требований и раз-
работка систем.
Посетите Web-узел, дополняющий книгу Анализ требований и разработка систем.
расположенный по адресу
http://vmvi.booksites.net/maciaszek
Здесь вы найдете ценные материалы, необходимые для преподавания, обучения
Для преподавателей:
лекционные слайды в формате PowerPoint или Acrobat;
руководство, содержащее аннотированные ответы и решения для всех
вопросов и упражнений, помещенных в конце каждой главы.
Для студентов и преподавателей:
файлы моделей, представленных средствами Rational Rose и PowerDesignei,
содержащие решения задач из наставления, анализ ситуаций и все прочие
примеры моделирования из учебника;
обновленную страницу, содержащую ссылки на последние тенденции и
работы других специалистов, работающих в этой проблемной области.
Диаграммы деятельности для книги 21
Диаграммы деятельности
для книги
Знания в области анализа требований и проектирования систем носят прикладной
характер. Поэтому их нельзя по-настоящему усвоить, только читая учебники. Единствен-
ный эффективный способ овладеть ими — пробовать применять на практике, совершая
ошибки, анализируя эти ошибки и стремясь избежать их при выполнении следующих
заданий. Данный учебник был написан с учетом этого наблюдения.
Книга насыщена примерами, включая наставление и разбор четырех конкретных
случаев. Однако, примеры сформулированы таким образом, чтобы дать возможность
читателю заниматься самостоятельно, экспериментировать, совершать ошибки и на-
ходить альтернативные решения. Читателю всегда предлагается найти собственное
решение прежде, чем заглянуть в ответ. Как сказал Джим Хорнинг (Jim Homing):
"Верные решения вырабатываются на основе опыта. Опыт вырабатывается на основе
ошибочных решений”.
Диаграммы деятельности для книги предоставляют в распоряжение читателей
“карту'”, которая связывает между собой все примеры. При построении этих диаграмм
использовался метод формального моделирования (диаграммы деятельности языка
UML), однако, для использования данных диаграмм какого-либо знания метода не тре-
буется. Каждый прямоугольник с закругленными углами (состояние в UML) соответствует
разделу книги с примером. Некоторые стрелки, которые (прямо или косвенно) указы-
вают на прямоугольник, исходят из других прямоугольников. Все такие прямоугольники
соответствуют примерам, выполнение которых является предусловием для данного при-
мера. Обозначения на стрелках определяют все действия, которые должны быть завер-
шены до того, как приступить к рассмотрению примера.
Разнообразие способов применения диаграмм деятельности для книги ограничено
только воображением читателя. Вот некоторые из возможных применений диаграмм.
Объединение примеров в наставлении или при разборе примеров в связный модуль,
который можно использовать как логичную и непрерывную учебную работу'.
Быстрый поиск предшествующих примеров и решений, необходимых для того,
чтобы приступить к следующему заданию.
Выбор некоторых видов деятельности по моделированию и пропуск остальных с
целью индивидуализации обучения.
Разработка заданий для студентов и т.д.
В конце каждой главы диаграммы деятельности для книги объединены с
упражнениями. Упражнения развивают идеи, заключенные в примерах. Лучший
способ найти примеры, относящиеся к упражнению, и понять, какие знания
требуются для решения задачи, сформулированной в упражнении, состоит в том,
чтобы просмотреть соответствующую диаграмму вида деятельности.
22 Internet-магазин (наставление)
Internet-магазин (наставление)
Диаграммы деятельности для книги 23
Заиж^яауииверснтетгскиетсурсы (разбор примера)
Запись на университетские курсы
(разбор примера)
Диаграммы деятельности для книги 25
26 Магазин видеопроката (разбор примера)
Магазин видеопроката (разбор примера)
Диаграммы деятельности для книги 27
Управление контактами с клиентами
(разбор примера)
Управление контактами с клиентами — Анализ
28 Управление контактами с клиентами (разбор примера)
Диаграммы деятельности для книги 29
Телемаркетинг (разбор примера)
Процесс разработки
программного обеспечения
Данная глава посвящена изложению — на уровне обзора — некоторых стратегических
вопросов, касающихся процесса разработки ПО. Поскольку предлагаемые темы рассмат-
риваются лишь на общем уровне, а некоторые из вопросов носят спорный характер, чита-
телям вовсе не обязательно соглашаться с автором, чтобы извлечь пользу из оставшейся
части книги (а, может быть, и переменить свое мнение по завершении чтения книги).
Образовательное значение данной главы состоит в том, чтобы ввести читателя в
процессы и подходы, которые лежат в основе современной разработки ПО. Многие
идеи и вопросы, рассматриваемые в данной главе, могут быть уже знакомы читателям
из опыта, повседневного использования компьютеров или соответствующей литера-
туры. При желании такие читатели могут просто бегло просмотреть данную главу и
перейти к главе 2.
1.1. Характер процесса разработки ПО
Литература по управлению информационными системами (ИС) изобилует примерами
провалившихся проектов, превышения сроков и бюджетов, ошибочных решений, сис-
тем, не пригодных для сопровождения и т.д. В исследовательском отчете организации
Standish Group за 1998 год по проекту CHAOS (который так любят цитировать!) утвер-
ждается, что три из четырех программных проектов терпят неудачу в одной из приве-
денных выше областей. В свете подобных утверждений уместно задаться вопросами: “В
чем причина подобных провалов? Какие симптомы свидетельствуют о возникновении
проблем в проекте и как их можно нейтрализовать?”
Прежде, чем обратиться к этим вопросам, необходимо понять характер процесса
разработки ПО. В своей ставшей уже классической статье [10] Брукс (Brooks) опреде-
ляет как сущность, так и случайные свойства, характерные для программной инжене-
рии (software engineering). Сущность программной инженерии кроется в собственных
свойствах программного обеспечения, которые вызывают трудности при его созда-
нии. Эти трудности можно только осознать — их нельзя ни преодолеть за счет какого-
либо технологического прорыва, ни сразить “серебряной пулей”. Согласно Бруксу
1.1. Характер процесса разработки ПО 31
сущность программной инженерии проистекает из таких свойств ПО, как сложность,
податливость, изменчивость и неосязаемость.
Четыре “существенных трудности” создания ПО определяют инвариант или неиз-
менную составляющую процесса его разработки. Инвариант просто констатирует тот
факт, что ПО является продуктом творческого акта разработки — ремесла или искус-
ства в том смысле, что эта деятельность совершается скорее ремесленником, чем ху-
дожником. При обычном положении дел ПО не является результатом повторяющего-
ся акта производства.
После того, как мы разобрались, что собой представляет инвариант разработки
ПО, можно обратиться к понятию случайных свойств программной инженерии. Эти
свойства не присущи ПО изначально, они скорее привнесены извне и обусловлены
вмешательством “человеческого фактора” в практику создания ПО. Свойства про-
граммной инженерии, которые носят случайный характер, также порождают опреде-
ленные трудности при создании ПО. В свою очередь мы разделяем эти “случайные
трудности” на три категории.
1. Участники проекта.
2. Процесс.
3. Язык и средства моделирования.
1.1.1. Инвариант разработки ПО
Как мы уже отмечали, ПО скорее разрабатывается, а не производится [65]. Конечно,
никто не может отрицать, что достижения программной инженерии привнесли в
практику разработки большую определенность, однако (в отличие от традиционных
инженерных дисциплин), успех программного проекта гарантировать нельзя.
Алгоритмы, библиотеки программ, повторно используемые классы, программные
компоненты и т.д. представляют собой неполные, фрагментарные решения для того,
что нам требуется описать при разработке информационных систем. Проблема состоит
в том, чтобы собрать воедино небольшие фрагменты проблемы в виде гармоничной
корпоративной системы, которая удовлетворяет требования сложных бизнес-процессов.
Практика создания ПО способствует разработке систем из настраиваемых про-
граммных пакетов — решений на основе COTS-продуктов {commerdatoj-the-shelf sciftviwe —
готовое к использованию ПО) или ERP-систем {Enterprise Resource Planning System— систе-
ма планирования корпоративных ресурсов). Программный пакет может обеспечить
функции стандартного бухгалтерского учета, производственной системы или системы
управления кадрами. Акцент смещается от разработки “с чистого листа” к “настройке”
ПО, однако, процесс производства все равно занимает значительное место.
Для всякой системы, разрабатываемой “с чистого листа”, необходимо сначала соз-
дать концептуальные конструкции (модели) для конечного решения, которые бы удов-
летворяли специфические потребности организации. После их создания функцио-
нальные возможности программного пакета настраиваются в соответствии с концеп-
туальными конструкциями. Задачи программирования могут быть разными, но
характер деятельности по анализу требований и системному проектированию, свя-
занной с этими конструкциями, при разработке “с нуля” аналогичен. В общем, кон-
цептуальная конструкция (модель) сохраняется, несмотря на всевозможные измене-
ния ее представления (реализации).
32 Глава 1. Процесс разработки программного обеспечения
Что еще более важно, маловероятно, чтобы организация могла найти программный
пакет для автоматизации ее ключевых бизнес-процессов. Ключевым бизнеопроцессом
для телефонной компании выступает телефония, а не управление кадрами или бухгал-
терский учет. То, что заставляет компанию работать (и конкурировать), должно разра-
батываться “с нуля” (или переделываться из унаследованной системы). Как верно было
подмечено Шиперским (Szyperski) [88]: “Стандартные [программные] пакеты создают
лишь гладкое игровое поле, а умение играть приходит совсем с другой стороны”.
Конечно, в любом случае процесс разработки должен использовать преимущества
компонентной технологии [1], [88]. Компонента — это исполняемый программный мо-
дуль, реализующий четко определенные функции (сервисы) и коммуникационные
протоколы (интерфейсы) взаимодействия с другими компонентами. Компоненты
можно сконфигурировать таким образом, чтобы удовлетворить требования к прило-
жению. В настоящее время наибольшую популярность завоевали следующие компо-
нентные технологии.
CORBA (Common Object Request Broker Architecture— Общая архитектура брокера
объектных запросов) от OMG (Object Management Group).
DCOM (Distributed Component Object Model— Распределенная модель компонентных
объектов) от Microsoft.
EJB (EnterpriseJavaBeans - Корпоративная технология дляJava-приложений) от Sun.
Пакеты, компоненты и другие подобные методы не изменяют сущности создания
ПО. В частности, принципы и задачи анализа требований и системного проектирова-
ния остаются неизменными. Конечный программный продукт может собираться из
стандартных или разрабатываемых под заказ компонент, но сам процесс “сборки” по-
прежнему остается искусством. Откровенно говоря, как заметил Прессмап (Pressman)
[65], у нас нет даже “запасных частей”, чтобы заменить отказавшие по ходу дела ком-
поненты системы.
1.1.2. Участники проекта
Участниками проекта (stakeholders) мы называем людей, которые заинтересованы в
программном проекте. Любой человек, интересы которого так или иначе
затрагиваются системой либо сам оказывающий влияние па разработку системы,
является участником проекта. (Проект здесь понимается в широком смысле, как некая
деловая активность, предприятие, в нашем случае — это программный проект. Прим,
ред.) Участники проекта делятся на две основные группы.
Заказчики (пользователи и владельцы системы).
Разработчики (аналитики, проектировщики, программисты и т.д.).
Мы предпочитаем использовать термин заказчик (customer), а не пользователь (user).
Это различение особенно безусловно обоснованно с точки зрения разработки систе-
мы. Во-первых, заказчик — это лицо, которое платит за разработку и отвечает за при-
нятие решений. Во-вторых, даже если заказчик не во всем прав, требования заказчика
не могут быть произвольным образом изменены или отвергнуты разработчиками —
любое противоречивое, невыполнимое или неправомерное требование должно быть
оговорено с заказчиками.
1.1. Характер процесса разработки ПО 33
В свете последнего утверждения мы отдаем себе отчет в том, что термин пользователь (в
значении заказчик) значительно более распространен и мы не будем в дальнейшем избе-
гать его. Однако, мы будем воздерживаться от использования неудобного термина конеч-
ный пользователь (end-user), под которым исторически подразумевался уполномоченный
пользователь, выбранный для общения с разработчиками (вместо реального пользователя).
Информационные системы — системы социальные. Они разрабатываются людьми
(разработчиками) для людей (заказчиков). Успех программного проекта определяет^
ся социальными факторами — роль технологии второстепенна. Есть немало примеров
технически отсталых систем, которые работают и полезны заказчикам. Обратное, как
правило, неверно. От системы, не приносящей пользы (ожидаемой или реальной),
заказчик рано или поздно откажется независимо от того, насколько блестящей она
является в техническом отношении.
В типичной ситуации основные причины провала программных проектов могут
быть отнесены на счет участников проекта. Если рассматривать проблему провала
проектов со стороны заказчиков, то эти причины выглядят следующим образом [62]:
потребности заказчиков не поняты или не полностью зафиксированы;
требования заказчиков изменяются слишком часто;
заказчики не готовы выделить достаточно ресурсов под проект,
заказчики не стремятся к сотрудничеству с разработчиками;
ожидания заказчиков нереалистичны;
система оказывается бесполезной для заказчиков.
Проекты также заканчиваются неудачей потому, что разработчики оказываются не
па высоте поставленных задач. В связи с увеличением сложности ПО растет понима-
ние того, что критическим фактором разработки становятся опыт и знания разработ-
чиков. Хорошие разработчики могут дать решение. Высококлассные разработчики
могут дать значительно лучшее решение, намного быстрее и дешевле. На эту тему су-
ществует довольно известная шутка Брукса: “Великие проекты — удел великих разра-
ботчиков” [10].
Мастерство и ответственность разработчиков являются факторами, вклад кото-
рых в достижение качества и продуктивности ПО трудно переоценить. Чтобы гаран-
тировать успешную поставку ПО заказчику и, что более важно, обеспечить выгоды от
его использования, организация-поставщик ПО должна в отношении разработчиков
следовать некоторым простым правилам [10], [96]. Итак, организация-разработчик
ПО должна добиваться следующего.
Нанимать лучших разработчиков.
Обеспечивать непрерывное обучение и повышать уровень образования своих
разработчиков.
Поощрять обмен информацией и общение между разработчиками так, чтобы они
взаимно стимулировали друг друга.
Стимулировать разработчиков, устраняя препятствия и направляя их усилия на
продуктивную работу.
Создавать исключительно благоприятную рабочую атмосферу (зачастую это
оказывается намного более важным, чем редкие прибавки к жалованью).
84 Глава 1. Процесс разработки программного обеспечения
Увязывать личные цели разработчиков со стратегией и задачами организации.
Придавать особое значение коллективной работе.
1.1.3. Процесс
Процесс разработки ПО определяет действия и организационные процедуры, па
правленные на усиление совместной работы в бригаде разработчиков с целью постав-
ки заказчикам высококачественных программных продуктов. На модель процесса
возлагаются следующие функции.
Установление порядка выполнения действий.
Определение состава и времени поставки артефактов, создаваемых в процессе
разработки.
Закрепление действий и артефактов за разработчиками.
Введение критериев отслеживания хода проекта, измерение результатов и
планирование будущих проектов.
Процесс разработки невозможно стандартизировать или систематизировать та
ким образом, чтобы любая организация могла использовать его автоматически. Каж-
дая организация должна разработать свою собственную модель процесса или ирис по-
собить некоторый настраиваемый шаблон процесса под свои нужды. К последним от-
носится шаблон, предлагаемый компанией Rational Software Corporation, известный как
Rational Unified Process [47].
Процесс, который берет на вооружение организация, должен быть увязай с ее раз*
витием, культурой, социальной динамикой, знаниями и опытом разработчиков, пракги
кой руководства, ожиданиями заказчиков, масштабами проектов и даже характером
проблемных областей. Поскольку все перечисленные факторы подвержены измснени
ям, организации может потребоваться ввести разнообразие в ее модель процесса и пре-
дусмотреть варианты модели для каждого отдельного программного проекта. Напри-
мер, в зависимости от того, насколько разработчики хорошо знакомы с методами и
средствами моделирования, в процесс может потребоваться включить специальные
курсы обучения. Наверное самое большое влияние на процесс оказывает масштаб про-
екта. Для небольших проектов (порядка десяти, или около того, разработчиков) фор-
мальный процесс может вообще не потребоваться. Такая небольшая бригада скорее все-
го способна общаться и реагировать на изменения неформально. Для более крупных
проектов неформальной коммуникативной сети может оказаться недостаточно, в этом
случае требуется строго определенный процесс для управляемой разработки.
1.1.3.1. Итеративный процесс разработки с пошаговым
наращиванием возможностей
Современные процессы разработки ПО непременно являются итеративными
(iterative) процессами с пошаговым наращиванием возможностей (incremental) системы.
Модели системы уточняются и преобразуются на этапах анализа, проектирования
и реализации — в результате успешных итераций добавляются новые детали, при не-
обходимости вводятся изменения и усовершенствования, а выпуски программных мо-
дулей с наращенными возможностями поддерживают высокий уровень удовлетворенно-
сти пользователей и обеспечивают обратную связь, необходимую для продолжения
разработки модулей.
1.1. Характер процесса разработки ПО 35
Одно из положений методологии Rational Unified Process звучит следующим образом:
“Итеративный процесс — это процесс, направленный на управление потоком испол-
няемых версий ПО. Процесс с наращиванием возможностей — это процесс, направ-
ленный на непрерывную интеграцию системной архитектуры для производства этих
версий, при этом каждая новая версия заключает в себе усовершенствованные воз-
можности в сравнении с предыдущими” [8].
Успех итеративного процесса с наращиванием возможностей основывается на
раннем выявлении архитектурных модулей системы. Модули должны быть примерно
одинаковыми по размерам, обладать сильной внутренней связностью и иметь мини-
мум взаимных пересечений (внешних связей). Важен также порядок реализации мо-
дулей. Некоторые модули невозможно реализовать в виде исполняемой версии, если
они зависят от информации или результатов вычислений, производимых другими
модулями, которые еще должны быть разработаны. Если только в основе итератив-
ной наращиваемой разработки не лежит планирование и контроль, то в отсутствие
контроля реального хода проекта процесс может превратиться в “хакерство”.
1.1.3.2. Модель технологической зрелости
Главной проблемой для любой организации, занятой производством программно-
го обеспечения, является усовершенствование процесса разработки. Вполне естест-
венно, что, для того, чтобы ввести в процесс усовершенствования, организация
должна знать, какие проблемы связаны с существующим процессом. Одним из наибо-
лее известных методов оценки и усовершенствования процессов является так назы-
ваемая модель технологической зрелости (Capability Maturity Model— СММ) [12].
Модель СММ была разработана Институтом программной инженерии (Software
Engineering Institute (SEI)) при Питтсбургском университете Карнеги-Меллона
(Carnegie Mellon University) в США. Первоначально эта модель использовалась Ми-
нистерством обороны США для оценки возможностей организаций в области ИТ, ко-
торые участвовали в конкурсах на получение оборонных заказов, сегодня она находит
широкое применение в ИТ-индустрии как в Америке, так и за ее пределами.
По существу СММ — это анкета, которую заполняет организация, работающая в
области ИТ. После анкетирования следует верификация и аттестация процесса, в ре-
зультате которых организацию относят к одному из пяти уровней модели СММ. Чем
выше уровень, тем более зрелым является процесс разработки ПО в организации.
Па рис. 1.1 определены уровни, даны краткие описания основных особенностей
каждого из уровней и приведены основные сферы улучшения процесса, необходимые
для достижения организацией более высокого уровня технологической зрелости.
Артур (Arthur) [3] называет уровни зрелости “лестницей, ведущей к совершенству
в области ПО”. Пять ступенек на этой лестнице соответствуют хаосу, управляемому
проекту, применению методов и средств организации процесса, измерению процесса
и непрерывному повышению качества.
Как показывает опыт, па переход с одного уровня шкалы технологической зрелости
на другой уходит несколько лет. Большинство организаций находятся на уровне 1, неко-
торые — па уровне 2; известно очень немного организаций, находящихся на 5-м уровне.
Приводимые ниже вопросы показывают, насколько трудновыполнима эта задача. Орга-
низация, которая стремится достичь 2-го уровня, должна добиться положительных от-
ветов па все приведенные ниже вопросы (а также на некоторые другие) [62].
36 Глава 1. Процесс разработки программного обеспечения
Совершенствование
определенности у
процесса I
Совершенствование
упорядоченности i
процесса I
Уровень 1
Начальный
Совершенствование
измерения /
характеристик /
процесса I
Уровень2
Воспроизводимый
Уровень3
Определенный
Совершенствование
процесса управления
изменениями
Непрерывное
и повсеместное
совершенствование
Уровень4
Управляемый
Уровень 5
Оптимизируемый
процесса
Для управления процессом
используются измерения
Кодификация и следование процессам
управления и разработки
Воспроизводимое управление проектом;
состоятельные оценки времени и средств
для аналогичных проектов
Непредсказуемый и неупорядоченный процесс,
зависящий от текущих исполнителей
Рис. 1.1. Уровни зрелости процесса по модели С,ММ
Имеется ли в организации канал управления и отчетности по функции обеспечения
качества ПО, отдельный от управления проектами по разработке ПО?
Введена ли для каждого проекта функция конфигурационного управления ПО,
которая затрагивает его разработку?
Использует ли руководство формальный процесс для анализа каждой
программной разработки прежде, чем взять на себя договорные обязательства?
Используется ли для составления календарного плана разработки ПО формальная
процедура?
Применяются ли формальные процедуры для оценки затрат на разработку ПО?
Собирается ли статистика в отношении программного кода и ошибок, выявленных
при тестировании?
Имеется ли в распоряжении высшего руководства механизм для регулярного
анализа состояния проектов по разработке ПО?
Используется ли определенный механизм для контроля изменений требований
к ПО?
1.1.3.3. Стандарт ISO 9000
Помимо СММ существуют и другие модели усовершенствования процесса созда
ния ПО. Особый интерес представляет серия стандартов по качеству ISO 9000, разра-
ботанная Международной организацией по стандартизации (International Organiza-
tion for Standardization). Стандарты ISO этой серии применяются для управления ка
чеством и определения процесса производства качественной продукции. Стандарты
1.1. Характер процесса разработки ПО 37
носят общий характер — они применимы для любой отрасли и всех видов бизнеса,
включая разработку ПО.
В основе серии стандартов ISO 9000 лежит предположение о том, что если процесс
организован надлежащим образом, то и результат процесса (товар или услуга) также бу-
дет обладать надлежащим качеством. “Цель управления качеством заключается в произ-
водстве качественных товаров за счет того, чтобы сделать качество неотъемлемым
свойством товара, а не проверки того, насколько оно присуще товару” [78].
Возвращаясь к нашему предыдущему рассмотрению особенностей процесса разра-
ботки ПО, заметим, что стандарты ISO не навязывают конкретного процесса и не
уточняют его характеристик. Стандарты дают модель того, что должно быть достиг-
нуто, однако не говорят о том, как именно должна осуществляться та или иная дея-
тельность. Организация, которая стремится получить сертификат ISO (это также на-
зывается регистрацией) должна рассказать, что она делает; доказать, что слова у нее
не расходятся с делом; и показать, чего она уже достигла [78].
Своеобразной “лакмусовой бумагой”, позволяющей проверить, насколько органи-
зация заслуживает сертификата ISO, может служить ее способность создать качест-
венный товар или обеспечить качественное обслуживание даже в том случае, если за-
менить весь персонал. С этой целью необходимо оформить документально и зафиксиро-
вать все виды своей деятельности. Для каждого вида деятельности должна быть
определена письменная процедура, включая действия, которые необходимо выпол-
нить в случае нарушения процесса или жалоб клиента.
Так же, как в случае модели СММ, сертификат ISO может быть официально пре-
доставлен только после аудита, проведенного на месте регистрационным бюро ISO. По-
добные аудиты затем повторяются через определенное время на регулярной основе.
Организации вынуждены проходить через подобную систему из-за давления конку-
рентных факторов, обусловленных требованиями со стороны потребителей, чтобы
поставщики товаров и услуг были сертифицированы.
1.1.4. Язык и средства моделирования
Участники проекта и процесс составляют два элемента “треугольника”, обеспечи-
вающего успех программного проекта. Третий элемент состоит из языка и средств
моделирования. Подлежащие моделированию артефакты необходимо выразить
(язык) и документально зафиксировать (средства).
Разработчикам необходим язык для построения как визуальных моделей, так и мо-
делей других типов, и обсуждения их с заказчиками и коллегами. Язык должен позво-
лять строить модели на различных уровнях абстракции для представления предла-
гаемых решений на различных уровнях детализации.
Язык должен обладать мощной визуальной составляющей согласно известной пого-
ворке о том, что “лучше один раз увидеть, чем сто раз услышать”. Язык моделирова-
ния должен также обладать мощной декларативной семантикой, т.е. должен позволять
зафиксировать “процедурное” значение в форме “декларативного” предложения.
Иначе говоря, мы должны иметь возможность сказать, “что” именно необходимо сде-
лать, а не распространяться о том, “как ” это должно делаться.
Кроме того, разработчикам необходимы средства для автоматизированного про-
ектирования и создания программ или так называемые CASE-средства (Coinputer-
Assisred Software Engineering — CASE). CASE-средства позволяют хранить и получать
доступ к моделям через центральный репозиторий, а также манипулировать этими
38 Глава 1. Процесс разработки программного обеспечения
моделями на экране компьютера в графическом и текстовом [«-жимах. В идеале репо-
зиторий должен обеспечивать одновременный доступ многих пользователей (многих
разработчиков) к моделям. Ниже приводится перечень типичных функций CASE
репозитория.
Координация доступа к моделям.
Помощь в организации взаимодействия между разработчиками.
Хранение нескольких версий моделей.
Идентификация различий между версиями.
Возможность совместного использования одних и тех же концептов в различных
моделях.
Проверка непротиворечивости и целостности моделей.
Генерация проектных отчетов и документов.
Генерация структур данных и программного кода (конструирование ПО).
Генерация моделей по существующей реализации (реконструкция ПО) и т.д.
Следует заметить, что зачастую программа, сгенерированная с помощью CASE
средств, представляет собой на самом деле всего лишь скелет программы — вычисли
тельный алгоритм, который необходимо дорабатывать программисту как при обыч
ном программировании.
1.1.4.1.UML
“UML (Unified Modeling Language — унифицированный язык моделирования) — э го
визуальный язык моделирования общего назначения, который используется для специ-
фикации, визуализации, конструирования и документирования артефактов программ
ной системы1* [76]. Язык UML был разработан компанией Rational Software Corporation
для унификации лучших свойств, которыми обладали более ранние методы и способы
нотации. В 1997 году организация OMG (Object Management Group — группа управления
объектами) признала его в качестве стандартного языка моделирования. С тех пор UM1
получил дальнейшее развитие и широкое признание в отрасли ПТ.
Язык UML не зависит от применяемого процесса разработки ПО, хотя позже ком-
пания Rational Rose предложила процесс, соответствующий этому языку, под назва-
нием Rational Unified Process (Унифицированный процесс [компании] Rational. Заме-
тим, впрочем, что название методологии можно перевести как “рациональный уни
фицированный процесс”. Прим, ред.) [47]. Совершенно очевидно, что процесс, в
котором в качестве базового языка принят UML, должен поддерживать объектно
ориентированный подход к созданию ПО. Язык UML не подходит для несовременных
структурных подходов, результатом которых являются системы, реализованные с по
мощью процедурных языков программирования, наподобие языка COBOL.
Язык UML также не зависит от технологий реализации (поскольку они являю тся обь-
ектно-ориентированными). По нашем}7 мнению это делает UML ограниченным в отноше-
нии поддержки этапа детализированного проектирования жизненного цикла (ЖЦ) ПО. В
то же время это делает UML более устойчивым к частой смене платформ реализации.
Конструкции языка UML позволяют моделировать статику (структуру) и динамик',
(поведение) системы. Система представляется в виде взаимодействующих объектов
(программных модулей), которые реагируют на внешние события. Действия объектов
позволяют выполнить определенные задачи или получить клиентам (пользователям)
1.2. Планирование разработки системы 39
системы некоторый полезный результат. Отдельные модели отображают определен-
ные стороны системы и пренебрегают другими сторонами, которые охватывают дру-
гие модели. Взятые в комплексе модели обеспечивают полное описание системы.
Модели, создаваемые с помощью языка UML, можно разделить на три группы.
Статические модели (описывают статические структуры данных).
Модем поведения (описывают взаимодействие объектов).
.Модели изменения состояний (описывают допустимые состояния системы, которые
она принимает с течением времени).
UML также содержит несколько архитектурных конструкций, которые позволяют
придать системе модульную структуру, используемую в процессе итеративной и нара-
щиваемой разработки.
1.1.4.2. CASE-средства и совершенствование процесса
Совершенствование процесса — это нечто большее, чем просто введение новых
методов и средств. В действительности, введение новых методов и средств в органи-
зации, находящейся на низком уровне зрелости процесса разработки, может принес-
ти больше вреда, чем пользы.
Подходящий пример — CASE-технологии. Интегрированные CASE-средства позво-
ляют нескольким разработчикам взаимодействовать и совместно использовать про-
ектную информацию для выработки новых проектных артефактов. Чтобы воспользо-
ваться преимуществами этой технологии, бригада разработчиков должна подчинять-
ся определенным правилам, поскольку CASE-средства налагают на процессы
некоторые ограничения. Но если бригада разработчиков не настолько квалифициро-
ванна, чтобы усовершенствовать процесс разработки, чрезвычайно маловероятно,
чтобы она смогла воспринять процесс, диктуемый CASE-средствами. В результате по-
тенциальные возможности роста продуктивности и качества, которые обещает новая
технология, так и не будут реализованы.
Рассмотренные выше особенности применения CASE-средств не должны натолк-
нуть вас на мысль, что CASE-технология — “рискованное дело”. Она может и не дать
вам ожидаемых выгод, если вы пытаетесь использовать ее для того, чтобы направлять
работу всей бригады разработчиков, а бригада не готова следовать нужному процессу.
Однако, те же методы и CASE-средства безусловно могут обеспечить повышение лич-
ной продуктивности и качества работы отдельных разработчиков, которые исполь-
зуют технологию на своих локальных рабочих станциях. Моделировать программные
артефакты с помощью карандаша и бумаги уместно только в аудитории, но никак ни
при работе над реальным проектом.
1.2. Планирование разработки системы
Проекты по разработке информационных систем (ИС) должны быть заранее
< планированы. ИС необходимо идентифицировать, классифицировать, ранжировать
и выбирать для первоначальной разработки, для усовершенствования или, возможно,
для ликвидации. Вопрос состоит в следующем: “Какие технологии ИС и приложения
принесут наибольшие деловые выгоды?” В идеале решение, которому необходимо
следовать, должно базироваться на бизнгс-стратегии и тщательном и методичном пла-
нировании [5], [37], [51].
О Гл— 1. Процесс разработки программного обеспечения
Бизнес-стратегию можно определить посредством различных процессов, извест-
ных как стратегическое планирование, бизнес-моделирование, реинжиниринг бизнес-процессов,
стратегическое увязывание, управление информационными ресурсами и т.п. Мы не ставим
целью пояснять различия между названными подходами. Достаточно сказать, что все
эти подходы связаны с изучением фундаментальных бизнес-процессов в организации,
целью которых является определение долгосрочного видения бизнеса с последующим
назначением приоритетов различным проблемам ведения бизнеса, которые моп г
быть разрешены с помощью информационной технологии (ИТ).
При этом существует немало организаций — в особенности это относится к не-
большим организациям, которые не имеют отчетливой стратегии ведения бизнеса.
Подобные организации скорее всего принимают решение о развитии ИС. просто вы-
являя наиболее насущные деловые проблемы, которые требуют немедленного реше-
ния. При изменении внешней бизнес-среды или внутренних условий ведения бизнеса
существующая ИС снова подлежит модификации. Хотя этот подход обладает очевид-
ными недостатками, он позволяет небольшим организациям быстро перестроиться в
соответствии с текущей ситуацией либо извлечь выгоду из представившихся возмож-
ностей, либо дать отпор новым угрозам.
Крупные организации не могут позволить себе постоянные изменения в направ-
лении ведения бизнеса. В действительности они зачастую диктуют направление дея-
тельности другим организациям, работающим в той же сфере бизнеса, а также в оп-
ределенной мере могут формировать среду для своих повседневных нужд. Однако,
крупные организации должны внимательно вглядываться в будущее: использовать
плановый подход при выборе проектов, связанных с разработкой. Как правило, э i о
масштабные проекты, на выполнение которых требуется много времени. Они слиш-
ком громоздки, чтобы их можно было легко изменить или заменить, и должны быть
способны адаптироваться или даже быть устремлены навстречу будущим возможно-
стям и угрозам.
Существует много способов планирования разработки систем. Один из традицион-
ных подходов получил название SWOT (Strengths, Weaknesses, Opportunities, Threats -
сильные стороны, слабые стороны, благоприятные возможности, угрозы). Еще одна
популярная стратегия базируется на модели VCM (Value Chain Model — модель цепочек
ценности). Более современные варианты подходов к разработке бизнес-стратегий из-
вестны как BPR (Business Process Reengineering— реинжиниринг бизнес-процессов).
Информацию, необходимую для деятельности организации, также оценивают с исполь-
зованием так называемых проектных шаблонов для ISA (Information System
Architecture — архитектура информационных систем). Подобные проектные шаблоны
можно получить по аналогии из описательных схем, успешно зарекомендовавших себя в
дисциплинах, отличных от ИТ (например, в строительной промышленности).
Все подходы к планированию разработки систем обладают одним общим знамена
телем — они направлены скорее на достижение эффективности (делать то, что нужно).
чем продуктивности (делать так, как нужно). Наиболее рациональное решение невер-
ной проблемы немногого стоит!
1.2.1. Подход SWOT
Подход SWOT позволяет идентифицировать, классифицировать, ранжировать и
выбирать проекты по разработке ИС таким образом, чтобы они были увязаны с силь-
1.2. Планирование разработки системы 41
ными и слабыми сторонами организации, а также возможностями и угрозами. Это под-
ход сверху-вниз, применение которого начинается с определения миссии организации.
Формулировка миссии фиксирует уникальный характер организации и определяет ее
видение того, где она хотела бы оказаться в будущем. Верно сформулированная мис-
сия отводит главное место потребностям клиентов, а не товарам или услугам, которые
предоставляет организация.
Формулировка миссии и разрабатываемая на ее основе бизнес-стратегия учитыва-
ют то, какими внутренними сильными и слабыми сторонами обладает компания в таких
областях, как управление, производство, кадровое обеспечение, финансы, маркетинг,
исследования и разработка и т.д. Эти сильные и сла/бые стороны должны быть де-
тально обсуждены и согласованы, после чего им назначаются приоритеты. Преуспе-
вающие организации способны в любой момент идентифицировать текущий набор
сильных и слабых сторон, которые направляют разработку их бизнес-стратегий.
Выявление внутренних сильных и слабых сторон компании — необходимое, но не-
достаточное условие для успешного делового планирования. Организация функцио-
нирует нс в вакууме — ее деятельность зависит от внешних экономических, социаль-
ных, политических и технологических факторов. Она должна знать о внешних благо-
приятных возможностях, из которых необходимо извлечь выгоду, а также о внешних
угрозах, которых следует избегать. Этими факторами организация не в состоянии
управлять, однако осведомленность в отношении их играет существенную роль при
определении целей и задач организации.
На любом заданном отрезке времени организация преследует одну или очень не-
большое количество целей. Цели обычно имеют долговременный характер (три-пять
лет), а иногда относятся к “вечным проблемам”. К типичным примерам целей отно-
сятся повышение уровня удовлетворенности потребителей, введение новых видов ус-
луг. преодоление конкурентных угроз, усиление контроля над поставщиками и т.д.
Каждая стратегическая цель должна быть связана с определенными задачами, кото-
рые обычно принимают форму годовых заданий. Например, цель “повысить уровень
удовлетворенности потребителей” может поддерживаться задачей более быстрого
выполнения заказов клиентов — скажем, в течение двух недель.
Цели и задачи требуют выработки стратегий управления и определенной политики
в отношении реализации этой стратегии. Подобные методы управления позволяют
привести в соответствие организационные структуры, распределить ресурсы и опре-
делить проекты, связанные с разработкой, в том числе, информационных систем.
1.2.2. Подход VCM
Метод ценностных цепочек — VCM — позволяет оценить конкурентные преимуще-
ства с помощью анализа всей цепочки видов деятельности в организации, начиная от
получения сырья до конечной продукции, продаваемой и доставляемой потребите-
лям. Метафора цепочки усиливает то положение, что единственное слабое звено
приводит к разрыву всей цепи.
Модель служит цели уяснения того, какая конфигурация цепочки ценности сулит
наибольшие конкурентные преимущества. Проекты по разработке ИС могут впослед-
ствии указать на тс сегменты, операции, каналы распределения, маркетинговые под-
ходы и т.д., которые позволяют завоевать наибольшее конкурентное преимущество.
В первоначальном варианте метода VCM [68] организационные функции были
разделены на основные виды деятельности и вспомогательные виды деятельности. Основ-
42 Глава 1. Процесс разработки программного обеспечения
ные виды деятельности создают или добавляют ценность конечному продукту. Они
разделяются на пять последовательных этапов: (1) входящее снабжение, (2) обрабо т-
ка, (3) исходящее снабжение, (4) сбыт и маркетинг, (5) обслуживание.
Поддерживающие виды деятельности не добавляют ценности, по крайней мерс,
прямо. Они также играют существенную роль, но не “обогащают” продукт. Поддер
живающие виды деятельности включают: (1) администрацию и инфраструктуру, (2)
управление кадрами, (3) исследования и разработку и — наверное, это не удивитель-
но — разработку ИС.
Хотя модель VCM представляет собой полезный инструмент для планирования раз-
работки ИС, вездесущая компьютеризация может способствовать переменам в способах
ведения бизнеса, что, в свою очередь, создает конкурентные преимущества. Другими
словами, ИТ может преобразовать ценностные цепочки организации. Таким образом, междх’
ИТ и моделью VCM может быть установлена положительная обратная связь.
Портер (Porter) и Миллар (Millar) [64] выделяют пять шагов, которые должна пред
принять организация, чтобы воспользоваться преимуществами, предоставляемыми ИТ.
1. Оценить информационную емкость продуктов и процессов.
2- Оценить роль ИТ в отраслевой структуре.
3. Выявить и ранжировать способы, с помощью которых ИТ создае т конкурент-
ное преимущество.
4. Рассмотреть, каким образом ИТ может создать новое направление в бизнесе.
5. Разработать план, направленный на извлечение выгод от использования ИТ.
1.2.3. Подход BPR
Подход к планированию разработки ИС с использованием методов реинжипирип
га бизнес-процессов (BPR-методов) основан на допущении, что современные органи-
зации должны реконструировать себя и отказаться от функциональной декомпози-
ции, иерархических структур и принципов приоритетности повседневных нужд, ко-
торые они сегодня используют.
Рассматриваемая концепция была введена в 1990 году Хаммером (Hainmci) и Де-
венпортом (Davenport) [30], и Шортом (Short) [19] и сразу обратила па себя внима-
ние, вызвав полемику. Расширенное описание метода BPR можно найти в книгах его
основателей [32], [18].
Сегодня большинство организаций имеют структуру с вертикальным подчинением
подразделений, сосредоточенных на функциях, товарах или регионах. Эти структуры и
методы работы прослеживаются вплоть до восемнадцатого века и берут свое начало в
принципе разделения труда и последующей фрагментации работы, сформулирован-
ном еще Адамом Смитом. Никто из работников или подразделений не отвечае т за биз-
нес-процесс, который определяется как “...совокупность видов деятельности, получаю-
щих на входе один или несколько типов ресурсов и создающих на выходе продукцию,
представляющую ценность для потребителя” [32].
Методология реинжиниринга бизнес-процессов ставит под сомнение индустри-
альные принципы Смита разделения труда, иерархического управления и экономии
на масштабах. В современном мире организация должна быть способна адаптиро-
ваться к быстрым изменениям рынка, новым технологиям, конкурентным факторам,
требованиям потребителей и т.д.
1.2. Планирование разраоотки сич смш
Жесткие организационные структуры, в которых бизнес-процессы разорваны ме-
жду многими подразделениями, устарели. Организации должны сосредоточиваться
на бизнес-процессах. а не на отдельных задачах, заданиях, специалистах и функциях
подразделений. Эти процессы разделены по горизонтали между видами деятельности и
завершаются в точках контакта с потребителями. “Наиболее видимое различие между
предприятием, ориентированным на бизнес-процессы, и традиционной организаци-
ей состоит в существовании у каждого из процессов “хозяина” [33].
Основная цель реинжиниринга бизнес-процессов состоит в радикальной реконст-
рукции бизнес-ироцессов в организации (поэтому подход BPR зачастую называется
реконструкцией или перепроектированием процессов). Бизнес-процессы необходимо иден-
тифицировать, хорошо наладить и усовершенствовать. Поведение процессов фикси-
руется в виде диаграмм потоков работ (workflow diagrams) и изучается в рамках дисцип-
лины “Анализ потоков работ”. Потоки работ охватывают потоки событий, документов
и информации в рамках бизнес-процессов и могут использоваться для подсчета вре-
мени, ресурсов и финансовых средств, необходимых для этих видов деятельности.
Основное препятствие на пути реализации BPR-подхода в организации лежит в
необходимости внедрения горизонтального процесса в традиционную вертикальную
струкгуру управления. Серьезная инициатива по внедрению BPR-подхода требует пе-
реключения организации на проектные бригады как основные организационные
единицы. Эти бригады отвечают за один или более сквозных бизнес-процессов.
Иногда радикальные изменения неприемлемы. Традиционные структуры не могут
быть изменены в одночасье. Радикальные шаги могут встретить сопротивление, и по-
тенциальные выгоды от внедрения BPR-подхода могут быть подвергнуты риску. В
данных обстоятельствах организация все же может выиграть от моделирования биз-
пег-процессов и попыток просто усовершенствовать их, а не подвергать полной пе-
ределке. Гермин “усовершенствование бизнес-процессов” (Business Process Improve-
ment — BPI) используется для характеристики подобного начинания [1].
После того, как бизнес-процесс определен, “хозяева” процесса могут потребовать
поддержки со стороны ИТ с целью дальнейшего повышения продуктивности этих
процессов. Результирующий проект по разработке ИС должен сосредоточиваться на
реализации выявленных потоков работ. Сочетание эффективности, получаемой от
применения BPR-подхода, с продуктивностью, являющейся результатом применения
ИТ. может привести к поразительному улучшению всех современных показателей
деятельности организации, таких как уровень качества и обслуживания, скорость, за-
траты, цена, конкурентные преимущества, гибкость и т.д.
1.2.4. Подход ISA
В отличие от уже описанных подходов подход с использованием унифицирован-
ной схемы для архитектуры информационных систем (Information Systems Architec-
ture— ISA) опюиаи на проектировании снизу-вверх. Этот подход предлагает ней-
тральную архитектурную концептуальную схему для проектных решений по созданию
ИС., которая может подходить для различных бизнес-стратегий. По существу, подход с
использованием ISA не включает методологии планирования разработки систем. Он
просто предлагает схему, которая может служить в качестве рычага для достижения
целей большинства бизнес-стратегий.
44 Глава i. Процесс разработки программного обеспечения
Подход на основе схемы ISA был впервые введен Захманом (Zachman) в его плодо-
творной статье {97] и впоследствии расширен Сова (Sowa) и Захманом [82]. Незначитель-
но видоизмененный вариант оригинальной статьи вновь был опубликован Захманом 1981.
Схема ISA представляет собой таблицу из тридцати ячеек, организованных в виде
пяти строк (помеченных от 1 до 5) и шести столбцов (помеченных от А до F). Строки
представляют различные точки зрения (или ракурсы), используемые при конструирова-
нии сложных инженерных продуктов, таких как информационные системы. Эти точки
зрения принадлежат пяти ос новным “игрокам” — пяти участникам разработки ИС.
1. Планировщик (определяет границы системы).
2. Владелец (определяет концептуальную модель предприятия).
3. Проектировщик (задает физическую модель системы).
4. Конструктор (обеспечивает детализированное технологическое решение).
5. Субподрядчик (поставляет компоненты системы).
Шесть столбцов представляют шесть различных описаний или архитектурных моде
лей, с которыми “играет” каждый участник. Подобно точкам зрения описания значи
тельно отличаются между собой, но в то же время они внутренне связаны между со-
бой. Описания призваны дать ответ на шесть вопросов в отношении моделируемых
сущностей, которыми задается каждый из участников.
А. Что составляет сущность (т.е., в случае ИС, данные).
В. Как сущность функционирует (т.е. бизнес-процессы).
С. Где сущность расположена (т.е. расположение обрабатывающих компонентов).
D. Кто работает с сущностью (т.е. пользователи).
Е. Когда с сущностью что-то происходит (т.е. распределения событий и состояний во
времени).
F. Почему сущность существует (т.е. мотивация предприятия).
Комбинация точек зрения и описаний, представленных в тридцати ячейках таб-
лицы Захмана, представляет собой мощную систематизацию, на основе которой мож
но выстроить полную архитектуру для разработки ИС. Расположенные по вертикали
ракурсы могут отличаться степенью детализации, но, что более важно, они отличают
ся по существу и используют различные представления модели. Различные модели
отражают различные взгляды участников. Аналогично расположенные по горизон та-
ли описания подготовлены, исходя из различных соображений. Каждое из этих опи-
саний призвано ответить на один из шести вопросов.
Наиболее привлекательной стороной подхода ISA является то, что он предлагает
схему, которая, вполне вероятно, может оказаться достаточно гибкой для адаптации к
будущим изменениям в условиях ведения бизнеса и в ресурсах, которыми располагает
предприятие. Это является следствием того, что решения на основе ISA не базируют^
ся на какой-либо определенной бизнес-стратегии. Это просто схема для полного они
сания ИС. Сама схема получена на основании опыта, накопленного более устоявши-
мися дисциплинами, некоторые из них насчитывают тысячи лет (например, класси
ческая архитектура).
1.2.5. Системы для трех уровней управления
Планирование разработки системы связано с представлением о наличии в органи-
зации трех уровней управления.
1.2. Планирование разраоотки ииисмш
1. Стратегического.
2. Тактического.
3. Оперативного.
Эти три уровня организационного управления характеризуются собственным
уровнем принимаемых решений, различным набором необходимых приложений ИС
и специфическими требованиями к поддержке со стороны ИТ-подразделений. Одна
из задач, возникающих при планировании разработки системы, состоит в определе-
нии комплекса приложений ИС и ИТ-решений, который является наиболее эффек-
тивным для организации в определенный момент времени. В табл. 1.1 определены
связанные с установлением соответствия приложений ИС и ИТ-решений уровню
принимаемых решений [40], [72].
Таблица 1.1. Поддержка различных уровней принятия решений со стороны
ИС и ИТ
Уровень принятия решений Направленность принимаемых решений Типичные приложения ИС Типичные ИТ-решения
Стратегический Стратегии, под- де ржи ваюсц ие долгосрочные це- ли организации Анализ рынка и сбыта; планирование разра- ботки товаров; оценка эффективности Добыча данных; управление знаниями
Тактический Стратегии, под- держивающие краткосрочные задачи и распре- деление ресурсов Анализ бюджета; про- гнозирование фонда зарплаты; планирова- ние запасов; обслужи- вание потребителей Хранилища данных; анализ данных; элек- тронные таблицы
Оперативный Поддержка повсе- дневной деятель- ности персонала и производство Выплата жалованья; выписка счетов; закуп- ки; бухгалтерский учет Базы данных; об- работка транзак- ций; генераторы приложений
Реализуемые ИС-приложения и ИТ-решения, которые способны обеспечить наи-
большие выгоды организации, относятся к стратегическому уровню. Однако эти реше-
ния наиболее трудно реализовать— они используют “пограничные” технологии и
требуют очень квалифицированного и специализированного проектирования. Тем не
менее, именно эти системы способны обеспечить организации конкурентное пре-
имущество на рынке.
11а противоположном конце шкалы располагаются системы, поддерживающие
оперативный уровень управления. Эти системы отличаются однообразием действий и
процедур, используют традиционные технологии баз данных и зачастую собираются
из готовых к применению пакетных программных решений. Данные системы непер-
спективны с точки зрения обеспечения конкурентного преимущества, однако без них
opt аиизация не способна функционировать надлежащим образом.
46 Глава 1. Процесс разработки программного обеспечения
Любая современная организация имеет в своем распоряжении полный комплект
систем оперативного управления, но только организации, которые достигли больших
высот в искусстве управления, обладают интегрированным набором приложений ИС
стратегического уровня. Основная технология, которая используется для хранения и
обработки данных в процессе принятия высокоуровневых стратегических и тактиче-
ских решений, известна как технология хранилищ данных [47].
1.3. Этапы жизненного цикла
программного обеспечения
Разработка программного обеспечения подчиняется определенному жизненному цик-
лу {lifecycle). Жизненный цикл (ЖЦ) — это упорядоченный набор видов деятельности,
осуществляемый и управляемый в рамках каждого проекта по разработке ПО. Процессы
и методы — это механизмы реализации жизненного цикла. Жизненный цикл определя-
ет этапы, так что программный продукт переходит с одного этапа на другой, начиная с
зарождения концепции продукта и заканчивая этапом его сворачивания.
Жизненный цикл разработки ПО может быть представлен с различной степенью
детализации этапов. На укрупненном уровне ЖЦ может включать только три этапа.
1. Анализ.
2- Проектирование.
3. Реализация.
Этап анализа {analysis phase) концентрируется на системных требованиях. Требо-
вания определяются и специфицируются. Осуществляется разработка и интеграция
функциональных моделей и моделей данных для системы. Кроме того, фиксируются
нефункциональные требования и другие системные ограничения.
Этап проектирования {design phase) разделяется на два основных подэтапа: архитек-
турное и детализированное проектирование. В частности, проводится уточнение
конструкции программы для архитектуры клиент/сервер, которая интегрирует объ-
екты пользовательского интерфейса и базы данных. Поднимаются и фиксируются
вопросы проектирования, которые влияют на понятность, приспособленность к со-
провождению и масштабируемость системы.
Этап реализации {implementation phase) включает написание программ клиентских
приложений и серверов баз данных. Акцент делается на итеративных процессах реали-
зации с наращиванием возможностей системы. Успех поставки программного продукта
не в последнюю очередь определяется циклической разработкой. Циклическая разработ-
ка {round-trip engineering) характеризуется периодическим возвратом от реализации кли-
ентских приложений и серверов баз данных к проектным моделям и обратно.
Коротко говоря, анализ указывает на то, что делать, проектирование — на то, как с
помощью имеющейся технологии сделать это “что”, а реализация воплощает заду-
манное на предыдущих этапах в виде осязаемого программного продукта, поставляе-
мого заказчику.
На детализированном уровне ЖЦ можно разделить на следующие семь этапов.
1. Установление требований.
2. Спецификация требований.
3. Проектирование архитектуры.
1.3. Этапы жизненного цикла программного обеспечения 47
4. Детализированное проектирование.
5. Реализация.
6. Интеграция.
7. Сопровождение (и окончательное сворачивание).
Некоторые авторы также рассматривают в качестве двух дополнительных этапов
планирование п тестирование. По нашему мнению, эти два важных вида деятельности не
являются отдельными этапами ЖЦ, поскольку охватывают весь ЖЦ в целом. План
управления проектом по разработке ПО составляется в самом начале процесса, суще-
ственно уточняется после этапа спецификации и продолжает развиваться в течение
всего оставшегося ЖЦ. Аналогично тестирование отличается наивысшей интенсив-
ностью после этапа реализации, однако оно также применимо к программным арте-
фактам, вырабатываемым на всех остальных этапах.
1.3.1. Этап установления требований
Котонья (Kotonya) и Соммервилль (Sommerville) [46] определяют требование
(requirement) как “формулировку сути системного сервиса или ограничения”. Формули-
ровка сути сервиса характеризует поведение системы по отношению к отдельным поль-
зователям или ко всему контингенту пользователей. В последнем случае описание
сервиса фактически служит определением бизнес-правила, которое должно выполнять-
ся всегда (например, “двухнедельная зарплата выплачивается в среду'”). Формулиров-
ка сути сервиса может быть связана с некоторым вычислением, которое должна про-
извести система (например, “вычислить комиссионные продавца на основе объема
продаж на прошлую среду' с использованием конкретной формулы”).
Формулировка ограничения выражает ограничивающее условие на поведение систе-
мы или на разработку' системы. Примером первого ограничения может быть ограни-
чение па безопасность: “только непосредственные руководители могут обращаться к
информации о зарплате их персонала”. Примером последнего типа может быть фор-
мулировка: “мы должны использовать средства разработки компании Sybase.”
Обратите внимание, что иногда различие между формулировкой ограничения на
поведение системы и формулировкой услуги на основе бизнес-правила размыто. Это
не составляет проблемы в том случае, если все требования идентифицированы и дуб-
лирование исключено.
Задачей этапа определения требований является определение, анализ и обсужде-
ние требований с заказчиками. На этом этапе применяются различные методы сбора
информации от заказчиков. Это и исследование концепции с помощью структуриро-
ванных и неструктурированных интервью пользователей, анкеты, изучение докумен-
тов и форм, видеозаписи и т.д. Последним методом, применяемым на этапе опреде-
ления требований, является быстрая разработка прототипа (rapid prototyping) решения,
так что требования, вызывающие затруднения, могут быть прояснены, что позволяет
11збежать недоразумений.
Анализ требований включает переговоры между разработчиками и заказчиками.
Этот шаг необходим для исключения противоречивых и дублирующихся требований,
а также согласования проектного бюджета и сроков.
Результатом этапа установления требований является документ, содержащий изложе-
ние требований (requirements document). Это большей частью текстовый документ с некото-
рыми неформальными диаграммами и таблицами. В этот документ, как правило, не
48 Глава 1. Процесс разработки программного обеспечения
включаются формальные модели за исключением, может быть, некоторых простых и
широко известных видов нотации, которые легко могут быть восприняты заказчиками 11
могут облегчить взаимопонимание между разработчиками и заказчиками.
1.3.2. Этап спецификации требований
Этап спецификации требований начинается с того момента, когда разработчики
приступают к моделированию требований с использованием определенного метода
(например, такого как UML). CASE-средства используются для ввода, анализа и доку-
ментирования модели. В результате документ описания требований дополняется
графическими моделями и отчетами, сгенерированными с помощью CASE-средств.
По существу, документ, излагающий требования, заменяется документом, содержа-
щим спецификацию требований {specifications document, иногда он обозначается жаргон-
ным словечком specs).
В рамках объектно-ориентированного анализа в качестве основных методов специ
фикации требований используются два типа диаграмм: диаграммы классов {class diagrams)
и диаграммы прецедентов {use case diagrams). Эти методы позволяют разрабатывать специ-
фикации данных и функций. Обычно документ, содержащий спецификацию требова-
ний, включает также описание других видов требований. Среди атрибутов системы,
требования к которым могут быть приведены в спецификации, относятся, например,
производительность, пригодность к использованию (или практичность), пригодность к
сопровождению, безопасность, политические и юридические требования, и даже
“впечатления и ощущения от использования программы” (“look and feel”).
Модели спецификации могут и должны перекрываться. Это позволяет рассмотреть
предлагаемое решение под разными углами, выделяя и анализируя различные аспекты
решения. Кроме того, это дает возможность проверить непротиворечивость и полнота
требований.
В идеале модели спецификаций должны быть независимы от программной и аппа-
ратной платформ, на которых должна разворачиваться система. Учет особенностей
программной и аппаратной платформ накладывает жесткие ограничения на словарь
(а следовательно — и на выразительность) языка моделирования. Более того, словарь
может быть труден для понимания заказчиками и, таким образом, препятствовать
общению разработчиков и заказчиков.
Тем не менее, некоторые формулировки ограничений могут фактически навязы-
вать разработчикам необходимость рассмотрения особенностей программного и ап-
паратного обеспечения. Более того, сами заказчики могут быть выразителями требо-
ваний относительно определенной технологии или даже требовать применения оп-
ределенной технологии. Отсюда вывод: при возможности следует избегать
рассмотрения особенностей программного и аппаратного обеспечения на этане со-
ставления спецификации системы.
1.3.3. Этап проектирования архитектуры
Документально оформленная спецификация похожа на контракт между разработ-
чиками и заказчиками на поставку программного продукта. В ней перечисляются все
требования, которым должен удовлетворять программный продукт. Теперь специфи-
кации передаются в руки системных архитекторов и проектировщиков для разработ-
ки детализированных моделей системной архитектуры и ее внутренних механизмов.
1.3. Этапы жизненного цикла программного ооесисчсппл
Проект выполняется в терминах программных и аппаратных платформ, на которых
предстоит реализовать систему.
Описание системы в терминах составляющих ее модулей называется архитектур-
ным проектированием (architectural design). Проект архитектуры включает выбор страте-
гических решений по клиентской и серверной частям системы.
Описание внутренних механизмов каждого модуля (прецедентов) называется де-
тализированным проектированием (detailed design). Детализированный проект включает
подробные алгоритмы и структуры данных для каждого модуля. Такие алгоритмы и
структуры данных приспосабливаются ко всем ограничениям, связанным с базовой
платформой реализации. Эти ограничения могут как усиливать основную архитек-
турную концепцию, так и препятствовать ее воплощению.
Архитектурное проектирование связано с выбором стратегии решения и разбив-
кой системы на модули. Стратегия решения (solution strategy) требует разрешения вопро-
сов, касающихся клиентской (пользовательский интерфейс) и серверной (база дан-
ных) частей системы, а также всевозможного ПО промежуточного уровня
(middleware), необходимого для связывания клиента и сервера. Выбор основных
строительных блоков (модулей) относительно независим от стратегии решения, од-
нако детализированный проект модулей должен соответствовать выбранному реше-
нию по архитектуре клиент/сервер.
Зачастую модели архитектуры клиент/сервер расширяются до так называемой
трехзвенной архитектуры (three-tier architecture), в которой логика приложения составляет
отдельный слой. Среднее звено представляет собой слой логики и в этом качестве
может поддерживаться или не поддерживаться отдельным аппаратным обеспечени-
ем. Логика приложения — это процесс, который может выполняться на клиентской
машине или на сервере, т.е. он скомпилирован в виде клиентского или серверного
процесса и реализован как библиотека DLL (Dynamic Link Library — динамически
подключаемая библиотека), интерфейс API (Application Programming Interface — ин-
терфейс прикладного программирования), RPC-вызовов (Remote Procedure Calls—
удаленный вызов процедуры) и т.д. [57].
1.3.4. Этап детализированного проектирования
Архитектурный проект описывает программный продукт с точки зрения состав-
ляющих его модулей. Детализированный проект описывает каждый модуль. При раз-
работке типичной ИС модули реализуются либо в виде клиентской компоненты, либо
серверной компоненты. За первые отвечают проектировщики прикладной части,
вторую должны разрабатывать проектировщики баз данных.
Проект пользовательского интерфейса (клиентского приложения) должен соответ-
ствовать принципам проектирования GUI-интерфейса, установленным разработ-
чиком конкретного GUI-интерфейса (Windows, Motif, Macintosh). Подобные прин-
ципы обычно доступны в WWW как часть электронной документации GUI-
интерфейса (см. например, [92]).
Основной принцип объектно-ориентированного проектирования GUI-интер-
фейс а состоит в том, что управление приложением является прерогативой пользователя,
а пе программы. Программа реагирует на случайные события, источником которых
является пользователь, и предоставляет необходимый программный сервис. Осталь-
ные принципы проектирования GUI-интерфейса являются следствием этого факта.
(Конечно, принцип “контроль является прерогативой пользователя” не следует при-
50 Глава Процесс разработки программного обеспечения
нимать буквально—программа по-прежнему может проверять права пользователя и
запретить некоторые пользовательские действия.)
Проект базы данных определяет объекты сервера базы данных — скорее всего, ре-
ляционной (или, возможно, объектно-реляционной). Часть этих объектов представ-
ляет собой контейнеры данных (таблицы, взгляды и т.д.). Другие объекты являются
процедурами (хранимые процедуры, триггеры и т.д.)
1.3.5. Этап реализации
Реализация информационной системы включает инсталляцию приобретенного ПО
и программирование ПО, разрабатываемого под заказ. Кроме того, реализация подра-
зумевает осуществление некоторых других важных мероприятий, таких как загрузка
тестовых и производственных баз данных, тестирование, обучение пользователей,
вопросы, связанные с аппаратным обеспечением, и т.д.
Типичная организация бригады по реализации проекта ПО предполагает разде-
ление программистов на две группы: одну, ответственную за программирование кли-
ентских приложений, и другую, которая должна отвечать за программирование сер-
вера баз данных. Клиентские программы реализуют оконный интерфейс, логику при-
ложений и при необходимости вызывают программы баз данных (хранимые
процедуры). Ответственность за непротиворечивость баз данных и корректность
транзакций лежит на серверных программах.
Как раз в духе итеративной и наращиваемой разработки проект пользовательских
интерфейсов иногда подвергается значительным изменениям на этапе реализации.
Прикладные программисты могут предпочитать — в зависимости от вида реализуемых
диалоговых окон — следовать принципам разработки, предлагаемым поставщиком
GUI-интерфейса, продвигать программирование или повышать продуктивность ра-
боты пользователей.
Аналогично реализация сервера баз данных может вызвать изменения в проектных
документах. Непредвиденные проблемы, связанные с базами данных, трудности при
программировании хранимых процедур и триггеров, вопросы параллелизма, инте-
грация с клиентскими процессами, настройка производительности и т.д. — вот пере-
чень только некоторых причин, которые могут повлечь за собой необходимость мо-
дификации проекта.
1.3.6. Этап интеграции
Наращиваемая разработка предполагает наращиваемую интеграцию программных
модулей. Эта задача не так проста, как может показаться на первый взгляд. Для боль-
ших систем интеграция отдельных модулей может потребовать больше времени и
усилий, чем любой из более ранних этапов ЖЦ, включая реализацию. Еще Аристо-
тель заметил, что целое больше простой суммы частей.
Интеграция модулей должна быть тщательно спланирована в самом начале жиз-
ненного цикла ПО. Программные компоненты, подлежащие отдельной реализации,
должны быть идентифицированы на ранних стадиях анализа системы. К этому вопро-
су необходимо постоянно возвращаться, уточняя детали во время архитектурного
проектирования. Порядок реализации должен позволять как можно более плавную
наращиваемую интеграцию.
Основная трудность, связанная с наращиваемой интеграцией, заключается в суще-
ствовании взаимных обратных зависимостей между модулями. Хороший проек т си< -
1.3. Этапы жизненного цикла программного обеспечения 51
темы отличается минимальной связностью (coupling) модулей. Тем не менее, время от
времени два модуля оказываются зависимы друг от друга, так что ни один из них не
может функционировать изолированно.
Что делать, если необходимо поставить один из модулей еще до того, как другой
готов к применению? Ответ состоит в написании специальной программы для вре-
менного “заполнения бреши” так, чтобы все модули оказались интегрированными.
Программная процедура, предназначенная для имитации работы отсутствующего мо-
дуля, называется заглушкой (stubs).
В отличие от традиционных программных систем, основанных на понятии глав-
ной программы, в современных объектно-ориентированных системах, управляемых
событиями, отсутствует центральная интеллектуальная (главная) программа. Более
того, в современных системах отсутствует четко определенная интеграционная
структура. Традиционные стратегии интегрирования сверху-вниз или снизу-вверх не
применимы к современным системам.
Объектно-ориентированные системы должны быть спроектированы под интеграцию.
Каждый модуль должен быть как можно более независимым. Зависимости между мо-
дулями необходимо идентифицировать и минимизировать на этапах анализа и проек-
тирования. В идеале, каждый модуль должен образовывать один поток обработки, ко-
торый запускается в ответ на определенное требование клиента. Использования за-
глушек как операций замещения следует, по возможности, избегать. Если система
спроектирована недостаточно качественно, этап интеграции приведет к хаосу и по-
ставит под угрозу весь проект по разработке системы.
1.3.7. Этап сопровождения
Этап сопровождения наступает после успешной передачи заказчику каждого по-
следующего программного модуля и, в конечном счете, всего программного продукта.
Сопровождение — не только неотъемлемая часть жизненного цикла ПО; оно состав-
ляет его большую часть, если речь идет о времени и усилиях персонала ИТ-
подразделений, приходящихся на сопровождение. Скеч (Schach) приводит оценку, по
которой 67% времени ЖЦ приходится на сопровождение ПО [77].
Сопровождение состоит из трех различных стадий [51].
1. Поддержка эксплуатации.
2. Адаптивное сопровождение.
3. Улучшающее сопровождение.
Поддержка эксплуатации (housekeeping) связана с рутинными задачами сопровожде-
ния, необходимыми для поддержания системы в состоянии готовности к применению
пользователями и эксплуатационным персоналом. Адаптивное сопровождение
(adaptive maintenance) связано с отслеживанием и анализом работы системы, настрой-
кой ее функциональных возможностей применительно к изменениям внешней среды
и адаптацией системы для достижения заданной производительности и пропускной
способности. Под улучшающим сопровождением (perfective maintenance) понимают пере-
проектирование и модификацию системы для удовлетворения новых или существен-
но изменившихся требований.
В конечном итоге продолжение сопровождения системы становится нецелесооб-
разным, и ее следует свернуть. Сворачивание (phasing out) обычно осуществляется по при-
чинам, которые имеют мало общего с утратой ПО своей полезности:, оно, возможно, по-
52 Глава 1. Процесс разработки программного обеспечения
прежнему остается вполне пригодным для испаяьзования, однако становится непригод-
ным для сопровождения. Скеч приводит четыре причины сворачивания ПО [77].
1. Предлагаемые изменения выходят далеко за рамки ближайших возможностей
улучшающего сопровождения.
2. Система выходит из-под контроля служб сопровождения, и последствия изме-
нений невозможно предвидеть.
3. Расширение ПО в будущем невозможно из-за отсутствия надлежащей доку-
ментации.
4. Аппаратная и/или программная платформы, на которых реализована система,
подлежат замене, а видимых путей для миграции нет.
1.3.8. Планирование проекта в течение жизненного
цикла ПО
Известное изречение гласит: то, что нельзя спланировать, нельзя и осуществить.
Планирование охватывает весь жизненный цикл программного проекта. Оно начи-
нается после того, как в результате работ по системному планированию определена биз-
нес-стратегия организации, и программный проект обозначен. Проектное планирова-
ние— это деятельность, направленная на оценку комплекта поставки, затрат, рисков,
этапов и требуемых ресурсов. Оно Чакже включает выбор методов разработки, про-
цессов, средств, стандартов, бригадной организации и т.д.
Проектные планы подобны ускользающей цели. Они меньше всего напоминают
что-то раз навсегда заданное и неизменное. Проектные планы подвержены измене-
ниям на протяжении всего ЖЦ. При этом данные изменения не выходят за рамки, ус-
танавливаемые несколькими постоянными ограничениями.
В качестве типичных ограничений выступают время и деньги— каждый проект име-
ет четкий конечный срок и строго ограниченный бюджет. Одна из первых задач про-
ектного планирования состоит в оценке осуществимости проекта в условиях времен-
ных, бюджетных и прочих ограничений. Если проект осуществим, то ограничения
фиксируются документально и могут быть изменены только в рамках формальной
процедуры утверждения.
Осуществимость проекта оценивается с учетом нескольких факторов [37], [91].
Практическая осуществимость связана с возвратом к вопросам, впервые поднятым при
системном планировании, когда проект был обозначен; она связана с изучением того, как
предлагаемая система повлияет на организационные структуры, процедуры и людей.
Экономическая осуществимость связана с оценкой затрат на проект и приносимых им
выгод (известной также как анализ затрат и результатов).
Техническая осуществимость связана с оценкой практичности предлагаемых
технических решений и наличия необходимых навыков, опыта и ресурсов.
Осуществимость по срокам связана с оценкой обоснованности план-графика
выполнения проекта.
Не все ограничения известны или могут быть оценены во время открытия проек-
та. На этапе выработки требований выявляются дополнительные ограничения, кото-
рые должны подвергаться изучению с точки зрения их влияния на осуществимость
проекта. К подобным ограничениям можно отнести юридические, договорные, поли-
тические ограничения и ограничения, связанные с безопасностью.
1.3. Этапы жизненного цикла программного обеспечения 53
С учетом оценки осуществимости составляется проектный план и устанавливаются
правила управления проектом и процессом. В проектном плане находят отражение
следующие вопросы [91].
Рамки проекта.
Проектные задания.
Управление и контроль проекта.
Управление качеством.
а Метрики и измерения.
План-график проекта.
Распределение ресурсов (людских, материальных, инструментальных).
Руководство людьми.
1.3.9. Измерения в течение жизненного цикла ПО
Измерение времени и усилий, затраченных на проект, а также принятие на воо-
ружение других метрик (metrics) для проектных артефактов в действительности явля-
ется важной частью управления проектам и процессом. Несмотря на важность, в органи-
зациях с низким уровнем технологической зрелости этой частью часто пренебрегают.
Цена здесь высока. Не “измеряя” прошлого, организация не в состоянии точно пла-
нировать будущее.
Метрики обычно рассматриваются в контексте качества и сложности ПО — они
применяются в отношении качества и сложности прораммного продукта [36], [65].
Используются для измерения таких характеристик качества, как корректность, на-
дежность, продуктивность, целостность, практичность, пригодность к сопровожде-
нию, гибкость и тестопригодность. Например, надежность ПО можно оценйть с по-
мощью измерения частоты и серьезности отказов, среднего времени между отказами,
точности выходных результатов, восстанавливаемости после отказов и т.д.
Другим важным применением метрик является измерение моделей разработки
(продуктовразработки) на различных этапах ЖЦ ПО. Затем метрики используются для
оценки эффективности процесса и повышения качества работы на различных этапах ЖЦ.
К типичным метрикам, которые применяются в отношении процесса создания ПО и
могут быть приняты к использованию на различных этапах ЖЦ, относятся следую-
щие метрики.
Изменчивость требований (процент требований, которые претерпевают
изменения до завершения этапа спецификации требований). Эта метрика может
отражать трудность получения требований от заказчиков.
Изменчивость требований после этапа спецификации требований. Эта метрика
может указывать на низкое качество документального оформления требований.
Прогнозирование “мест перегрева” и “узкого горла” в системе (частота, с которой
пользователи пытаются выполнить различные функции на прототипе
программного продукта).
Объем документов, содержащих спецификации, которые генерируются CASE-
средствами, и другие более детализированные метрики, взятые из репозитория
CASE-системы, например, такие как количество классов в модели классов. Если их
54 Глава 1. Процесс разработки программного обеспечения
применить к нескольким прошлым проектам, затраты и время выполнения которых
известны, эти метрики способны обеспечить идеальную плановую “базу данных” для
прогнозирования времени и усилий, необходимых для будущих проектов.
Фиксирование статистики отказов, времени их появления, обнаружения и устранения.
Подобная статистика может отражать доскональности системы обеспечения качества,
процессов пересмотра и деятельности по тестированию ПО.
Среднее число тестов, после проведения которых тестируемая компонента
считается готовой для интеграции поставки заказчику. Эта метрика может
отражать уровень процедур отладки, используемых программистами.
1.3.10. Тестирование в течение жизненного цикла ПО
Подобно проектному планированию или измерению характеристик ПО, тестиро-
вание (testing) — это деятельность, охватывающая весь жизненный цикл ПО. Тестиро-
вание — это не просто отдельный этап ЖЦ, следующий за реализацией. После того,
как дело зашло уже довольно далеко и программный продукт реализован, приступать
к тестированию слишком поздно. Исправление ошибок, допущенных на ранних эта-
пах ЖЦ, обходится безмерно дорого [77].
Действия по тестированию должны быть тщательно спланированы. Планирова-
ние процесса тестирования начинается с установления перечня тестовых прецедентов
или тест-прецедентов (test case). Тест-прецеденты (или тест-планы) определяют шаги
тестирования, которые необходимо предпринять, чтобы попытаться “сломать” про-
граммную модель или продукт.
Тест-прецеденты должны быть определены для каждого функционального модуля
(прецедента), описанного в виде документально оформленных требований. Соотнесе-
ние тест-прецедентов с прецедентами устанавливает траекторию прослеживаемости
(traceability) между тестами и требованиями пользователей. Тестопригодность про-
граммного артефакта определяется, в частности, его прослеживаемостью.
Вполне естественно, что каждый разработчик тестирует продукт своего труда. Од-
нако у разработчиков-авторов программных артефактов их “детище” всегда на первом
месте, так что от них трудно ожидать непредвзятого отношения к результатам своей
работы.
Для более эффективного тестирования требуется привлечение независимых (по
крайней мере— относительно) тестировщиков, которые могут провести методиче-
ское тестирование. Эту задачу можно поручить SQA-группе организации (Software Qual-
ity Assurance- обеспечение качества ПО). Группа должна включать лучших разработ-
чиков организации. Их задача заключается в тестировании, а не в разработке. Затем
на SQA-группу (но не на разработчиков-авторов) возлагается ответственность за каче-
ство программного продукта.
Чем больший объем тестирования выполнен на ранних этапах разработки, тем
больше отдача. Требования, спецификации и любые другие документы (включая тексты
программ) должны быть протестированы с использованием формальных пересмотров
(formal review) (так называемого сквозного контроля (walkthrough) и инспекции (inspection)).
Формальные пересмотры — это тщательно подготовленные заседания, целью ко-
торых является анализ определенной части документации или системы. Специально
назначенный рецензент заранее изучает документ и формулирует различные вопро-
сы. Заседание решает, действительно ли поднятый вопрос вскрыл недочет, но не де-
1.4. Подходы к разработке программного обеспечения 55
лает при этом никаких попыток предложить немедленное решение проблемы. Позже
разработчик-автор обращается к выявленному дефекту. При условии, что заседание
проходит в дружественном духе, а участники избегают “указывать пальцем” на винов-
ников ошибок, совместные усилия приводят к раннему обнаружению и исправлению
многих ошибок.
После того, как программные прототипы и первые версии программного продукта
становятся доступны, предпринимается тестирование, основанное на выполнении про-
граммы (execution-based testing). Существует два основных вида тестирования, основан-
ного на прогонах.
Тестирование по спецификации (тестирование по методу “черного ящика”).
Тестирование по программному коду (тестирование по методу “прозрачного ящика”).
При тестирование по спецификации (testing to specification) сама программа рассматрива-
ется как “черный ящик”, о котором ничего не известно, за исключением того, что он
получает некоторую информацию на входе и вырабатывает некоторую информацию на
выходе. На вход программы подаются некоторые входные данные, а результирующие
данные анализируются на предмет наличия ошибок. Тестирование по спецификации
особенно полезно для выявления некорректных или упущенных требований.
При тестировании по программному коду (testing to code) программная логика подвер-
гается “сквозному просмотр/’ с целью установить, какие данные необходимо подать
на вход, чтобы испытать различные выполняемые ветви программы. Тестирование
по коду дополняет тестирование по спецификации — эти два вида тестирования на-
правлены на выявление различных категорий ошибок.
Наращиваемая разработка предполагает не только наращиваемую интеграцию про-
граммных модулей, но и наращиваемое или регрессионное тестирование (regression testing).
Регрессионное тестирование представляет собой повторное выполнение предыдущих
тест-прецедентов на том же базисном наборе данных (baseline data set) после расширения —
за счет наращивания возможностей — ранее выпущенных программных модулей. Тес-
тирование проводится в предположении, что прежние функциональные возможности
должны остаться неизменными и не должны быть нарушены за счет расширения.
Неплохим инструментом поддержки регрессионного тестирования могут служить
средства записи-воспроизведения (captureplayback tools), которые позволяют зафиксировать
взаимодействие пользователя с программой, а затем воспроизвести их без дальней-
шего вмешательства пользователя. Основная трудность регрессионного тестирова-
ния заключается в нестабильности базисного набора данных. Дело в том, что нара-
щиваемая разработка не только расширяет процедурную логику программы, но также
расширяет и (модифицирует) основные структуры данных. Программный продукт
с расширенными возможностями может заставить изменить базисный набор данных,
таким образом лишая смысла сравнение результатов.
1.4. Подходы к разработке программного
обеспечения
“Революция в программном обеспечении” вызвала ряд значительных изменений в
способах работы программных продуктов. В частности, значительно увеличились ин-
терактивные возможности программ. Задачи, выполняемые программами, и их пове-
дение могут динамически адаптироваться к запросам пользователей.
56 Глава L Процесс разработав программного обеспечения
Процедурная логика программ, написанных в прошлом на языках подобных языку
COBOL, не отличалась гибкостью и не очень-то откликалась на неожиданные собы-
тия. После запуска программа выполнялась до завершения в более или менее детер-
минированном режиме. Иногда программа могла запрашивать некоторую информа-
цию от пользователя и следовать по различным выполняемым ветвям. Однако, в об-
щем случае взаимодействие с пользователем было ограничено, а количество
различных выполняемых ветвей заранее фиксировано. Контроль оставался за про-
граммой, а не пользователем.
С появлением современного графического пользовательского интерфейса (GUI)
все кардинально изменилось. Программы на основе GUI-интерфейса управляются со-
бытиями, ход их выполнения носит случайный и непредсказуемый характер и дикту-
ется инициируемыми пользователем событиями, источником которых являются кла-
виатура, мышь и другие устройства ввода.
В среде СиИпперфейса пользователь контролирует (по большей части) выполнение
программы, а не наоборот. За кажд ым событием стоит программный объект, который зна-
ет, как обслужить данное событие при текущем состоянии хода выполнения программы.
После завершения обслуживания управление вновь возвращается к пользователю.
Различные стили программирования требуют разных подходов к разработке ПО.
При разработке традиционного ПО хоровгую службу сослужил структурный подход. Со-
временные системы на основе GUI-интерфейса требуют объектного программирова-
ния, и объектный подход является наилучшим способом проектирования таких систем.
1.4.1. Структурный подход
Структурный подход (structured approach) к разработке систем получил широкое рас-
пространение (и был признан стандартом де-факто) в 1980-х годах. Этот подход осно-
ван на двух методах: диаграммах потоков данных ( (data flow diagrams — DFD) для мо-
делирования процессов и диаграммах сущность-связь (entity relationship diagrams —
ERD) для моделирования данных.
Структурный подход является функушишеыюориеняшроваммым и рассматривает
DFD-диаграммы в качестве д вижущей силы разработки ПО. Позднее, в качестве одно-
го из непосредственных результатов широкого распространения моделей реляцион-
ных баз данных, значение DFD-диаграмм в структурной разработке снизилось, и под-
ход стал более ориентированным. на данные, и, соответственно, акцент в разработке
сместился на ERD-диаграммы.
Сочетание DFD- и ERD-диаграмм дает относительно полные модели анализа, кото-
рые фиксируют все функции и данные системы на требуемом уровне абстракции не-
зависимо от особенностей аппаратного и программного обеспечения. Затем модель
анализа преобразуется в проектную модель, которая обычно выражается в понятиях
реляционных баз данных. После этого следует этап реализации.
Структурный подход к • анализу и проектированию отличается рядом особенно-
стей, некоторые из них не очень хорошо увязываются с современными методами
конструирования ПО.
Этот подход скорее является последовательным и трансформационным, чем
итеративным подходом с наращиванием возможностей (т.е. этот подход не
способствует непрерывному процессу разработки, осуществляемому посредством
итеративной детализации и пошаговой поставки ПО с наращенными
возможностями).
1.4. Подходы к разработке программного обеспечения 57
Этот подход направлен на поставку негибких решений, которые способны
удовлетворить набор определенных бизнес-функций, но которые может быть
трудно масштабировать и расширять в будущем.
Этот подход предполагает разработку “с чистого листа” и не поддерживает
повторное использование уже существующих компонент.
Трансформационный характер структурного подхода является источником повы-
шенного риска неправильно истолковать исходные требования пользователей по хо-
ду разработки. Такой риск усиливается за счет необходимости постепенной замены
относительно декларативной семантики моделей анализа на процедурные решения
для проектных моделей и программного кода реализации (это является следствием
того, что модели анализа семантически богаче, чем базовые проектные и реализаци-
онные модели).
1.4.2. Объектно-ориентированный подход
Обыктжм^вештфовахный подход (dbjeAmented approach) к разработке систем получил
распространение в 1990-х годах. Ассоциация производителей ПО Object Management
Group утвердила в качестве стандартного средства моделирования для этого подхода
язык UML (Unified Modeling Language—Унифицированный язык моделирования).
По сравнению со структурным подходом объектно-ориентированный подход в
большей степени ориентирован на дюнные— он развивается вокруг моделей классов. На
этапе анализа для классов не требуется определять операции — только атрибуты. Воз-
растающее значение использования в языке UML прецедентов способствует незначи-
тельному смещению акцентов от данных к функциям.
Существует понимание того, что разработчики используют объектный подход
вследствие технических преимуществ объектной парадигмы, таких как абстракция,
инкапсуляция, повторное использование, наследование, передача сообщений, поли-
морфизм и т.д. Эти технические свойства могут привести к более высокому уровню
повторного использования программного кода и данных, сокращению времени раз-
работки, росту продуктивности труда программистов, повышению качества ПО,
большей понятности программ и т.д.
При всей свой привлекательности данные преимущества объектной технологии до
сих пор не нашли своего практического воплощения. Тем не менее мы продолжаем
использовать сегодня объекты и будем использовать их завтра. Одной из причин это-
го является возможность работы с новым стилем программирования — программиро-
ванием, управляемым событиями, (event-driveri),— который поддерживается современ-
ными GUI-интерфейсами.
Другой причиной популярности объектного подхода является возможность удовле-
творить требования вновь возникающих типов приложений и находить наилучшие спосо-
бы борьбы с ростом количества невыполненных заказов на приложения. К двум наиболее
важным новым категориям приложений, для которых требуется объектная технология,
относятся вычислительная обработка для рабочих групп и системы мультимедиа. Идея оста-
новить рост числа невыполненных заказов посредством концепции “помещения объек-
тов в оболочку” доказала как свою привлекательность, так и работоспособность.
Объектный подход к разработке систем следует итеративному процессу с наращи-
ванием возможностей. Единая модель (и один проектный документ) конкретизируется
на этапах анализа, проектирования и реализации — в результате успешных итераций
58 Глава 1. Процесс разработки программного обеспечения
добавляются новые детали, при необходимости вводятся изменения и усовершенст-
вования, а выпуски программных модулей с наращенными возможностями поддержи-
вают высокий уровень удовлетворенности пользователей и обеспечивают обратную
связь, необходимую для продолжения разработки модулей.
Разработка с помощью последовательной детализации становится возможной бла-
годаря том)’, что все создаваемые в ходе разработки модели (анализа, проектирования
и реализации) обладают семантическим богатством и базируются на одном и том же
“языке” — базовый словарь этих моделей существенно не отличается (классы, атрибу-
ты, методы, наследование, полиморфизм и т.'д.). Следует, однако, заметить, что если в
основу реализации положена реляционная база данных, необходимость в сложной и
связанной с риском трансформации по-прежнему сохраняется (поскольку базовая се-
мантика реляционной модели сравнительно беднее).
Объектный подход устраняет большинство из наиболее значительных недостат-
ков структурного подхода, однако, служит источником некоторых новых проблем.
Этап анализа проводится на еще более высоком уровне абстракции, и — если
серверная часть решения по реализации предполагает использование
реляционной базы данных— семантический разрыв между концепцией и ее
реализацией может быть значительным. Хотя анализ и проектирование могут
проводиться итеративно с наращиванием возможностей, в конце концов
разработка достигает этапа реализации, которая требует трансформации решения
применительно к реляционной базе данных. Если в качестве платформы
реализации используется объектная или объектно-реляционная база данных,
трансформация проекта проходит значительно легче.
Управление проектом сложно осуществлять. Менеджеры измеряют степень
продвижения разработки с помощью четко определенной декомпозиции работ,
элементов комплекта поставки и ключевых этапов. При объектной разработке с
помощью “детализации” не существует четких границ между этапами, а проектная
документация непрерывно развивается. Приемлемое решение в такой ситуации лежит
в делении проекта на небольшие модули и управлении ходом разработки за счет
частого выпуска выполняемых версий этих модулей (некоторые из этих выпусков
могут быть для внутреннего применения, а другие — поставляться заказчику).
Еще одна большая проблема применения объектного подхода связана с возрастающей
сложностью решения, что, в свою очередь, сказывается на таких характеристиках ПО,
как приспособленность к сопровождению и масштабируемость.
Сложности, связанные с объектным подходом, не влияют на тот факт, что по сло-
вам Артура Кларка “будущее нельзя повернуть вспять”. Возврата к вызывающему нос-
тальгию процедурному стилю пакетных приложений на языке COBOL нет. Все участ-
ники проектов по созданию ИС хорошо знакомы с Internet, электронной коммерци-
ей, компьютерными играми и другими интерактивными приложениями.
Новые программные приложения отличаются значительно большей сложностью
построения, и структурный подход совершенно не соответствует этой задаче. На се-
годняшний день объектно-ориентированный подход — единственный известный ме-
тод, позволяющий совладать с разработкой нового управляемого событиями отли-
чающегося высоким уровнем интерактивности ПО.
Резюме 59
Резюме
В этой главе мы рассмотрели стратегические вопросы, касающиеся процесса раз-
работки программного обеспечения. Для некоторых читателей содержимое этой гла-
вы значит не больше “родительской” нотации. Читателям, обладающим некоторым
опытом в области разработки ПО, эта глава могла дать дополнительный интеллекту-
альный заряд. По отношению ко всем читателям данная глава была задумана как вве-
дение к предстоящему более всестороннему обсуждению.
По своей природе разработка ПО ближе к ремеслу или даже искусству. Результаты
программного проекта нельзя полностью предвидеть при его начале. Основная не-
предсказуемая трудность при разработке ПО связана с участниками проекта— про-
граммный продукт должен дать участникам проекта ощутимые выгоды; в противном
случае его ждет провал. В “треугольник” факторов, обеспечивающий успех проекта,
помимо человеческого фактора входят стабильный прогресс и поддержка языка и
средств моделирования.
Цель разработки ПО — предоставить заказчику продуктивную систему. Разработке
ПО предшествует системное планирование, в ходе которого определяется, какие про*
дукты будут наиболее эффективными для организации. Существуют разные способы
осуществить системное планирование. В данной главе были рассмотрены четыре из-
вестных подхода: SWOT, VCM, BPR и ISA. Системы, поддерживающие стратегиче-
ский уровень принятия решений, приносят наибольшую выгоду. Эти же системы соз-
дают наибольшие проблемы для разработчиков.
Разработка программного обеспечения подчиняется определенному жизненному
циклу. В этой книге наибольшее внимание уделяется двум этапам жизненного цикла:
анализу и проектированию. Другие этапы включают реализацию, интеграцию и сопро-
вождение. Разработку ПО составляют и некоторые другие виды Деятельности, такие
как проектное планирование, сбор данных измерений, тестирование и управление
изменениями. Мы не относим эти виды деятельности к отдельным этапам, поскольку
они регулярно повторяются на протяжении всего ЖЦ.
В прошлом программные продукты отличались процедурным характером — запро-
граммированная процедура выполняла свою задачу более-менее последовательным и
предсказуемым образом, после чего завершалась. Структурный подход к разработке ус-
пешно использовался для производства подобных систем.
Современные программные продукты являются объектно-ориентированными— про-
грамма состоит из программных объектов, которые выполняются случайным, не-
предсказуемым образом, и программа не завершается до Тех пор, пока пользователь
не прекратит ее выполнение. Объекты “бездействуют”, ожидая наступления иниции-
рованного пользователем события, чтобы начать вычисление; для выполнения задачи
они могут запросить от других объектов предоставить им услуги, после чего снова
впадают в “спячку”, но сразу “поднимаются по тревоге” — стоит только пользователю
инициировать другое событие. Современные клиент/серверные приложения ИС,
разработанные с использованием GUI-интерфейса, являются объектно-ориентиро-
ванными, и объектно-ориентированный подход к разработке наилучшим образом
пригоден для производства таких приложений. Оставшаяся часть книги посвящена
объектно-ориентированному подходу.
60 Глава 1. Процесс разработки программного обеспечения
Щ Вопросы
В1. Исходя из своего опыта в отношении программных продуктов, как бы вы могли проин-
терпретировать замечание Фреда Брукса о том, что сущность программной инженерии
проистекает из таких свойств ПО, как сложность, податливость, изменчивость и неося-
заемость? Какое объяснение вы могли бы дать этим четырем факторам? В чем про-
граммная инженерия отличается от традиционных инженерных дисциплин, таких как
строительство или машиностроение?
В2. Мы пытались доказать, что производство ПО — это искусство или ремесло. В качестве под-
тверждения этого тезиса можно привести высказывание о том, что “Искусство — это союз ме-
жду Богом и художником, и чем меньше вклад ывает в него художник, тем лучше" (Андре Жид).
Какой урок мргутвынрсти из этого высказывания разработчики ПО? Согласны ли вы сним?
ВЗ. Объясните разницу между программными пакетами и компонентами. Какое будущее, по-
вашему, ожидает эти две технологии?
В4. Вспомните опред еление участника предприятия. Относятся ли продавец ПО и специалист
по технической поддержке к участникам предприятия? Объясните свою точку зрения.
>В5. Какой уровень технологической зрелости требуется д ля организации, чтобы овладеть
кризисной ситуацией? Объясните свою точку зрения.
Вб. В ходе объяснения SWOT-подхода к системному планированию мы заметили, что “верно
сформулированная миссия отводит главное место потребностям клиентов, а не товарам
или услугам, которые предоставляет организация*. Пожалуйста, объясните и проиллюст-
рируйте, каким обрезом нацеливание формулировки миссии на определенные товары
или услуги может привести к утрате, основной цели системного планирования — дости-
жения эффективности.
В7. Реинжиниринг бизнес-процессов (BPR) проводит ясное различие между бизнес-
лроцессом и бизнес-функцией. В чем заключается это различие? Приведите пример
бизнес-процесса, который разорван по горизонтали по всей организации.
В8. Сравните концепции цепочек ценности и бизнес-процесса.
В9. Почему понимание метода ISA (архитектура информационной системы) важно для сис-
темной разработки?
В10. Назовите три уровня управления организацией. Рассмотрите банковское приложение,
которое предназначено для отслеживания стереотипов поведения владельцев кредитных
карточек, чтобы автоматически блокировать карточку, если банк заподозрит злоупотреб-
ление (кража, подделка и т.д.). Какой уровень управления поддерживает подобное при-
ложение? Обоснуйте свое заключение.
В11. Объясните разницу между этапами определения требований и разработки спецификации.
В12. Объясните взаимосвязь двух этапов проектирования (архитектурное проектирование и
детализированное проектирование} с первыми двумя этапами жизненного цикла — эта-
пом определения требований и этапом разработки спецификации.
В13. Что вы понимаете под соглашением, рбъектно-ориентированные системы должны про-
ектироваться под интеграцию"?
В14. Системное планирование и измерения ПО существенно связаны. Объясните этот тезис.
В15. Объясните взаимосвязь между прослеживаемостью и тестопригодностью.
В16. Какой основной метод моделирования применяется при структурном под ход е к разработке?
В17. Каковы основные причины сдвига от структурного под хода к проектированию объектно-
ориентированному?
Основания анализа требований
В качестве основного метода создания ПО в данной книге принят объектно-
ориентированный подход. Этот подход не дается легко, поскольку объектно-
ориентированная разработка требует хорошего знания объектной технологии. Без глубо-
кого понимания тонкостей объектной технологии разработчик не сможет правильно
применять язык UML в качестве универсального и привычного средства моделирования.
Основная трудность изучения объектной технологии связана с отсутствием оче-
видной отправной точки и ясного направления исследования. Это не хорошо извест-
ные нам подходы к изучению систем “сверху-вниз” или “снизу-вверх”. По существу,
рассматриваемый подход представляет собой что-то наподобие “все время со среди-
ны”. Не зависимо от того, насколько мы продвинулись в процессе изучения, кажется,
что мы всегда находимся посередине этого процесса (поскольку все время возникают
новые вопросы). Можно считать, что в процессе изучения достигнут первый успех,
когда читатель осознает глубинный смысл того факта, что в объектно-ориентирован-
ной системе “все есть объект”.
Данная глава направлена на то, чтобы дать читателю необходимый базовый уро-
вень знаний об изучаемом предмете прежде, чем приступить к его более глубокому
изучению. В этой главе разъясняется, выполнение каких предварительных условий
необходимо для анализа требований, при этом одновременно используются два спо-
соба подачи материала. Во-первых, здесь объясняются основы объектной технологии.
Во-вторых, проводится “обучение на примерах” и дается наставление по моделирова-
нию анализа с использованием приложения lntemet-магазин, относящегося к известной
прикладной области — “Электронная торговля”.
2.1. Основы объектной технологии
Для объяснения сути объектной ориентации информационных систем воспользу-
емся аналогией с объектами реального мира. Окружающий мир состоит из объектов
(object), пребывающих в состоянии (state), которое определяется текущими значениями
атрибутов объекта.
Например, кружка на моем столе находится в состоянии filled (наполнена), по-
скольку она приспособлена для хранения жидкостей и в ней все еще есть кофе. Когда
в ней нет больше кофе, состояние кружки можно определить как empty (пуста). Если
она упадет на пол и разобьется, она перейдет в состояние broken (разбита).
62 Глава 2. Основания анализа требований
Моя кофейная чашка, конечно, пассивна — она не обладает собственным поведени-
ем (behavior). Однако, этого нельзя сказать о моей собаке или эвкалиптовом дереве за
моим окном. Моя собака лает, дерево растет и т.д. Итак, некоторые объекты реально-
го мира обладают поведением.
Все объекты реального мира обладают также идентичностью (identity)— постоянным
свойством, с помощью которого мы отличаем один объект от другого. Если на моем столе
стоят две чашки из одного набора, я могу сказать, что они одинаковые, но не идентичные.
Чашки одинаковые, потому что значения их свойств совпадают (они одинакового размера
и формы, черного цвета и пустые). Однако, на объектноориентированном языке они не
идентичны, поскольку их две, и у меня есть выбор, которую из них использовать.
Реальные объекты, обладающие тремя свойствами (состояние, поведение, иден-
тичность), образуют системы с естественным поведением. Естественные системы безус-
ловно являются самыми сложными системами из всех известных. Никакая компьютер-
ная система не может сравниться по сложности с животным или заводом.
Несмотря на сложность, естественные системы способны работать: они демонст-
рируют интересное поведение, могут приспосабливаться к внешним и внутренним
изменениям, могут эволюционировать со временем и т.д. Вывод очевиден. Наверное,
мы должны конструировать искусственные системы с помощью моделирования
структуры и поведения естественных систем (сравн. [55]).
Искусственные системы являются моделью реальности. Кофейная чашка на экра-
не моего компьютера всего лишь модель реальной “сущности” так же, как собака или
эвкалиптовое дерево на моем экране. Кофейная чашка может быть, таким образом,
смоделирована с помощью поведенческих свойств. Она может, к примеру, упасть на
пол, если ее уронить. Действие “падения" можно смоделировать как поведенческую
операцию (operation) чашки. Еще одним логическим “действием” чашки может быть
операция “разбиться” при ударе об пол. Большинство, если не все, объекты в компью-
терной системе “оживают” — они обладают поведением.
2.1.1. Объект-экземпляр
Объект — это экземпляр (instance) некоей “сущности”. Он может быть одним из мно-
жества экземпляров одной и той же “сущности”. Моя Чашка — экземпляр множества
всевозможных чашек.
Общее описание “сущности” называется классом (class). Поэтому объект является
экземпляром класса. Однако, как мы увидим в разделе 2.1.6, класс также может нуж-
даться в конкретизации — он может быть объектом. Поэтому нам необходимо разли-
чать объект-экземпляр (instance object) и объект-класс (class object).
Для краткости объект-экземпляр часто называют объектом или экземпляром. Название
“экземпляр объекта” сбивает с толку. Объектно-ориентированная система состоит из
взаимодействующих объектов. В объектно-ориентированной системе нет ничего, кроме
объектов, будь-то объект экземпляра (объект-экземпляр) или объект класса (объект-класс).
В качестве отступления и в продолжение темы заметим, что мы не настаиваем на
использовании термина “класс объекта”. Конечно, класс представляет собой шаблон
для объектов с аналогичными атрибутами и операциями, но сам класс также может
быть конкретизирован в виде.объекта (и мы не хотим называть такое образование
“объект класса объекта”).
2.1. Основы объектной технологии 63
2.1.1.1. Объектная нотация
В языке UML объект обозначается прямоугольником с двумя отделениями. Верх-
нее отделение содержит имя объекта и имя класса, которому принадлежит объект.
Синтаксис этой конструкции выглядит так:'
objectname: classname.
Нижнее отделение содержит список имен атрибутов и значений. С помощью этого,
синтаксиса можно также показать типы атрибутов:
attributename: type = value.
На рис. 2.1 показан объект Course (Дисциплина) с именем cl. Объект обладает
двумя атрибутами. Типы атрибутов не показаны — они заданы в определении класса.
cl: Course
course_number= СОМР227
course_name = R equirements Analysis and System Design
Рис. 2.1. Объект-экземпляр
Важно иметь в виду, что объектная нотация не предусматривает в обозначении
объекта особого “отделения” для перечня операций, которые может выполнять объ-
ект-экземпляр. Это связано с тем, что операции, выполняемые всеми объектами-
экземплярами, идентичны, и поэтому хранить их в каждом объекте-экземпляре было
бы накладно. Операции можно хранить в объекте-классе или же можно связать их с
объектами-экземплярами другими средствами (реализованными в ПО базовой объ-
ектно-ориентированной системы).
2.1.1.2. Как объекты кооперируются
Количество объектов определенного класса может быть очень большим. Показать
большое количество объектов на диаграмме нереально, а иногда просто невозможно.
Объекты изображаются только для того, чтобы привести пример системы в опреде-
ленный момент времени или проиллюстрировать, каким образом они кооперируются
(collaborate) с течением времени при выполнении определенных задач. Например,
чтобы упорядочить товары, может потребоваться установить кооперацию между объ-
ектом Stock (Склад) и объектом Purchase (Покупка).
Системные задачи выполняются объектами, которые активизируют операции
(поведение) друг друга. Мы говорим, что они обмениваются сообщениями (message). Со-
общения запускают операции на объектах, которые могут приводить к изменению со-
стояний объектов и вызывать другие операции.
Рис. 2.2 иллюстрирует поток сообщений между четырьмя объектами. Скобки после
имени сообщения указывают на то, что сообщение может принимать параметры
(аналогично вызову функции в традиционном программировании). Объект Order
(Заказ) предписывает объекту Shipment (Поставка) доставить заказ. Для этого объект
Shipment инструктирует объект Stock о необходимости вычесть соответствующее
количество товаров. Затем объект Stock анализирует новый уровень запаса и, если
оп оказывается ниже определенного значения, предписывает объекту Purchase сде-
лать повторный заказ дополнительного объема товаров.
64 Глава 2. Основания анализа требований
Хотя приведенное объяснение кооперации объектов выглядит как последовательность
видов деятельности, а сообщения даже пронумерованы, в общем случае на порядок, в ко-
тором активируются объекты, не накладывается строгих ограничений. Например, сооб-
щения analyzeStockLevels (проанализировать уровни запаса) и reorderProducts
(повторить заказ товара) могут выполняться в любой последовательности, возможно, не-
зависимо от сообщений shipOrder (доставить заказ) и subtractProduct (уменьшить
количество товара). Поэтому в дальнейшем при рассмотрении кооперации объектов на
уровне реализации мы откажемся от нумерации сообщений (раздел 6.2).
Рис. 2.2. Кооперация объектов
2.1.1.3. Как объекты идентифицируют друг друга
Вопрос состоит в том, каким образом объект узнает об идентичности другого объ-
екта, которому требуется отправить сообщение. Каким образом объект Order узнает
свой объект Shipment так, чтобы сообщение shipOrder попало к своему адресату?
Ответ заключается в том, что каждому объекту при создании присваивается
идентификатор объекта (object identifier— ОН)). Идентификатор объекта (OID) представля-
ет собой дескриптор (handle) объекта — уникальный номер, который остается с объектом
на протяжении всего времени его существования. Если объекту X необходимо отпра-
вить сообщение объекту Y, объект X каким-либо образом должен узнать OID объекта Y.
На практике для установления связи по OID между объектами существует два под-
хода, каждому из которых соответствует определенный тип связи.
Постоянная связь по OID.
Временная связь по OID.
Различие между этими видами связи определяется продолжительностью существо-
вания объекта. Время жизни некоторых объектов не превышает времени выполнения
программы — они создаются программой и уничтожаются во время выполнения про-
граммы или по ее завершении. Это так называемые временные объекты (transient object).
Другие объекты “переживают” выполнение программы — после завершения програм-
мы они запоминаются в долговременной дисковой памяти и доступны при следующем
выполнении программы. Это так называемые постоянные объекты (persistent object).
2.1. Основы объектной технологии 65
(Временные объекты называют также короткоживущими, а постоянные— долгоживу-
щими, постоянного хранения или энергонезависимыми. Последнее название связано с тем,
что объекты этого типа не исчезают при отключении питания компьютера, сохраня-
ясь в энергонезависимой памяти, как правило, на дисковых устройствах. Прим, ред.)
2.1.1.3.1. Постоянная связь
Постоянная связь (persistent link) — это ссылка на объект (или множество ссылок на объ-
екты), принадлежащая одному из объектов, хранимых в долговременной памяти, кото-
рая связывает этот объект с другим объектом в долговременной памяти (или со множе-
ством других объектов). Поэтому, для установления постоянной связи объекта Course
(Курс) с его объектом Teacher (Преподаватель) объект Course должен содержать ат-
рибут связи, значение которого равно OID объекта Teacher. Описанная связь постоян-
на, поскольку OID физически хранится в объекте Course, как показано на рис. 2.3.
Ref&*)(
cl: Course
course_number= COMP227
course_name= Requirements Analysis and System Design
teacher identity= Ref@#$%
Рис. 2.3. Реализация постоянной связи
OID объекта cl помечен здесь как Ref&*) (. Объект содержит атрибут связи под име-
нем teacher. Данный атрибут принадлежит типу identity. Его значение равно магиче-
скому числу Ref #$ % —адресу дисковой памяти, где постояннохранитсяобъектТеасЬег.
После того, как объекты Course и Teacher перемещаются в память программы,
значение атрибута teacher будет “втянуто” в указатель памяти, в результате устанав-
ливается кооперация между объектами на уровне памяти. (Выражение “втягивать”
(swizzling, по англ. букв, “тянуть коктейль”) — это не термин языка UML, он
используется в объектных базах данных (см. раздел 6.2), где перемещение объектов
между' долговременной и оперативной памятью довольно частое явление.)
На рис. 2.3 показана типичная реализация постоянной связи. Однако, связи между
объектами для случая моделирования с помощью языка UML показаны на рис. 2.4.
Связи представляются как экземпляры ассоциации (instances of association) между объек-
тами Course и Teacher.
Обычно кооперативные связи допускают передвижение (navigation) в обоих направ-
лениях. Каждый объект Course связан со своим объектом Teacher, а объект Teacher
может привести к объектам Course. Изредка допускается передвижение только в од-
ном направлении.
После того как объект связан с другим объектом на постоянной основе, он может от-
править по этой связи сообщение, чтобы запросить у другого объекта сервис (service). Это
значит, что объект вызывает операцию на другом объекте за счет отправки ему сообще-
ния. При типичном сценарии для указания объекта отправитель использует программ-
ную переменную, содержащую значение связи (значение OID) этого объекта.
Например, сообщение, отправленное объектом Teacher для того, чтобы опреде-
лить имя объекта Course, может иметь следующий вид:
crs-ref.getCourseName(out crs_name)
66 Глава 2. Основания анализа требований
В приведенном примере определенный объект класса Course, который будет вы-
полнять операцию getCourseName, указывается текущим значением переменной
связи crs_ref. Результирующий (out) аргумент (crs name) представляет собой пе-
ременную, значение которой инициализируется с помощью значения, возвращаемого
операцией getCourseName, реализованной в классе Course.
Рис. 2.4. Постоянные связи в объектной UML-модели
2.1.1.3.2. Временная связь
Что если мы не определили постоянные связи между объектами Course и
Teacher, но нам по-прежнему требуется отправить сообщение от объекта tl к объек-
ту cl для вызова операции getCourseName? Прикладная программа должна обладать
другими средствами для установления идентичности объекта cl и создать временную
связь от объекта 11 к объекту cl [70].
К счастью, в распоряжении программиста имеется много средств, способных
обеспечить инициализацию переменной crs_name с помощью OID объекта cl, рези-
дентно находящегося в памяти. Для начала заметим, что, возможно, связь между объ-
ектами cl и tl была установлена в программе раньше, и переменная crs_name хра-
нит правильный OID. Например, программа выполнила операцию поиска с исполь-
зованием атрибута занятости преподавателя tl и расписания курсов и определила,
что преподаватель tl должен вести курс cl.
Альтернативная возможность состоит в том, что программа имеет доступ к посто-
янно хранимой таблице, которая отображает номера курсов на имена преподавате-
лей. Затем программа может выполнить поиск на объектах Course, чтобы отыскать
все курсы, читаемые преподавателем tl, и попросить пользователя определить курс
(т.е. объект Course), которому должно быть отправлено сообщение getCourseName.
Возможно также, что задача программы как раз и состоит в создании объектов для
курсов и преподавателей перед тем, как запомнить их в базе данных. Между соответст-
вующими объектами нет постоянных связей, но пользователь вводит информацию та-
ким образом, что каждый курс четко определяет ответственного за него преподавателя.
Затем программа может запомнить временную связь в программной переменной (такой
как crs-ref), а эту переменную можно позднее использовать (во время выполнения
этой же программы) для отправки сообщений между объектами Teacher и Course.
2.1. Основы, объектной технологии 67
Короче говоря, существуют как программные, так И управляемые пользователем
методы установления временных связей между объектами, которые не связаны по-
стоянно с помощью ассоциации между соответствующими классами. Временные связи—
зто программные переменные, которые содержат значения OID. объектов, находя-
щихся в текущий момент в оперативной памяти. Отображение (“втягивание”) между
временными и постоянными OID должно быть прерогативой базовой программной
среды, например, такой как система управления объектной базой данных.
2.1.2. Класс
Класс (class) — это дескриптор множества объектов, обладающих одинаковым набором
атрибутов и операций. Он служит в качестве шаблона (template) для создания объектов. Каж-
дый объект, созданный по шаблону, содержит значения атрибута, соответствующие типу
атрибута, определенному в классе, и может вызвать операции, определенные в классе.
Графически класс представляется в виде прямоугольника с тремя отделениями,
разделенными горизонтальными линиями, как показано на рис. 2.5. Верхнее отделе-
ние хранит имя класса. Среднее отделение содержит объявления всех атрибутов клас-
са. Нижнее отделение содержит определения операций.
2.1.2.1 Атрибуты
Атрибут представляет собой пару тип-значение. Класс определяет типы атрибутов.
Объекты содержат значения атрибутов. Рис. 2.6 иллюстрирует два класса с определе-
ниями имен и типов принадлежащих им атрибутов. ‘
Тип атрибута может быть встроенным элементарным типом (primitive type) или дру-
гим классом. Элементарный тип — это непосредственно распознаваемый и поддержи-
ваемый базовой объектно-ориентированной средой тип данных. Все типы атрибутов,
показанных на рис. 2.6, обозначают элементарные типы.
Class name
Attributes
Operations ()>
Рис. 2.5. “Отделения” в представлении класса
_______Course_______
course_number: String
course name: String
Order
order_number: Integer
order_date: Date
ordetjzalue; Currency
Рис. 2.6. Атрибуты
2.1.2.1.1. Тип атрибута, обозначающий класс
Тип атрибута также может обозначать класс. Применительно к конкретному объ-
екту' некоторого класса подобный атрибут содержит значение идентификатора объ-
екта (OID), указывающее на объект другого класса. В UML-моделях анализа атрибуты,
68 Глава 2. Основания анализа требований
типы которых обозначают классы, не приводятся в среднем “отделении” представле-
ния класса (в отличие от примитивных типов). Вместо этого они представляются с
помощью ассоциации (association) между классами. На рис. 2.7 показана подобная ассо-
циация между двумя классами.
Два имени на ассоциативной линии (the shipment ([конкретная] поставка) и
the_order ([конкретный] заказ)) представляют так называемые ролевые имена. Ро-
левое имя (rolename) определяет значение для одного из концов ассоциации и исполь-
зуется для перемещения к объекту другого класса в ассоциации.
В реализованной системе ролевое имя (на противоположном конце ассоциации)
становится атрибутом класса, тип которого является классом, на который указывает
ролевое имя. На рис. 2.8 показано, как выглядят два класса с рис. 2.7 после того, как
они были реализованы.
Рис. 2.7. Ролевые имена, обозначающие
классы (модель анализа)
________Order_________
order_number: Integer
order_date: Date
ordervalue: Currency
the shipment: Shipment
Shipment
the_order: Order
shipQrderQ
Puc. 2.8. Атрибуты, обозначающие
классы (модель реализации)
2-1.2.1.2. Видимость атрибутов
Как отмечалось в разделе 2.1.1.2, объекты взаимодействуют с помощью отправки
друг другу сообщений. Сообщение вызывает операцию класса. Операция обслуживает
запрос вызывающего объекта с помощью доступа к значениям атрибутов в своем соб-
ственном объекте. Чтобы подобный сценарий стал возможен, операции должны быть
видимы (visible) внешним объектам (сообщения должны “увидеть” операции). Говорят,
что подобные операции обладают открытой видимостью (public visibility).
В чисто объектно-ориентированной системе (примером которой может служить
среда программирования языка Smalltalk) большинство операций относится к откры-
тым (public), а большинство атрибутов— к закрытым (private). Значения атрибутов
скрыты от других классов. Объекты одного класса могут только затребовать услугу
(операцию), опубликованную в открытом интерфейсе другого класса. Им не разреша-
ется непосредственно манипулировать атрибутами другого объекта.
2.1. Основы объектной технологии 69
Мы говорим, что операции инкапсулируют (encapsulate) атрибуты. Заметим, однако,
что инкапсуляция применима к классам. Один объект не может скрыть (инкапсули-
ровать) ничего, кроме другого объекта того же класса.
Видимость обычно обозначается с помощью символов плюс и минус:
+ для открытой видимости;
- для закрытой видимости.
В некоторых CASE-средствах эти символы заменены на графические пиктограм-
мы. На рис. 2.9 продемонстрировано два графических представления для обозначе-
ния видимости атрибутов.
________Purchase________
-purchase_number: String
-purchase_dste: Date
-purdiase yalue: Currency
+reorderProducts()
Purchase
О purchase_number: String purchase_date: Date purchase.value: Currency
Щ reorderProducts()
Puc. 2.9. Закрытые атрибуты и открытые операции
2.1.2.2. Операции
Объект содержит данные (атрибуты) и алгоритмы (операции) для работы с этими
данными. Операция объявляется в классе. Процедура, реализующая операцию, назы-
вается методом (method).
Операция (или метод, если быть точным) вызывается с помощью отправленного
ей сообщения. Имя сообщения и имя операции совпадают. Операция может содер-
жать список параметров, которым в вызове сообщения могут быть присвоены опре-
деленные значения, и может возвращать значение вызывающему объекту.
Имя операции вместе со списком типов формальных аргументов называется
сигнатурой (signature) операции. Сигнатура в пределах класса должна быть уникальной.
Это значит, что класс может обладать множеством операций с одним и тем же име-
нем, при условии, что списки типов параметров этих операций отличаются.
2.1.2.2.1. Операции — основа совместной работы объектов
Объектно-ориентированная программа выполняется, реагируя на случайные собы-
тия, которые инициирует пользователь. Источником событий выступает клавиатура,
щелчки мышью, пункты меню, кнопки действий и любые другие входные устройства.
Инициированное пользователем событие преобразуется в сообщение, отправляемое объек-
ту. Для выполнения задания многим объектам требуется действовать совместно. Объек-
ты “сотрудничают” с помощью вызова операцийдругих объектов (см. разд. 2.1.1.2).
На рис. 2.10 показаны операции классов, необходимые для поддержки совместных
действий объектов, приведенных на рис. 2.2. Каждое сообщение на рис. 2.2 запраши-
вает операцию класса, обозначенного как адресат сообщения. В данном простом
примере у класса Order операции отсутствуют. Объект класса Order инициирует со-
вместную работу объектов. Объект Order (Заказ) предписывает объекту Shipment
(Поставка) осуществить его “поставку”. В результате поставки (т.е. выполнения заказа
за счет товаров со склада) может потребоваться пополнение запаса новыми товарами.
70 Глава 2. Основамияанализа. требований
Order
Shipment
HshlpOrderf)
Stock
subtractProducts()
Ц analyzeStockLevelsf)
Purchase
В reorderProducts()
Puc. 2.10. Операции служат основой совместных
действий объектов
2.1.2.2.2. Видимость операций
Принципы видимости операций не отличаются от принципов видимости атрибу-
тов (см. разд. 2.1.2.1.2). Видимость операции определяет, является ли операция ви-
димой объектам классов, отличных от класса, который определяет операцию. Если
она видима, то ее видимость является открытой. В противном случае она будет
закрытой. Пиктограммы перед именами операций на рис. 2.10 обозначают откры-
тую видимость.
Как правило, большинство операций объектно-ориентированной системы обла-
дают открытой видимостью. Чтобы объект мог предоставить сервис внешнему ми-
ру, операция “обслуживания” должна быть видима. Однако, большинство объектов
имеют также несколько внутренних операций “местного” значения. Видимость этих
операций должна быть закрыта. Они доступны только объектам класса, в котором
они определены.
Следует различать видимость операции и область действия (scope) операции. Опе-
рацию можно вызвать на объекте-экземпляре (см. разд. 2.1.1) или же на объекте-
классе (см. разд. 2.1.6). В первом случае говорят, что операция обладает областью
действия экземпляра. Во втором случае — областью действия класса. Например, опера-
ция, предназначенная для отыскания возраста работника, обладает областью дей-
ствия экземпляра, а операция вычисления среднего возраста всех работников обла-
дает областью действия класса.
2.1.3. Ассоциации
Ассоциация (association) представляет собой один из видов отношений между класса-
ми. Помимо ассоциации существуют такие виды отношений, как обобщение
(generalization), агрегация (aggregation), зависимость (dependency) и некоторые другие.
Отношение ассоциации устанавливает связь между объектами данных классов. Объек-
ты, которым требуется взаимодействовать друг с другом, могут использовать установлен-
ную связь. Обычно сообщения между объектами отправляются по ассоциативной связи.
На рис. 2.11 показано отношение между классами Order и Shipment под именем
OrdShip. Это отношение дает возможность “отправить” (или связать) объект Order
(Заказ) более, чем одному объекту Shipment (Поставка) (обозначенному звездочкой *).
Также и объект Shipment может осуществить операцию “поставки” (быть связанным с)
более, чем одного объекта Order.
2.1.Основы объектной технологии 71
Рис. 2.11. Пример ассоциации
2.1.3.1. Порядок ассоциации
Порядок ассоциации (association degree) определяет количество классов, соединенных
с помощью ассоциации. Наиболее часто встречаются ассоциации второго порядка. Та-
кая ассоциация называется бинарной ассоциацией. Ассоциация, показанная на рис. 2.11,
является бинарной.
Ее можно также определить на единственном классе. Тогда она называется унарной
(unary) (или сингулярной (singular)) ассоциацией [51]. Унарная ассоциация устанавливает
связь между объектами одного класса.
На рис. 2.12 показан типичный пример унарной ассоциации. Этот пример фикси-
рует иерархическую организационную структуру. Объект Employee (Сотрудник)
“работает” “под руководством” (managed_by) другого объекта Employee или в отсут-
ствие руководства с чьей-либо стороны (это может быть, к примеру, генеральный ди-
ректор, которым никто не руководит). Объект Employee “является руководителем”
(manager_of) для других сотрудников до тех пор, пока не оказывается в самом низу
служебной лестницы и никем не “руководит”.
Возможны также ассоциации третьего порядка (тернарные (ternary) ассоциации), хо-
тя их применение не рекомендуется [51].
managed_by
I0-1
Employee
manager_of
0..*
Рис. 2.12. Пример унарной ассоциации
2.1.3.2. Кратность ассоциации
Кратность ассоциации (association multiplicity) определяет, сколько объектов могут
занимать позицию, указанную ролевым именем. Кратность говорит о том, сколько объ-
ектов целевого класса (указываемых ролевым именем) может быть ассоциировано с
одним объектом исходного класса.
72 Глава 2. Основания анализа требований
Кратность обозначается в виде диапазона целых чисел nl.. п2. Число nl опреде-
ляет минимальное количество связываемых объектов, а п2 — максимальное количест-
во (если мы не знаем точного максимального целочисленного значения, то вместо
максимального количества может быть подставлена звездочка *). Если точное мини-
мальное количество заранее неизвестно, но мы зиаем, что в отношении может участ-
вовать несколько объектов, этот параметр можно вообще не указывать (подобно тому,
как показано на рис.2.11).
Наиболее часто встречаются следующие значения кратности:
0. .1
0. .»
На рис. 2.13 показаны две ассоциации на объектах классов Teacher (Преподаватель)
и Courseoffering (Предлагаемый курс). Одна из ассоциаций фиксирует закрепление
преподавателей за текущими учебными курсами. Другая определяет, кто из преподава-
телей отвечает за учебный курс. Преподаватель может вести несколько учебных курсов
или не вести ни одного (например, если преподаватель в отъезде). Учебный курс ведут
один или несколько преподавателей. Один из этих преподавателей отвечает за курс. В
общем случае преподаватель может отвечать за несколько курсов или не отвечать вовсе.
Один и только один преподаватель руководит учебным курсом.
Рис. 2.13. Кратность ассоциации
В языке UML термин "кратность” является очень емким. Минимальная кратность,
равная “нулю” или “единице”, может рассматриваться как еще одно семантическое
понятие, называемое принадлежностью (membership) или участием (participation) [51].
“Нулевая” минимальная кратность означает необязательную принадлежность объекта ас-
социации. “Единичная” кратность означает обязательную принадлежность. Например,
предлагаемый курс обучения (объект Courseoffering) должен проводиться под ру-
ководством преподавателя (объект Teacher).
Свойство принадлежности само по себе обладает любопытными семантическими
особенностями. Например, данная обязательная принадлежность может дополни-
тельно означать, что принадлежность является фиксированной, т.е. если объект связан
с целевым объектом в ассоциации, он не может быть повторно связан с другим целе-
вым объектом в той же ассоциации.
2.1. Основы объектной технологии 73
2.1.З.З. Ассоциативная связь и объем ассоциации
Ассоциативная связь представляет собой экземпляр ассоциации. Это кортеж (tuple)
ссылок на объекты. Кортеж может быть набором (set) ссылок или списком (list)
(упорядоченным множеством) ссылок. В общем случае кортеж может содержать толь-
ко одну ссылку. Как рассматривалось выше, связь также представляет ролевое имя.
Объем (extent) ассоциации — это количество связей в наборе.
На рис. 2.14 представлена конкретная реализация ассоциации OrdShip, показан-
ной на рис. 2.11. На рис. 2.14 представлено пять связей. Следовательно, объем ассо-
циации равен пяти.
Понимание сущности ассоциативной связи и объема ассоциации важно для обще-
го представления об ассоциации, однако, ассоциативные связи и объемы ассоциаций
не предназначены для моделирования, их нельзя получить во время выполнения про-
граммы или каким-либо образом получить к ним явный доступ.
Рис. 2.14. Кратность ассоциации
2.1.3.4. Ассоциативный класс
Иногда ассоциация обладает своими собственными атрибутами (и/или операция-
ми). В качестве модели подобной ассоциации необходимо использовать класс, по-
скольку атрибуты могут быть определены только в классе. Каждый объект
ассоциативного класса обладает значениями атрибутов и связями с ассоциированными
классами. Поскольку ассоциативный класс является классом, он может быть ассоции-
рован с другими классами модели обычным способом.
На рис. 2.15 показан ассоциативный класс Assessment (Оценка). Объект класса
Assessment хранит список баллов, общий балл и оценку, полученную студентом
(Student) по предлагаемому курсу (Courseoffering).
Рис. 2.15. Ассоциативный класс
74 Главай. Основанняанализатрёбований
Атрибут mark (балл) имеет тип List (Number). Это так называемый
параметризованный тип (parameterized type). Number представляет собой параметр класса
List, где List (Список) определяет упорядоченное множество значений. Атрибут
mark содержит список всех баллов, полученных студентом по данному курсу. То есть,
если студент “Фрэд” проходит курс обучения по дисциплине “СОМР227”, со временем
заполняется список (упорядоченное множество) баллов, полученных им в ходе обу-
чения по этому курсу. Этот список баллов запоминается в объекте Assessment, кото-
рый представляет собой ассоциацию между объектами “Фрэд” и “СОМР227”.
2.1.4. Агрегация и композиция
: Агрегация (aggregation) — это отношение вида часть-целое между классом, который
представляет собрание компонент (класс-супермножество (superset class)), и классами, пред-
ставляющими компоненты (классы-подмножества (subset class)). Класс-супермножество со-
держит один или более классов-подмножеств. Свойство включения может быть силь-
ным (агрегация по значению (aggregation by value)) или слабым (агрегация по ссылке
(aggregation by reference)). В языке UML агрегация по значению называется композицией
(composition), а агрегация по ссылке называется просто агрегацией.
С точки зрения системного моделирования агрегация представляет собой особый
случай ассоциации, обладающей дополнительной семантикой. В частности, агрегация
обладает свойствами транзитивности и асимметрии. Транзитивность означает, что ес-
ли класс А содержит класс В, а класс В содержит класс С, то класс А содержит класс С.
Асимметрия означает, что если А содержит В, то В не может содержать А.
Композиция обладает дополнительным свойством зависимость по существованию
(existence dependency). Объект класса-подмножества не может существовать в отсутствие
связи с объектом класса-супермножества. Отсюда следует, что если объект супермно-
жества удален (уничтожен), объекты его подмножеств также удаляются.
Композиция обозначается заполненным ромбовидным “украшением” на конце ас-
социативной связи, присоединенной к классу-супермножеству. Агрегация, не являю-
щаяся композицией, помечается незаполненным ромбом. Заметим, однако, что пус-
той ромб можно также использовать, если в ходе моделирования вопрос о том, явля-
ется ли агрегация композицией или нет, следует оставить открытым.
Рис. 2.16. Композиция и агрегация
2.1. Основы объектной технологии 75
На рис. 2.16 слева показана композиция, а справа — обычная агрегация. Всякий
объект Book (Книга) является композицией объектов Chapter (Глава), а всякая глава
(объект Book) — композицией разделов (объектов Section). Объект Chapter не об-
ладает собственной независимой жизнью; он существует только в пределах объекта
Book. Этого же нельзя сказать об объектах BeerBottle (Пивная бутылка). Объект
может существовать вне контейнера — объекта Crate (Ящик).
2.1.5. Обобщение
Обобщение {generalization} представляет собой видовое отношение между более об-
щим классом {суперкласс или родительский класс) и боЛёё Специфическим‘видом’класса
{подкласс или дочерний класс). Подкласс является видом суперкласса. Там, где допусти-
мо использование суперкласса, может использоваться и объект подкласса.
Обобщение делает невозможным переопределение уже заданных свойств. Атрибу-
ты и операции, уже определенные для суперкласса, могут повторно использоваться в
подклассе. Говорят, что подкласс наследует {.inherit) атрибуты и методы его родитель-
ского класса. Обобщение способствует пошаговой спецификации, использованию
общих свойств разными классами и лучшей локализации изменений.
Обобщение изображается в виде незаполненного треугольника на конце линии
отношения, присоединенной к родительскому классу. На рис. 2.17 Person (Личность)
является суперклассом, a Employee (Сотрудник) — подклассом. Класс Employee на-
следует все атрибуты и операции класса Person. Наследуемые свойства явно не пока-
заны в прямоугольнике, обозначающем подкласс, — отношение обобщения отодвига-
ет наследование на задний план.
Обратите внимание, что наследование применимо к классам, а не объектам. Оно
применимо по отношению к типам, а не значениям. Класс Employee наследует опреде-
ления атрибутов full_name (полное имя) и date_of_birth (дата рождения). Объект
класса Employee может быть позже реализован с использованием значений этих атри-
бутов (поскольку атрибуты существуют в объекте наряду с четырьмя другими атрибута-
ми: date_hired (дата приема на работу), salary (зарплата), leave_entitlement
(положенный отпуск) и leave_taken (использованный отпуск)). .
Рис. 2.17. Обобщение
76 Глава 2. Основания анализа требований
2.1.5.1. Полиморфизм
Зачастую метод, унаследованный подклассом, напрямую используется этим под-
классом. Операция аде () (возраст) работает аналогично в объектах классов Person
и Employee. Однако, иногда необходимо, чтобы операции в подклассе были замещены
(overridden) в соответствии с семантическими вариациями подкласса.
Например, операция Employee. remainingLeave () (остаток отпуска сотрудни-
ка) вычисляется посредством вычитания значения атрибута leave_taken из значе-
ния атрибута leave_entitlement (рис. 2.17). Однако сотрудник, являющийся ме-
неджером, имеет право на ежегодное получение дополнительного отпуска
(leave supplement). Теперь, если добавить в обобщенную иерархию класс Manager
(как показано на рис. 2.18), операция Manager .remainingLeave () должна замес-
тить операцию Employee. remainingLeave (). Это показано на рис. 2.18 с помощью
дублирования имени операции в подклассе.
Рис. 2.18. Полиморфизм
Теперь операция remainingLeave () замещена (модифицирована). Существует две
реализации (два метода) операции. Можно отправить сообщение remainingLeave ()
объекту Employee или объекту Manager, и при этом будут выполняться различные
методы. Мы можем даже не знать и не заботиться о том, кто выступает в качестве ад-
ресата: объект Employee или объект Manager — будет выполнен подходящий метод.
Говорят, что операция remainingLeave () полиморфна (polymorphic).
2.1.5.2. Наследование
В отсутствие наследования полиморфизм находит лишь ограниченное применение.
Наследование (inheritance) открывает возможности для определения подкласса методом
последовательного наращивания с использованием и последующим расширением опи-
саний суперкласса. Вполне возможно, операция Manager. remainingLeave () реали-
зована с помощью обращения к функциональным возможностям метода
Employee. remainingLeave () с последующим добавлением к значению, возвращае-
мому этим методом, величины leave__supplement.
Несколько классов в рамках одной иерархии наследования могут объявлять одну и
туже операцию. Подобная операция имеет несколько реализаций (методов), но одну и
ту же сигнатуру — имя, а также количество и типы параметров, если, конечно, они оп-
ределены для операции. Полиморфное поведение зависит от наследования.
2.1.5.2.1. Множественное наследование
Подкласс может наследовать более, чем одному суперклассу. Множественное насле-
дование может стать источником конфликтов наследования, которые должны явно
разрешаться программистом.
2.1. Основы объектной технологии 77
На рис. 2.19 класс Tutor (Наставник) наследует классам Teacher (Преподаватель)
и Postgraduatestudent (Аспирант). Класс Teacher в свою очередь наследует клас-
су Person точно так же, как класс Postgraduatestudent (через класс Student). В
результате класс Tutor дважды унаследует атрибуты и операции класса Person, если
только программист не укажет программной среде на необходимость однократного
наследования за счет использования левого либо правого “пути” наследования (или
если программная среда не применит некоторое правило умолчания, приемлемое для
программиста, которое ликвидирует двойное наследование).
2.1.5.2.2. Множественная классификация
В большинстве современных объектно-ориентированных программных сред объ-
ект может принадлежать только одному классу. Это жесткое ограничение, поскольку в
реальности объект может принадлежать одновременно нескольким классам.
Множественная классификация отличается от множественного наследования. При
множественной классификации объект одновременно является экземпляром двух или
более классов. При множественном наследовании класс может иметь множество су-
перклассов, но для каждого объекта должен быть определен единственный класс.
В примере множественного наследования на рис. 2.19 каждый объект Person
(такой, как Мери или Питер) принадлежит одному классу (наиболее конкретизирован-
ному, который к нему применим). Если Мери — аспирантка (Postgraduatestudent),
но не наставник (Tutor), то Мери принадлежит классу Postgraduatestudent.
Рис. 2.19. Множественное наследование
Проблема возникает при попытке уточнить значение объекта Person для не-
скольких ортогональных иерархий. Например, личность (Person) может быть со-
___Глава*- Основания анализа требований
трудником (Employee) или студентом (Student), мужчиной (Male) или женщиной
(Female), ребенком (Child) или взрослым (Adult) и т.д. При отсутствии возможно-
сти множественной классификации нам необходимо определить классы для каждой
разрешенной комбинации иерархий, чтобы получить, к примеру, объект Person, ко-
торый является ребенком (Child), женщиной (Female) и студентом (Student) (т.е.
класс, который можно было бы назвать ChildFemaleStuden) [25].
2.1.5.2.3. Динамическая классификация
В большинстве современных объектно-ориентированных программных сред объект
не может сменить класс после того, как он реализован (создан). Это еще одно жесткое
ограничение, поскольку в реальности объекты могут динамически изменять класс.
Динамическая классификация является прямым следствием множественной классифика-
ции. Объект может не только принадлежать нескольким классам, но также может в про-
цессе своего жизненного цикла приобретать или утрачивать принадлежность к классу.
В случае схемы динамической классификации объект Person в один день может
быть просто сотрудником, а в другой — менеджером (и сотрудником). В отсутствие
динамической классификации деловые перемены, такие как продвижение сотрудни-
ков, трудно (или даже невозможно) декларативно моделировать в диаграмме классов.
Их необходимо моделировать процедурно в диаграмме состояний или с помощью
аналогичного метода моделирования.
К сожалению, язык UML не поддерживает моделирования динамической или
множественной классификации. Это ставит его по отсутствию поддержки вровень с
программными средами. Следовательно, наши пояснения и примеры не обогащены
графическими моделями динамической и множественной классификации.
2.1.5.3. Абстрактный класс
Абстрактный класс (abstract class) — важная концепция моделирования, которая ло-
гически вытекает из понятия наследования. Абстрактный класс — это родительский
класс, который не имеет непосредственных объектов-экземпляров. Только подклассы
абстрактного родительского класса'могут быть материализованы как экземпляры.
• В типичном случае Класс становится абстрактным, если, по меньшей мере, одна из
его операций является абстрактной. Абстрактная операция обладает сигнатурой (именем
и Списком формальных аргументов), определенной в абстрактном родительском классе,
однако реализации операции (метод) отличаются для конкретных дочерних классов.
Причина, по которой абстрактный класс не может порождать объекты-экземпляры,
заключается в том, чТо он обладает, по меньшей мере, одной абстрактной операцией.
Если допустить, что абстрактный класс создает объекты, то сообщение абстрактной
операции этого объекта приведет к ошибке при выполнении программы (поскольку для
абстрактной операции В классе этого объекта отсутствовала бы реализация).
Класс может быть абстрактным только в Том случае, если он является суперклассом,
который полностью подразделяется'На подклассы. Разделение называется полным, если
подклассы содержат все возможные объекты, которые порождены в рамках наследст-
венной иерархии. В этом случае не существует никаких “отбившихся” объектов [60].
Класс Person на рис. 2.19 не является абстрактным, нам может потребоваться реализо-
вать объекты класса Person, которые не являются преподавателями (Teacher) и сту-
дентами (Student). Возможно также, что нам может потребоваться добавить в будущем
к классу Person другие классы (например, такие Как AdminEmployee).
2.1. Основы объектной технологии 79
На рис. 2.20 показан абстрактный класс Video (в языке UML имя абстрактного
класса выделяется курсивом). Этот класс содержит абстрактную операцию
rentalcharge (арендная плата). Ясно, что арендная плата вычисляется по-разному
для видеокассет и видеодисков. Поэтому вводятся две различных реализации опера-
ции rentalcharge — для классов VideoTape и VideoDisk.
Абстрактные классы могут не иметь объектов, но очень полезны при моделирова-
нии. Они создают высокоуровневый “словарь” моделирования, без которого язык мо-
делирования будет неполным. ,
Рис. 2.20. Абстрактный класс
с абстрактной операцией
2.1.6. Объект-класс
Попутно мы провели различие между объектом-экземпляром и объектом-классом. Объ-
ект-класс — это объект, область действия атрибутов и/или операций которого совпа-
дает с данным классом. Область действия-класс здесь означает глобальный атрибут
или операцию, которые применимы к самому классу и ,не применимы ни к одному из
объектов-экземпляров.
Поскольку в чистой объектно-ориентированной системе в качестве хранилищ вы-
ступают объекты, необходимо, чтобы объект-класс хранил глобальные атрибуты и
операции. Наиболее распространенными атрибутами- с областью действиякласс явля-
ются атрибуты, которые хранят значения, принятые по умолчанию, или агрегиро-
ванные значения (такие, как суммы, итоги, средние значения). Наиболее распростра-
ненной операцией с областью действия-класс является операция создания и уничтожения
объектов-экземпляров и операции, вычисляющие агрегированные значения.
На рис. 2.21 показан класс Student с атрибутом с областью действия-класс
(max_courses_per_semester) (максимальное количество курсов за семестр) и анало-
гичной операцией averageStudentAge () (средний возраст студентов). Каждый сту-
дент может прослушать одинаковое максимальное количество курсов за семестр, поэто-
му данное количество должно храниться в объекте-классе. Операция, вычисляющая
средний возраст студентов, обладает глобальнрй областью действия, поскольку ей для
того, чтобы опредедить средний возраст всех студентов, необходим доступ к индивиду-
альному возрасту каждого студента (в объекте-экземпляре Student).
При работе с языком UML в прямоугольнике описания класса рекомендуется выделять
атрибуты и операции с областью действия-класс. На рис. 2.21 символ $ перед именем атри-
бута обозначает атрибут с областью действия-класс (или статический атрибут). Для обо-
значения операции с областью действия-класс (или статической операции) в UML в каче-
стве стандартной записи используется глобальное имя, заключенное внутрь скобок (« »).
80 Глава 2. Основания анализа требований
Student
Bfstudant Id: String Blstudent name: PersonName W$ max_courses_per_semester: Integer
Б «global» averagestudent Age(): Real
Рис. 2.21. Класс, содержащий атрибуты
и операции с областью действия-класс
2.2. Наставление по моделированию анализа
В данном разделе представлено краткое наставление по визуальному моделирова-
нию на языке UML с использованием простого примера. Цель состоит в том, чтобы
продемонстрировать различные виды диаграмм UML и показать, как они согласуются
друг с другом. Каждая из диаграмм UML символизирует определенный взгляд на сис-
тему. Чтобы понять систему в целом, необходима разработка и интеграция несколь-
ких видов диаграмм, представляющих разные взгляды.
На самом общем уровне можно выделить три типа UML-моделей— каждая со своим
собственным набором диаграмм и связанных с ними конструкций.
1. Модель состояний (state model), которая представляет статический взгляд на систе-
му, — это модель требований к данным. Модель состояния представляет структу-
ры данных и отношения на них. Основной метод визуализации модели состоя-
ний состоит в использовании диаграммы классов.
2. Модель поведения (behavior model), которая представляет операционным взгляд на систе-
му, — это модель функциональных требований. Модель поведения представляет биз-
нестранзакции, операции и алгоритмы над данными. Для визуализации модели по-
ведения существует несколько способов — диаграммы прецедентов, диаграммы по-
следовательностей, диаграммы коперации и диаграммы видов деятельности.
3. Модель изменения состояний (state change model), которая представляет динамиче-
ский взгляд на систему, — это модель эволюции объектов со временем. Модель
изменения состояний представляет возможные изменения состояний объекта
(где под состоянием понимаются текущие значения атрибутов и ассоциативных
связей с другими объектами). Основной метод визуализации модели изменения
состояний заключается в использовании диаграммы состояний.
2.2.1. Internet-магазин
Internet вызвал революцию в способах ведения бизнеса. Чтобы оставаться конкурен-
тоспособными организациям, необходимо “присутствовать” в Internet и расширить круг
своих бизнес-приложений, включив в них средства электронной коммерции (е-
commerce). Изменения касаются прежде всего клиентской части (front end) приложений,
однако, основная серверная 'часть (back end) систем управления базами данных (СУБД) по-
прежнему должна выполнять вполне традиционную обработку деловых операций.
Наше краткое наставление опирается на приложение Internet-магазин. В основном
мы будем иметь дело с серверной частью приложения — приемом электронных зака-
зов от клиентов, обработкой и выполнением заказов, выставлением счетов и отправ-
кой товаров потребителю.
2.2. Наставление по моделированию анализа 81
j Производитель компьютеров предлагает возможность приобретения своей продукции
| через Internet. Клиент может выбрать компьютер на Web-странице производителя. Ком-
I пьютеры подразделяются на серверы, настольные и портативные. Заказчик может вы-
i брать стандартную конфигурацию или построить требуемую конфигурацию в диалого-
вом режиме. Компоненты конфигурации (такие, как оперативная память) представляют-
; ся как список для выбора из доступных альтернатив. Для каждой новой конфигурации
система может подсчитать цену.
5 Чтобы оформить заказ, клиент должен заполнить информацию по доставке и оплате. В каче-
стве платежных средств допускается использование кредитных карточек или чеков. После
; ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждени-
« ем получения заказа вместе с относящимися к нему деталями. Пока клиент ожидает прибы-
, тия компьютера, он может проверить состояние заказа в любое время в диалоговом режиме.
i Серверная часть обработки заказа состоит из заданий, необходимых для проверки кредито-
; способности и способа расчета клиента за покупку, истребования заказанной конфигурации
> со склада, печати счета и подачи заявки на склад о доставке компьютера клиенту.
Наставление задумано с целью продемонстрировать методы визуального модели-
рования языка UML. Представленная последовательность видов деятельности по мо-
делированию также задумана таким образом, чтобы показать зависимости между диа-
граммами UML.
Последовательность видов деятельности не должна рассматриваться как рекомен-
дуемый процесс. В действительности процесс является итеративным процессом с нара-
щиванием возможностей (раздел 1.1.3.1). Слишком сильная опора в наставлении на мо-
делирование прецедентов в действительности не отражает сложившейся практики
разработки ПО. Обычно наряду с моделированием прецедентов должно проводиться
моделирование классов.
2.2.2. Моделирование прецедентов
Поведение системы— это ее реакция в ответ на внешние события. В языке UML
внешне наблюдаемое и допускающее тестирование поведение фиксируется в виде
прецедентов. Прецедент (use case) выполняет бизнес-функцию, которую может наблю-
дать внешний субъект и которая может быть впоследствии отдельно протестирована в
процессе разработки.
Субъект (actor) — это некто или нечто (человек, машина и т.д.), взаимодействующее
с прецедентом. Субъект взаимодействует с прецедентом, ожидая получить некий по-
лезный результат.
Диаграмма прецедентов — это наглядное представление субъектов и прецедентов
вместе с любыми дополнительными определениями и спецификациями. Диаграмма
прецедентов представляет собой не просто некую схему, а является полностью доку-
ментированной моделью предполагаемого поведения системы. Такое же понимание
применимо в отношении других диаграмм языка UML. Если только не оговорено
противное, то UML-диаграмма используется как синоним UML-модели.
2.2.2.1. Субъекты
Субъекты и прецеденты определяются в результате анализа функциональных тре-
бований. Функциональные требования воплощаются в прецедентах. Прецеденты
82 Глава 2. Основания анализа требований
удовлетворяют функциональные требования за счет предоставления субъекту полез-
ного результата. При этом не имеет значения, в какой последовательности решает
бизнес-аналитик свои задачи: сначала обозначает субъектов, а затем прецеденты, или
наоборот. В нашем наставлении сначала выбираются субъекты.
Типичным графическим изображением субъекта является “штриховой человечек”
(см. ниже). В общем случае субъект может быть показан в виде прямоугольного сим-
вола класса. Подобно обычному классу субъект может обладать атрибутами и опера-
циями (связанными с событиями, сообщения о которых он отправляет и получает).
На рис. 2.22 показаны три субъекта, которые явно представлены в спецификации.
Это субъекты Customer (Клиент), Salesperson (Продавец) и Warehouse (Склад).
Customer
Salesperson
Warehouse
Рис. 2.22. Субъекты (Internet-магазин)
: Обратитесь к приведенному выше содержанию наставления (с.54) и рассмотрите следующие
I расширенные требования для установления субъектов в приложении Internet-магазин.
1. Для знакомства со стандартной конфигурацией выбираемого сервера, настольного
или портативного компьютера клиент использует Web-страницу lnternet-магвзина.
При этом также приводится цена конфигурации.
2. Клиент выбирает детали конфигурации, с которыми он хочет познакомиться, возмож- i
j но, с намерением купить готовую или составить более подходящую конфигурацию. Це-
| нв для каждой конфигурации может быть подсчитана по требованию пользователя.
I 3. Клиент может выбрать вариант заказа компьютера по Internet либо попросить, чтобы ;
| продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п.
< прежде, чем заказ будет фактически размещен.
I 4. Для размещения заказа клиент должен заполнить электронную форму с адресами
для доставки товара и отправки счет-фактуры, а также деталями, касающимися оп-
латы (кредитная карточка или чек).
5. После ввода заказа клиента в систему продавец отправляет на склад электронное i
требование, содержащее детали заказанной конфигурации.
6. Детали сделки, включая номер заказа, номер счета клиента, отправляются по электрон- ;
ной почте клиенту, так что заказчик может проверить состояние заказа через Internet. ,
7. Склад получает счет-фактуру от продавца и отгружает компьютер клиенту. '
2.2.2.2. Прецеденты
Прецедент (use case) представляет собой некий целостный набор функций, имеющих
определенную ценность для субъекта. Субъект, который не общается с прецедентом, не
имеет смысла, однако обратное утверждение не всегда верно (т.е. прецедент, который
не общается с субъектом — вещь допустимая). Могут существовать некоторые прецеден-
ты, которые обобщают или уточняют основной прецедент и не взаимодействуют непо-
средственно с субъектами. Они используются как внутренние в модели прецедентов и
помогают основному прецеденту выработать результат, предоставляемый субъекту.
2.2. Наставление по моделированию анализа 88
Прецеденты можно вывести в результате идентификации задач для субъекта. Для
этого следует задаться вопросом: “Каковы обязанности субъекта по отношению к сис-
теме и чего он ожидает от системы?” Прецеденты также можно определить в резуль-
тате непосредственного анализа функциональных требований. Во многих случаях
функциональное тпребовлные отображается непосредственно в прецедент.
Для выполнения этого задания наставления мы можем построить таблицу, которая
распределяет функциональные требования по субъектам и прецедентам. Обратите
внимание, что некоторые потенциальные бизнес-функции могут выходить за рамки
приложения — они не подлежат преобразованию в прецеденты.
В табл. 2.1 функциональные требования, приведенные на шаге 1 наставления, рас-
пределены по субъектами и прецедентам. Складские задачи сборки конфигурации
компьютера и отправки его клиенту относятся к функциям, которые в данном случае
выходят за рамки приложения.
На рис. 2.23 показано графическое обозначение прецедентов. Прецедент изобра-
жается в. виде эллипса, внутри или ниже которого помещается имя прецедента. Мож-
но использовать также другие представления, включая обозначение класса в виде
прямоугольника, внутри которого можно привести перечень всех необходимых атри-
бутов и операций прецедента.
Display Standard
Computer Configuration
Build Computer
Configuration
Order Configured
Computer
Request
Salesperson Contact
Verify and Accept
Customer Payment
Inform Warehouse
about Order
Print Invoice
Update
Order Status
Puc. 2.23. Прецеденты (Internet-магазин)
84 Глава 2. Основания анализа требований
Таблица 2.1. Распределение требований по субъектам и прецедентам
№ п/п Требование Субъект Прецедент
1. Для знакомства со стандартной конфигурацией выбираемого сер- вера, настольного или портативно- го компьютера клиент использует Web-страницу Internet-магазина. При этом также приводится цена конфигурации Customer (Клиент) Display Standard Computer Configuration (Отображение стандарт- ной конфигурации ком- пьютера)
2. Клиент выбирает детали конфигу- рации, с которыми он хочет позна- комиться, возможно, с намерением купить готовую или составить бо- лее подходящую конфигурацию. Цена для каждой конфигурации может быть подсчитана по требо- ванию пользователя Customer Build Computer Configuration (Составление конфигу- рации компьютера)
3. Клиент может выбрать вариант зака- за компьютера по Internet либо по- просить, чтобы продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п. прежде, чем заказ будет фактически размещен Customer, Salesperson (Продавец) 1 / Customer Order Configured Computer (Заказ сконфи- гурированного компьюте- ра), Request Salesperson Contact (Обращение с просьбой к продавцу)
4. Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки то- вара и отправки счет-фактуры, а также деталями, касающимися оп- латы (кредитная карточка или чек) Order Configured Computer,Verify and Accept Customer Payment (Проверка и прием платежа от клиента)
5. После ввода заказа клиента в сис- тему продавец отправляет на склад электронное требование, содер- жащее детали, касающиеся зака- занной конфигурации Salesperson, Warehouse (Склад) Inform Warehouse About Order (Информирование склада о заказе)
6. Детали сделки, включая номер зака- за, номер счета клиента, отправля- ются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet Salesperson, Customer Order Configured Computer, Update Order States (Обновление состояния заказа)
7. Склад получает счет-фактуру от продавца и отправляет компьютер клиенту Salesperson, Warehouse Print Invoice (Печать счет-фактуры)
2-2. Наставление по моделированию анализа 85
2.2.2- 3. Диаграммы прецедентов
Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позво-
ляет пользователю установить отношения между прецедентами, конечно, если такие
отношения существуют. Эти отношения рассматриваются в главе 4 (см. разд. 4.3.1.2).
Диаграммы прецедентов — основной метод визуализации для модели поведения
системы. Чтобы представить полную модель прецедентов (см. разд. 2.2.2.4), необходимо
более подробное описание элементов диаграммы (прецедентов и субъектов).
О наставление по анализу: задан.ие^^^^^^/_!ж__ .
Обратитесь к предыдущим заданиям наставления и изобразите диаграмму прецеден- I
I тов для приложения Internet-магазин. i
Решение для этого задания наставления можно прямо получить, воспользовав-
шись информацией предыдущих заданий. Единственное, что необходимо при этом
учесть, — это отношения между прецедентами. Диаграмма прецедентов представлена
на рис. 2.24. Смысл отношения <<extend>> (расширяет) состоит в том, что преце-
дент Order Configured Computer может быть расширен субъектом Customer
с помощью прецедента Request Salesperson Contact.
Рис. 2.24. Диаграмма прецедентов (ЪгйетеЬмагазин)
86 Глава 2. Основания анализа требований
2>2.2.4. Документирование прецедентов
Каждый прецедент должен быть описан с помощью документально зафиксирован-
ного потока событий {flow of events). Соответствующий текстовый документ определяет,
что должна делать система, когда субъект инициирует прецедент. Структура докумен-
та, описывающего прецеденты, может варьироваться, однако типичное описание долж-
но содержать следующие разделы [66].
Краткое описание.
Участвующие субъекты.
Предусловия, необходимые для инициирования прецедента.
Детализированное описание потока событий, которое включает:
— основной поток, который можно разбить для того, чтобы показать подчинен-
ные потоки событий (подчиненные потоки могут быть разделены дальше на
еще более мелкие потоки, с целью улучшить удобочитаемость документа);
— альтернативные потоки для определения исключительных ситуаций.
Постусловия, определяющие состояние системы, по достижении которого
прецедент завершается.
Документ, содержащий описания прецедента, развивается по ходу разработки. На
ранней стадии определения требований составляется только краткое описание. Ос-
тальные части документа создаются постепенно и итеративно. Полный документ воз-
никает в конце этапа спецификации требований. На этой стадии документ может
быть дополнен прототипами GUI-экранов. Позднее документ по прецедентам исполь-
зуется для создания пользовательской документации для реализуемой системы.
Решение для этого задания наставления представлено в табличной форме (табл. 2.2).
Не следует рассматривать этот способ документирования прецедента как общеприня-
тый. Документы с описанием прецедентов могут быть многостраничными (в среднем
около десятка страниц) и обладать стандартной для документов структурой, и включать,
например, такие элементы, как оглавление.
Обратитесь к предыдущим заданиям наставления и подготовьте документ, содержащий
описание прецедента Order Configured Computer. Чтобы установить детали, кото-
рые явно не сформулированы в требованиях, используйте ваши общие знания или ин-
формацию о типичной задаче обработки заказов.
Таблица 2.2. Описательная спецификация прецедента Order Configured
Computer (Internet-магазин)
Прецедент Заказ сконфигурированного компьютера
Краткое опи- сание Прецедент дает возможность клиенту. (Client) ввести заказ на покуп- ку. Заказ включает адреса доставки товара и оплаты счета, а также де- тали условий оплаты
Субъекты Предусловия Client (Клиент) Клиент с помощью Intemet-броузера выбирает страницу производителя компьютеров для ввода заказа. На Web-странице отображается подробная информация о сконфигурированном компьютере вместе с его ценой
2.2. Наставление по моделированию анализа 87
Окончание табл. 2.2
Прецедент Заказ сконфигурированного компьютера
Основной поток Начало прецедента совпадает с решением клиента заказать сконфигу- рированный компьютер с помощью выбора функции Continue (Продолжить) (или аналогичной функции) при отображении на экра- не детализированной информации, относящейся к заказу. Система просит клиента ввести детали покупки, в том числе: имя про- давца (если оно известно); детали, касающиеся доставки (имя и адрес клиента); детальную информацию по оплате (если она отличается от информации по доставке); способ оплаты (кредитная карточка или чек) и произвольные комментарии. Клиент выбирает функцию Purchase (Покупка) (или аналогичную функцию) для отправки заказа производителю. Система присваивает уникальный номер заказа и клиентский учетный но- мер заказу на покупку и запоминает информацию о заказе в базе данных. Система отправляет клиенту по электронной почте номер заказа и клиентский номер клиенту вместе со всеми деталями, относящимися к заказу, в качестве подтверждения принятия заказа
Альтернатив ные потоки Клиент инициирует функцию Purcha se до того, как введет всю обязатель- ную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Клиент выбирает функцию Reset (Сброс) (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система дает воз- можность клиенту вновь ввести информацию
Постусловия Если прецедент был успешным, заказ на покупку записывается в базу дан- ных. В противном случае состояние системы остается неизменным
2.2.3. Моделирование видов деятельности
Модель видов деятельности (activity model) может представлять в графической форме
поток событий для прецедента. Этот тип модели был введен только в более поздние
версии UML и позволил преодолеть разрыв между высокоуровневым представлением
поведения системы с помощью моделей прецедентов и намного более низким уровнем
представления поведения с помощью моделей взаимодействий (диаграмм последова-
тельностей и диаграмм кооперации).
Диаграмма видов деятельности показывает шаги вычисления. Каждый шаг соот-
ветствует состоянию (state), в котором что-либо выполняется. Поэтому шаги выполне-
ния называются состояниями вида деятельности. Диаграмма описывает, какие шаги вы-
полняются последовательно, а какие — параллельно. Передача управления от одного
состояния вида деятельности к другому называется переходом (transition).
После завершения документа с описанием прецедента состояния вида деятельно-
сти можно установить по описанию основного и альтернативных потоков. Однако, меж-
ду описанием прецедентов и моделью видов деятельности существует важное разли-
чие. Описание прецедента создается с точки зрения внешнего субъекта. Модель видов
деятельности отражает внутрисистемную точку зрения.
88 Глава 2. Основания анализа требований
Модели видов деятельности могут находить и другое применение при разработке
систем помимо моделирования прецедентов [25]. Они могут использоваться для ана-
лиза бизнес-процессов на высоком уровне абстракции до выработки прецедентов. И
наоборот, их можно использовать на более низком уровне абстракции для разработки
сложных последовательных алгоритмов или средств распараллеливания в многопо-
точных приложениях.
2.2.3.1. Виды деятельности
Если моделирование видов деятельности используется для визуализации последо-
вательности видов деятельности, связанных с прецедентом, то состояния вида дея-
тельности можно установить на основе документа описания прецедента. Как было
отмечено выше, имена действиям следует присваивать, исходя из системных сообра-
жений, а не с точки зрения субъекта.
Состояние вида деятельности представляется в UML в виде прямоугольника с за-
кругленными углами. Следует сразу уточнить, что один и тот же графический символ
используется для визуализации состояния вида деятельности (activity state) и состояния дей-
ствия (action state). Различие между деятельностью и действием реакцией заключается в
их временном масштабе. Для осуществления деятельности требуется определенное вре-
мя; действие же завершается столь быстро, что — в масштабах нашей временной шкалы —
может считаться происходящим мгновенно. (Следовательно, в модели состояний
(раздел 2.2.6) виды деятельности могут быть определены только в рамках состояния объ-
екта, а действия могут появляться также при переходе между состояниями объекта.)
В табл. 2.3 изложены события, относящиеся к основному и альтернативным пото-
кам, заимствованным из документа описания прецедента, а также обозначены со-
стояния видов деятельности. Обратите внимание, что имя каждому виду деятельности
присвоено, исходя из системной точки зрения, а не с точки зрения субъекта.
Виды деятельности, приведенные в табл. 2.3, показаны на рис. 2.25.
Таблица 2.3. Установление действий в основном и альтернативных потоках
№ Формулировка прецедента
п/п
Состояние вида деятельности
1.
Начало прецедента совпадает с решением клиента
заказать сконфигурированный компьютер с по-
мощью выбора функции Continue (или аналогич-
ной функции) при отображении на экране детали-
зированной информации, относящейся к заказу
2. Система просит клиента ввести детализирован-
ную информацию о покупке, в том числе; имя
продавца (если оно известно); детали, касающие-
ся доставки (имя и адрес клиента); детальную
информацию по оплате (если она отличается от
информации по доставке); способ оплаты
(кредитная карточка или чек) и произвольные
комментарии
Display Current
Configuration
(Отображение текущей
конфигурации); Get Order
Request (Получение запро-
са на заказ)
Display Purchase Form
(Отображение закупочной
формы)
2.2. Наставление по моделированию анализа 89
Окончание табл. 2.3
№ Формулировка прецедента
п/п
Состояние вида деятельности
3. Клиент выбирает функцию Purchase (или ана-
логичную функцию) для отправки заказа произ-
водителю
Get Purchase Details
(Детализировать информа-
цию о покупке)
4.
5.
Система присваивает уникальный номер заказа и
клиентский учетный номер заказу на покупку и за-
поминает информацию о заказе в базе данных
Система отправляет клиенту по электронной
почте номер заказа и клиентский номер клиенту
вместе со всеми деталями, относящимися к зака-
зу, в качестве подтверждения принятия заказа
Store Order (Запомнить
заказ)
Email Order Details
(Отправить детальную ин-
формацию по заказу)
6.
Клиент инициирует функцию Purchase до того,
как введет всю обязательную информацию. Сис-
тема отображает на экране сообщение об ошибке
и просит ввести пропущенную информацию
Get Purchase Details;
Display Purchase Form
7.
Клиент выбирает функцию Reset (или анало-
гичную) для того, чтобы вернуться к исходной
форме заказа на покупку. Система дает возмож-
ность клиенту вновь ввести информацию
Display Purchase Form
j Обратитесь к заданию 4 наставления. Проанализируйте основной и альтернативный по- j
| токи, представленные в документе описания прецедента. Установите, какие виды дея- j
| тельности свойственны прецеденту Order Configured Computer. |
2.2.3.2. Диаграмма видов деятельности
Диаграмма видов деятельности (activity diagram) показывает переходы между видами
деятельности. Если вид деятельности не представляет собой замкнутого цикла, то диа-
грамма содержит начальное состояние вида деятельности и одно или более конечных
состояний вида деятельности. Полностью закрашенная окружность представляет на-
чальное состояние. Конечное состояние изображается в виде окружности с закрашен-
ной центральной частью (автор образно называет этот символ “бычьим глазом”).
Переходы могут разветвляться по условию и объединяться. В результате возникают
альтернативные (alternative) вычислительные потоки (thread). Условие ветвления обо-
значается ромбом.
Переходы могут также разделяться и сливаться. В результате возникают параллельные
(одновременно выполняемые) (concurrent) потоки. Распараллеливание и воссоедине-
ние переходов представляется в виде жирной линии или полосы. Заметим, что диа-
грамма вида деятельности, в которой отсутствуют параллельные процессы, похожа на
обычную блок-схему. (Поведение с параллелизмом в наставлении не используется. Его
демонстрации посвящен подраздел 4.3.2).
90 Глава 2. Основания анализа требований
Display Current
Configuration
Get Order
Request
Display
Purchase Form
Get Purchase
Details
Puc. 2.25. Виды деятельности для прецедента Order Configured
Computer (Internet-магазин)
Обратитесь к заданию 4 и заданию 5 наставления и изобразите диаграмму видов дея-
тельности для прецедента Order Configured Computer, относящегося к приложению
j Internet-магазин.
Чтобы изобразить диаграмму, виды деятельности, обозначенные в задании 5 на-
ставления, следует соединить линиями перехода, как показано на рис. 2.26.
Рис. 2.26. Диаграмма видов деятельности для прецедента
Order Configured Computer (Internet-магазин)
Начальное состояние деятельности—Display Current Configuration. Рекур-
сивный переход на этом состоянии служит признанием того факта, что отображение
непрерывно обновляется до тех пор, пока не сработает следующий переход (переход
в состояние Get Order Request). Этот факт может интерпретироваться как осоз-
нание того, что это состояние является деятельностью, а не действием.
Если при нахождении модели в состоянии Display Purchase Form сработает ус-
ловие timeout (истечение времени ожидания), то выполнение модели видов деятель-
2.2. Наставление по моделированию анализа 91
ности завершится. Иначе, активизируется состояние Get Purchase Details. Если де-
тальные данные относительно покупки неполны, система вновь переходит в состояние
Display Purchase Form. В противном случае система переходит в состояние Store
Order, азатем —в состояние Email Order Details (конечноесостояние).
Обратите внимание, что на диаграмме показаны только те условные переходы, кото-
рые (всегда) появляются на выходах из состояния вида деятельности. Условные переходы,
которые являются внутренними для состояния вида деятельности, не показаны явно на
диаграмме. Об их существовании можно догадаться по наличию нескольких исходящих
переходов, которые, возможно, сопровождаются именем условия в квадратных скобках
(например, таким как [timeout] на выходе из состояния Display Purchase Form).
2.2.4. Моделирование классов
Систему образует системное состояние. Состояние является функцией содержимого
системной информации в заданный момент времени — это функция системного теку-
щего набора объектов-экземпляров (см. разд. 2.1.1).
Определение внутреннего состояния системы дается в модели классов (class model). К
элементам, принимающим участие в моделировании классов, относятся сами классы,
атрибуты и операции классов, ассоциации, агрегации и композиции, а также обобще-
ния (см. разделы 2.1.2, 2.1.3, 2.1.4 и 2.1.5). Диаграмма классов (class diagram) дает обоб-
щенное визуальное представление обо всех этих элементах модели.
Еще раз напоминаем, что хотя в наставлении моделирование классов рассматри-
вается после моделирования прецедентов, на практике эти двй вида деятельности
проводятся в параллель (см. разд. 3.2). Две модели взаимно дополняют одна другую
вспомогательной информацией. Прецеденты облегчают выбор классов, и наоборот —
модели классов могут помочь выявить упущенные прецеденты.
2.2.4.1. Классы
До сих пор мы использовали классы для определения бизнес-объектов. Все приве-
денные в книге примеры классов относились к долгоживущим (постоянным или пер-
манентным) сущностям бизнес-процессов, таким как Order (Заказ), Shipment
(Доставка), Customer (Клиент), Student (Студент) и т.д. Это классы, которые опре-
деляют модель базы данных для прикладной области. По этой причине подобные
классы часто называют классами-сущностями (entity class) или модельными классами.
Они представляют постоянно хранимые объекты базы данных.
Классы-сущности определяют существо любой информационной системы. Анализ
требований направлен преимущественно на выявление классов-сущностей. Однако,
для функционирования системы требуются также классы другого типа. Пользовате-
лям системы необходимы классы, которые определяют GUI-объекты (например, та-
кие как экранные формы), называемые пограничными классами (boundary classes)
(классами представления (view classes)). Чтобы функционировать надлежащим обра-
зом, системе также необходимы классы, которые управляют программной логикой —
управляющие классы (control classes) (см. разд. 5.2.3).
В зависимости от конкретного подхода к моделированию пограничные и управ-
ляющие классы могут рассматриваться или не рассматриваться на некотором уровне
представления в ходе анализа требований. Моделирование классов этого типа может
быть отложено до этапа проектирования системы.
92 Глава 2. Основания анализа требований
'.^^Э@Н8вИЯВВИ1мШншШЯ»И»'^^'«^^ПЖ->^.. ,мям i.V
' Обратитесь к требованиям, определенным в содержании наставления (разд. 2.2.1) и в <
j задании 1 наставления (разд. 2.2.2.1). Укажите классы, которые могут служить прототи- ’
I нами классов-сущностей для приложения Internet-магазин.
Следуя подходу, принятому при установлении субъектов и прецедентов (см.
табл. 2.1), можно построить таблицу, которая поможет выявить классы в результате
анализа функциональных требований. В табл. 2.4 функциональным требованиям, пе-
речисленным в задании 1 наставления, поставлены в соответствие классы-сущности.
Таблица 2.4. Соответствие функциональных требований и классов-сущностей
(Internet-магазин)
№ п/п Требование Класс-сущность
1. Для знакомства со стандартной кон- фигурацией выбираемого сервера, на- стольного или портативного компью- тера клиент использует Web-страницу Internet-магазина. При этом также приводится цена конфигурации Customer (Клиент); Computer (Компьютер); Standardconfiguration (Стандартная конфигурация); Product (Товар)
2. Клиент выбирает детали конфигурации, с которыми хочет познакомиться, воз- можно, с намерением купить готовую или составить более подходящую кон- фигурацию. Цена для каждой конфигу- рации может быть подсчитана по тре- бованию пользователя Customer, ConfiguredComputer (Сконфигурированный компьютер); ConfiguredProduct (Укомплектованный товар); Configurationitem (Элемент кон- фигурации)
3. Клиент может выбрать вариант заказа компьютера по Internet либо попро- сить, чтобы продавец связался с ним для объяснения деталей заказа, дого- ворился о цене и т.п. прежде, чем за- каз будет фактически размещен Customer,ConfiguredComputer, Order (Заказ), Salesperson (Продавец)
4. Для размещения заказа клиент должен заполнить электронную форму с адре- сами для доставки товара и отправки счетфактуры, а также деталями, касаю- щимися оплаты (кредитная карточка или чек) Customer;Order; Shipment (Поставка); Invoice (Счет-фактура); Payment (Платеж)
5. После ввода заказа клиента в сис- тему продавец отправляет на склад электронное требование, содер- жащее детали, касающиеся зака- занной конфигурации Customer; Order; Salesperson; ConfiguredComputer; Configurationitem
2.2. Наставление по моделированию анализа 93
Окончание табл. 2.4
№ п/п Требование Класс-сущностъ
6. Детали сделки, включая номер заказа, номер счета клиента, отправляются по электронной почте клиенту, так что заказчик может проверить со- стояние заказа через Internet Order; Customer; Orderstatus (Состояние заказа)
7. Склад получает счет-фактуру от про- давца и отправляет компьютер клиенту Invoice;Shipment
Выделение классов представляет собой итеративную задачу, и первоначальный
перечень предполагаемых классов, как правило, претерпевает изменения. При опре-
делении того, являются ли понятия, присутствующие в требованиях, искомыми клас-
сами, могут помочь ответы на некоторые вопросы. Вот эти вопросы.
1. Является ли понятие “вместилищем” данных?
2. Обладает ли оно отдельными атрибутами, способными принимать разные зна-
чения?
3. Можно ли создать для него множество объектов-экземпляров?
4. Входит ли оно в границы прикладной области?
Перечень классов, приведенный в табл. 2.4, кроме того, вызывает много вопросов.
К примеру, следует задаться такими вопросами.
1. В чем различие между классами Conf iguredComputer и Order? Помимо про-
чего, мы не собираемся хранить информацию о сконфигурированном компью-
тере (Conf iguredComputer), до тех пор пока заказ (объект Order) не разме-
щен, или это не так?
2. Совпадает ли смысл понятия Shipment, приведенный в требованиях №4 и №7?
Скорее всего, нет. Необходим ли нам класс Shipment, если нам известно, что
поставка является обязанностью склада и, таким образом, выходит за рамки
приложения? (Разд. 2.2.2.2).
3. Не является ли понятие элемента конфигурации (Configurationitem) просто
атрибутом понятия сконфигурированного компьютера (Conf iguredComputer)?
4. Является понятие состояние заказа (Orderstatus) самостоятельным классом
или же атрибутом понятия заказа (Order)?
5. Является ли понятие продавца (Salesperson) самостоятельным классом или
же атрибутом понятий (Order) и (Invoice)?
Дать ответы на эти и аналогичные вопросы не легко, для этого требуется глубокое
знание требований прикладной области. В целях дальнейшей работы с данным на-
ставлением мы выбрали классы, перечень которых приведен на рис. 2.27. Обратите
внимание, что класс Customer (Клиент) уже появился в качестве субъекта на диаграм-
ме прецедента — отсюда примечание “с точки зрения прецедента”.
94 Глава 2. Основания анализа требований
Рис. 2.27. Классы (Internet-магазин)
2.2.4.2. Атрибуты
Структура класса определяется его атрибутами (разд. 2.1.2.1). При первоначальном
объявлении класса аналитик должен иметь некоторое представление о структуре ат-
рибутов. На практике основные атрибуты обычно назначаются классу сразу после его
добавления к модели.
Customer
(from Use Case View)
^customer name: String
BScustomer address: String
BHIphone number: String
BSemail address: String
Configurationitem
Я item type: String
0|item descr: String
___________Order___________
E^orderjumber: String
E^order_dae: Date
|2Jshlp_address: String
E^order total: Currency
[SBorder status: String
EJ|salesperson name: String
_______Computer_______
^computer name: String
Standard price: Currency
ConfiguredComputer
Qcomputer_name: String
EJconfigured price: Currency
__________Payment__________
Plpayment method: String
E^date received: Date
Ejamount received: Currency
___________Invoice______
jjlnvoice_number: String
Pjinvoice date: Date
Д Invoice total: Currency
Puc. 2.28. Элементарные атрибуты (Internet-магазин)
2.2. Наставление по моделированию анализа 95
ЛЪа. ri . J- ='«:• . ** -,ПЛГ - - '
f] Наставление по анализу: задание 8 (1п1егпе1-магазин1
I»-' fe» :.U '' OS»~-. -I* < »' ..<Я> * » J* «•*-' S$WS|
5 Обратитесь к заданиям 5, 6 и 7 наставления. Подумайте над атрибутами для классов, ’
показанных на рис. 2.27. Рассмотрите только атрибуты, тип которых принадлежит к |
: элементарным (разд. 2.1.2.1). J
На рис. 2.28 показаны классы с элементарными атрибутами. При этом приведены
только наиболее интересные атрибуты. Атрибуты класса Configurationltein тре-
буют некоторых пояснений. Значениями атрибута item_type являются типы эле-
ментов конфигурации, такие как процессор, память, монитор, жесткий диск и т.д. Ат-
рибут item_descr содержит более подробное описание типа Элемента. Например,
процессор, входящий в конфигурацию, может представлять собой процессор марки
Intel с частотой 600 МГц, имеющий кэш объемом 256 Кбайт.
Совершенно очевидно, что при определении атрибутов, приведенных на
рис. 2.28, существуют широкие возможности для выбора произвольных вариантов.
Если читатель попытается предложить свое собственное решение для этого задания
наставления, то другие, отличные от предложенных в книге, интерпретации возмож-
ны и конечно допустимы.
2.2.4.3. Ассоциации
Ассоциации, связывающие классы, устанавливают пути, облегчающие кооперацию
объектов (разд. 2.1.3). В реализуемой системе ассоциации представляются типами ат-
рибутов, которые обозначают ассоциированные классы (разд. 2.1.2.1.1). В модели
анализа ассоциации представлены соединительными линиями.
&
Наставление по анализу: задание 9 {Internet-магазин)
£' Лг ,........ дп' г--- «.star* s
Обратитесь к предыдущим заданиям наставления. Рассмотрите классы, показанные на •
рис. 2.28. Подумайте, какие пути доступа между этими классами необходимы для пре- !
? цедентов. Добавьте к модели классов ассоциации. j
Рис. 2.29. Ассоциации (Internet-магазин)
96 Глава 2. Основания анализа требований
На рис. 2.29 показаны наиболее очевидные ассоциации между классами. При оп-
ределении кратности ассоциаций был сделан ряд предположений (разд. 2.1.3.2). Заказ
(Order) поступает от одного клиента (Customer), однако клиент может разместить
несколько заказов. Заказ не принимается до тех пор, пока не определены реквизиты
платежа (Payment) (отсюда, ассоциация типа “один к одному”). Заказ не должен обла-
дать связанной с ним счетом-фактурой (Invoice), однако счет-фактура всегда связана
с единственным заказом. Заказ делается на один или несколько сконфигурированных
компьютеров (ConfiguredComputer). А компьютер с данной конфигурацией может
заказываться многократно или не заказываться вовсе.
2.2.4Л. Агрегации
Агрегация и композиция являются более сильной формой ассоциативной связи, ко-
торой присуща семантика принадлежности (разд. 2.1.4). В типичной коммерческой
программной среде агрегация и композиция, скорее всего, должны быть реализованы
подобно ассоциации — с помощью типов атрибутов, которые обозначают ассоцииро-
ванные классы (разд. 2.1.2.1.1).
Наставление поян 1изу: задание10 (1п1егпе1-магазин)
Обратитесь к предыдущим заданиям наставления. Рассмотрите модели, представлен-
j ные на рис. 2.28 и 2.29. Добавьте к модели классов агрегации.
На рис. 2.30 к модели добавлены отношения агрегации. Компьютер (Computer)
обладает (как вы помните, выше говорилось о свойстве принадлежности]) одним или
более элементами конфигурации (Configurationitems). Подобно этому, сконфигу-
рированный компьютер (ConfiguredComputer) состоит из одного или нескольких
элементов (Configurationitems).
Рис. 2.30. Агрегации (Internet-магазин)
2.2.4.5. Обобщения
Обобщение представляет собой мощное средство повторного использования ПО, од-
нако, оно также способно в значительной мере упростить и прояснить модель
2.2. Наставление по моделированию анализа 97
(разд. 2.1.5). Упрощение модели семантически не находит выражения в ее графическом
изображении. Обобщение обычно используют как метод создания дополнительных ро-
довых классов (как правило, абстрактных). Упрощение достигается за счет увеличения
точности, с которой существующий класс может быть ассоциирован с наиболее подхо-
дящими (т.е. на наиболее удобном уровне абстракции) классами в иерархии обобщения.
На рис. 3.31 показана модифицированная модель, в которой класс изменен на абстракт-
ный класс Computer, являющийся родовым для двух конкретных подклассов — Standard
Computer и Conf iguredComputer. Теперь классы Order и Conf igurationltem свя-
заны с классом Computer, который может быть либо классом Standardcomputer, либо
классом Conf iguredComputer.
Рис. 2.31. Обобщение (Internet-магазин)
2.2.4.6. Диаграмма классов
Диаграмма классов составляет, так сказать, “сердце” и “душу” объектно-
ориентированной системы. В данном наставлении ставится цель только продемонст-
рировать возможности статического моделирования применительно к модели классов.
В классы пока что не введено ни одной новой операции. Операции принадле-
жат скорее к сфере проектирования, чем анализа. После того, как операции в ко-
нечном итоге вводятся в классы, модель классов в явном виде определяет поведе-
ние системы.
98 Глава 2. Основания-анализа требований
rtnirrnrinniiiri nn auaHH&v эдлгшиа ЛИЕИКМВДГЗгШВйЙ j,
•.._ •&.4?-л*#?'.. _. z _ ''-•
Обратитесь к предыдущим заданиям наставления. Скомбинируйте модели, представлен-
ные на рис. 2.28 и 2.30, таким образом, чтобы показать полную диаграмму классов. Изме-
ните содержимое атрибутов классов, как того требует введение обобщающей иерархии.
На рис. 2.32 показана диаграмма классов для приложения Intemel-магазин. Это еще
не законченное решение, поскольку, например, для практического решения может
потребоваться введение дополнительных атрибутов.
Рис. 2.32. Диаграмма классов (Internet-магазин)
2.2.5. Моделирование взаимодействий
Моделирование взаимодействий (interaction modding) охватывает вопросы взаимодейст-
вия между объектами, необходимыми для выполнения прецедента. Модели взаимодей-
2.2. Наставление по моделированию анализа 99
ствия используются на более развитых стадиях анализа требований, когда становится
известной модель классов, так что ссылки на объекты опираются на модель классов.
Приведенное выше наблюдение служит опорой для установления основного раз-
личия между моделированием видов деятельности (см. разд. 2.2.3) и моделированием
взаимодействий. Модели обоих типов описывают поведение одного прецедента (как
правило). Однако, моделирование видов деятельности осуществляется на более высоком
уровне абстракции — оно отражает последовательность событий вне связи событий с
объектами. Моделирование взаимодействий отображает последовательность событий
(сообщений) в их связи с действующими в кооперации объектами.
Диаграммы взаимодействий разделяются на два вида — диаграммы последовательно-
стей и диаграммы кооперации. Они могут использоваться как взаимозаменяемые, и, ко-
нечно, многие CASE-средства поддерживают автоматическое преобразование одной
модели в другую. Разница между моделями заключается в акцентах. Модели последова-
тельностей концентрируются на временных последовательностях событий, а в моделях
кооперации основное внимание уделяется отношениям между объектами [76].
В настоящей книге для этих типов моделей выбрано следующее применение: диа-
граммы последовательностей используются на этапе анализа требований, а диаграм-
мы кооперации — системного проектирования. Этот выбор соответствует общепри-
нятой практике разработки ИС.
2.2.5.1. Взаимодействия
Взаимодействие (interaction) представляет собой набор сообщений, свойственных
поведению некоторой системы, которыми обмениваются объекты в соответствии с ус-
тановленными между ними связями (последние могут быть постоянными или времен-
ными (разд. 2.1.1.3)). Диаграмма последовательностей представляется' двумерным
графом. Объекты располагаются по горизонтали. Последовательности сообщений
располагаются сверху вниз по вертикали. Каждая вертикальная линия называется ли-
нией жизни (lifeline) объекта (см. рис. 2.33).
Стрелки представляют каждое сообщение, направляемое от вызывающего объекта
(отправителя) к операции (методу) вызываемого объекта (получателя). Для каждого
сообщения, как минимум, указывается его имя. Кроме того, для сообщения могут
быть указаны фактические аргументы сообщения и другая управляющая информа-
ция. Фактические аргументы соответствуют формальным аргументам метода объекта-
получателя.
Фактические аргументы могут быть входными аргументами (передаются от отправителя
к получателю) или выходными аргументами (передаются от получателя назад к отправите-
лю). Входные аргументы могут быть обозначены ключевым словом in (если ключевое
слово отсутствует, то предполагается, что аргумент — входной). Выходные аргументы обо-
значаются ключевым словом out. Допускаются также аргументы типа inout (“входные-
выходные”), однако, для объектно-ориентированного подхода они не характерны. Сооб-
щение getCourseName (см. разд. 2.1.1.3.1), отправленное объекту, обозначенному пере-
менной crs_ref, имеет один выходной аргумент и ни одного входного:
crs_ref.getCourseName(out crs_name)
Показывать на диаграмме возврат управления от объекта-получателя объекту-
отправителю не обязательно. Стрелка, указывающая на объект-получатель, предпола-
гает автоматический возврат управления отправителю. Получатель знает уникальный
идентификатор объекта (OID) отправителя.
100 Глава 2. Основания анализа
Сообщение может быть отправлено коллекции (collection) объектов (коллекция мо-
жет быть набором, списком, массивом объектов и т.д.)- Довольно частой является си-
туация, когда вызывающий объект связан с несколькими объектами-получателями
(поскольку кратность ассоциации указана как “один ко многим” или “многие ко мно-
гим”). Итеративный маркер— звездочка перед обозначением сообщения — указывает
на процесс итерации сообщения по всей коллекции.
Обратитесь к диаграмме видов деятельности на рис. 2.26. Рассмотрите первый шаг
диаграммы Display Current Configuration. Постройте диаграмму последователь-
ностей для этого шага.
Диаграмма последовательностей для “отображения текущей конфигурации ” пока-
зана на рис. 2.33. Внешний субъект— клиент— (Customer) принимает решение об
отображении конфигурации компьютера. Сообщение openNew (открыть новое
[окно]) отправляется объекту ConfWin класса Configurationwindow ([диалоговое]
окно конфигурации). В результате создается (“материализуется как экземпляр”) новый
объект ConfWin. (Класс Configurationwindow — пограничный класс (разд. 2.2.4.1).)
aConfWin: ,
aComp:
Computer
: Configuration
Item
openNew
getConf
displaycomputer (itemrecset)
getConfltem (out item rec) ।
Puc. 2.33. Диаграмма последовательностей для вида деятельности Display Current
Configuration ( Internet-магазин)
Объекту ConfWin необходимо “отобразить себя” вместе с данными, относящимися к
конфигурации. С этой целью он отправляет сообщение объекту aComp:Computer. В
действительности, aComp— это объект класса Standardcomputer или
Conf iguredComputer. Класс Computer — абстрактный класс (рис. 2.31 в разд. 2.2.4.5).
Объект aComp использует выходной аргумент для того, чтобы “собрать себя” из
элементов конфигурации — объектов Configurationitem. Затем он “оптом” отсыла-
ет элементы конфигурации объекту aConfWin в качестве аргумента i recset сооб-
щения displaycomputer. Теперь объект aConfWin может отобразить себя. На экра-
не компьютера выводится изображение, подобное показанному на рис. 2.34.
2.2. Наставление по моделированию анализа 101
Обратите внимание, что поля для выбора на рис. 2.34 в начале отображают эле-
менты стандартной конфигурации. Однако, эти поля для выбора заполнены другими
не стандартными элементами, которые клиент может выбрать для создания новой
допустимой конфигурации. Диаграмма последовательностей на рис. 2.33 не модели-
рует способ и время заполнения полей выбора данными.
Base Price: AU$3399 Including Tax (Ex tax Price:
AU$2924)
Current specifications and prices should be regularly checked.
For component specifications please click the underlined text. з
Processor: Intel® Pentium® III Processor 700MHz
Memory: |128MB sdram “ “
Cache: 256К On-die L2 Cache Hard Drive: |20GB Ultra ATA HDD (7200 rpm) £1 X
Drive: 1 44MB 3.5“ Diskette Drive ’»*? .4!
NOiWPrK Card: CD/DVD Player: <1 Not included 'Ы v J? %: - - - « *
12X DVD-ROM Drive jft
Puc. 2.34. Пример окна выбора конфигурации (Internet-магазин)
2.2.5.2. Операции
Хотя введение операций в классы зачастую откладывается до этапа проектирова-
ния, в данном наставлении будет показано, что исследование взаимодействий между
классами может привести к выявлению операций. Между взаимодействиями и опера-
циями существует прямая зависимость. Каждое сообщение обращается к операции в вы-
зываемом объекте. Имена операции и сообщения совпадают.
Конечно, это однозначное отображение между сообщениями модели взаимодейст-
вий и методами реализуемых классов может иметь смысл только в том случае, если мо-
дель взаимодействий образует детализированный технический проект, что вряд ли
возможно и может потребоваться на этапе анализа.
102 Глава 2. Основания анализа требований
Попутно заметим, что подобное однозначное соответствие существует между сооб-
щениями и ассоциациями, когда сообщение пересылается между постоянными
(модельными) объектами. Эти сообщения должны поддерживаться постоянными свя-
зями (разд. 2.1.1.3.1). Таким образом наличие сообщения в диаграмме последователь-
ностей обусловливает необходимость в ассоциации в диаграмме классов.
Обратитесь к диаграмме видов деятельности на рис. 2.32 и диаграмме последовательностей
на рис. 2.33. Для каждого сообщения о взаимодействии на диаграмме последовательностей
введите операцию в соответствующий класс на диаграмме классов. Не перерисовывайте всю
диаграмму классов—только отобразите классы, расширенные за счет операций.
Решение для этого задания наставления показано на рис. 2.35. Изменениям под-
верглись три класса. Класс Configurationwindow — это пограничный класс. Два дру-
гих класса— это классы-сущности, представляющие постоянные объекты базы дан-
ных. Операция openNew выбрана в качестве шаблона операции конструктора. Это оз-
начает, что операция openNew будет реализована в качестве метода конструктора,
который порождает новые объекты класса.
«boundary»
Configurationwindow
«constructor» openNew()
displayComp uter(item recset)
_______Computer_____
computer name: String
«abstract» getConf()
______Configurationitem
Bl item type: String
BW item_descr: String
getConf I tern (out itemrec)
Puc. 2.35. Использование взаимодействий для введения опе-
раций в классы (Internet-магазин)
Класс Computer — абстрактный класс. Операция getConf — абстрактная операция,
наследуемая подклассами (ConfiguredComputer и Standardcomputer). Эти под-
классы обеспечивают собственную реализацию операции getConf.
2.2.5.3. Диаграмма последовательностей
Как уже упоминалось, для каждого прецедента зачастую строится отдельная диа-
грамма последовательностей. Поскольку каждый прецедент вероятно должен быть
выражен через диаграмму видов деятельности, диаграмма последовательностей стро-
ится для каждой диаграммы видов деятельности. Использование нескольких взаимо-
увязанных точек зрения на одну и ту же систему является краеугольным камнем над-
лежащего моделирования.
Решение для сформулированных выше вопросов показано на рис. 2.36. Для удоб
ства диаграмма последовательностей разделена на две части (а именно, линии жизни
объектов Order и Orderwindow разделены на две части).
2.2. Наставление по моделированию анализа 103
: Customer
: Configuration
Window
: Computer
: Order :OrderWtndow
openNew
getConf
acceptConf
I
prepareforOrder
displ^Order
submitOrder
storeOrder
e mailorder
: Order
: OrderWindow
displsyOrder
storeOrder
Computer
linkCustomer
linkComputer
linkcustomer
: Customer
linkPa
: Payment
linkPayment
Puc. 2.36. Диаграмма последовательностей для диаграммы видов деятельности
Order Configured Computer (Internet-магазин)
104 Глава 2. Основания анализа требований
Обратитесь к диаграмме видов деятельности на рис. 2.26 и постройте для нее диаграм- ;
му последовательностей. Чтобы упростить диаграмму, не показывайте обмен сообще- '
ниями между объектами Computer и Configurationitem. ;
Кроме того, не изображайте объектов подклассов — считайте, что объект computer
принадлежит либо классу Standardcomputer, либо классу Conf iguredComputer. <
Покажите только сообщения активизации. Возвраты управления подразумеваются. За- :
давать аргументы операций или другую управляющую информацию нет необходимости, t
Диаграмма последовательностей во многом является самоочевидной. Пояснения к
первым двум сообщением были сделаны в задании 13 наставления. Сообщение
acceptConf вызывает отправку сообщения prepareForOrdeг объекту : Order. Это
приводит к созданию временного объекта : Order, отображаемого в “объекте-окне”
:OrderWindow.
В ответ на принятие клиентом детализированных условий заказа (submitOrder) объ-
ект : OrderWindow инициирует (storeOrder) создание постоянного объекта : Order.
После этого объект-заказ : Order устанавливает связь с заказанным компьютером
(: Computer), а также соответствующими клиентом (: Customer) и платежом : Payment.
После того, как эти объекты постоянно связаны в базе данных, объект : Order отправляет
электронное сообщение emailOrder внешнему субъекту-клиенту (Customer).
Обратите внимание на двойное использование сущности : Customer — в качестве
внешнего субъекта, представленного объектом, и внутреннего объекта-класса. По-
добная двойственность довольно часто встречается в моделировании. Клиент
(Customer) является по отношению к системе одновременно и внешней, и внутрен-
ней сущностью. Он представляет собой внешнюю сущность, поскольку взаимодейст-
вует с системой извне. Однако информация о клиенте должна храниться в системе,
чтобы иметь возможность установить идентичность внешнего клиента и внутренней
сущности, о которой знает система.
2.2.6. Моделирование состояний
Модель взаимодействий (interaction model) является источником детализированной
спецификации прецедента. Модель состояний (statechart model) служит детализирован-
ным описанием класса или, более точно, динамических изменений состояний класса.
Эти динамические изменения обычно описывают поведение объекта в рамках не-
скольких прецедентов.
Состояние (state) объекта обозначается текущими значениями его атрибутов (как
элементарных атрибутов, так и атрибутов, обозначающих другие классы). Модель со-
стояний (statechart model) фиксирует возможные состояния, в которых может находить-
ся класс, и эффективно фиксирует “жизненный путь” класса. На протяжение своего
жизненно цикла объект остается одним и тем же — его идентичность никогда не из-
меняется (разд. 2.1.1.3). Однако состояние объекта изменяется.
Диаграмма состояний представляет собой двудольный граф состояний
(прямоугольников с закругленными углами) и переходов (стрелки), вызванных собы-
тиями. Основная концепция состояний и событий совпадает с концепцией, которая
известна нам по диаграмме видов деятельности. Различие же заключается в том, что
“состояния графа видов деятельности представляют состояния выполнения вычисле-
ния, а не состояния обычного объекта” [76].
2.2. Наставление по моделированию анализа 105
2.2.6.1. Состояния и переходы
Значения атрибутов объекта изменяются, однако не все подобные изменения
приводят к переходу между состояниями. Рассмотрим объект BankAccount
[банковский счет) и связанное с ним бизнес-правило, по которому банк отказывает-
:я от взимания платы за услуги по ведению счета, когда остаток на счету (balance)
превышает 100000 долларов. Можно сказать, что объект BankAccount переходит в
привилегированное (priviledged) состояние. В противном случае объект пребы-
вает в обычном состоянии. Остаток на счету (balance) изменяется после каждого
перехода, соответствующего операции по снятию/вкладу денег, однако, состояние
«меняется только тогда, когда баланс превышает или становится ниже порога в
100000 долларов.
L? Наставление по ан^^^||йнйё ^I|i
Рассмотрите класс Invoice (Счет-фактура), относящийся к приложению Internet- •
магазин. Из модели прецедентов нам известно, что клиент определяет способ оплаты )
(кредитная карточка или чек) за компьютер, когда закупочная форма заполнена и ото- *
слана производителю. Это приводит к генерации заказа и последующей подготовке ‘
счет-фактуры. Однако, диаграмма прецедентов не проясняет вопрос о том, когда же [
производится фактическая оплата в соответствии со счет-фактурой. Можно, к примеру, {
предположить, что оплата может осуществляться до или после того, как счет-фактура i
выдана, а также предположить возможность частичной оплаты. I
Из модели класса нам известно, что счет-фактура для заказа подготавливается продавцом, •
однако, в конечном итоге она передается на склад. Склад отправляет счет-фактуру клиенту ;
одновременно с доставкой компьютера. Важно отметить, что состояние оплаты счет-фактуры ;
отслеживается в системе, так что счет-фактуры снабжены надлежащими комментариями. |
Изобразите диаграмму состояний, которая фиксирует возможные состояния счет- !
фактуры в той мере, в которой это касается платежей. >
Приведенный выше пример схватывает сущность моделирования состояний. Моде-
ли состояний строятся для классов, которые характеризуются не просто изменениями
состояний, а изменениями состояний, представляющими определенный интерес с точ-
ки зрения предметной области. Решение о том, что представляет интерес, а что нет, яв-
ляется прерогативой моделирования бизнес-процессов. Диаграмма состояний пред-
ставляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила
остаются неизменными. Они относительно независимы от конкретных прецедентов. В
действительности прецеденты должны соответствовать бизнес-правилам.
На рис. 2.37 показана модель состояний для класса Invoice. Начальным состоя-
нием объекта Invoice является состояние Unpaid (не оплачено). Из состояния
Unpaid возможны два перехода. При наступлении события partial payment
(частичная оплата) объект Invoice переходит в состояние Partly Paid (частично
оплачено). Допускается только одна частичная оплата. Наступление события final
payment (окончательная оплата), когда объект Invoice находится в состоянии
Unpaid или Partly Paid, инициирует переход в состояние Fully Paid (полностью
оплачено). Это конечное состояние.
106 Глава 2. Основания анализа требований
Рис. 2.37. Состояния и события для класса
Invoice (1п1етеЬмагазин)
2.2.6.2. Диаграмма состояний
Диаграмма состояний обычно присоединяется к классу, но, в общем случае, она
может присоединяться к другим модельным представлениям, например, прецеден-
там. Диаграмма состояний, присоединенная к классу, определяет способ реагирова-
ния объектов класса на события. Более точно, диаграмма определяет — для каждого
состояния объекта — действие (action), выполняемое объектом при получении им сиг-
нала о событии. Один и тот же объект может выполнять различные действия в ответ
на одно и то же событие в зависимости от состояния объекта. Выполнение действия,
как правило, вызывает изменение состояния.
Полное описание перехода (transition) состоит из трех частей:
event (parameters) [guard] / action.
Каждая из частей является необязательной. Если строка перехода самоочевидна,
допустимо опустить все компоненты. Событие — это кратковременное явление, кото-
рое воздействует на объект. Оно может обладать параметрами, например, кнопка
мыши нажата (правая_кнопка). Событие может быть защищено ограждающим усм
вием (guard), например, кнопка мыши нажата (правая_кнопка) [внутри окна].
Только в том случае, если условие принимает значение “истина”, событие срабатыва-
ет и воздействует на объект.
Различие между событием и защитой не всегда очевидно. Это различие состоит в
том, что событие “происходит” и оно может быть даже сохранено до тех пор, пока
объект не приготовится к его обработке. С этих позиций защитное условие проверя-
ется на истинность, чтобы определить, должен ли сработать переход.
Действие (action) представляет собой короткое атомическое вычисление, которое вы-
полняется при срабатываний перехода. Действие также может быть связано с состоянием.
В общем случае действие — это отклик объекта на обнаруженное событие. Состояние мо-
жет содержать более продолжительное вычисление — вид деятельности (activity).
Состояние может состоять из других состояний, которые называются вложенными
(nestedstate). Составное состояние (composite state) является абстрактным — это всего лишь
родовое имя для всех вложенных состояний. Переход, который берет начало из-за
границы составного состояния, означает, что он может сработать от любого из вло-
женных состояний. Это делает диаграмму более ясной и лаконичной. Конечно, пере-
2.2. Наставление по. моделированию анализа 107
ход, который берет начало вне границы составного состояния, может сработать от
вложенного состояния.
Диаграмма состояний для класса Order показана на рис. 2.38. Начальное состоя-
ние объекта класса — New Order (новый заказ). Это одно из вложенных состояний со-
ставного состояния Pending (ожидающий [заказ]) — к другим относятся состояния
Back Order (невыполненный заказ) и Future Order (будущий заказ). Из каждого из
этих трех состояний, вложенных в состояние Pending, возможны два перехода.
Рис. 2.38. Диаграмма состояний для класса Order (Internet-магазин)
|Г7 НаЬтавлениё по анализ: 17,
Обратитесь к предыдущим заданиям наставления. Рассмотрите класс Order (заказ), отно- I
сящийся к приложению /nternef-магазин. Обдумайте, в каких состояниях может находиться I
класс Order, начиная от отправки заказа в систему и заканчивая его заполнением.
Рассмотрите ситуации, когда заказанный компьютер находится на складе в готовом ви- j
де или же его необходимо сконфигурировать в отдельности, чтобы удовлетворить ваши [
требования. Вы можете также задать определенный день, в который вы бы хотели полу- j
чить компьютер, даже если он имеется на складе. !
Вы можете отменить ваш заказ в любое время прежде, чем компьютер будет доставлен. [
Вам не требуется моделировать ситуацию взимания штрафа, связанную со слишком I
поздним отказом. Изобразите диаграмму состояний для класса Order.
Переход в состояние Canceled (отменен) защищено условием [canceled]. Должна
существовать возможность — без изменения правил моделирования состояний — заме-
нить защитное условие событием cancel. Переход в состояние Ready to Ship (готов к
дос тавке) помечен полным описанием, содержащим событие, защиту и действие.
108 Глава 2* Основания анализа требований
2.3. Постановки задач для исследуемых
примеров
Чтобы проиллюстрировать различные виды деятельности по моделированию, на
протяжении всей книги разбираются четыре примера. Разбор примеров представлен
с использованием того же подхода, который использовался для наставления “Internet-
магазин” — сначала формулируются вопросы, а затем даются решения. Это дает воз-
можность читателям предложить собственные решения, а затем сравнить их с пред-
ложенными в книге. Итак, мы разберем следующие четыре примера.
1. Запись на университетские курсы.
2. Магазин видеопроката.
3. Управление контактами с клиентами.
4. Телемаркетинг.
2.3.1. Запись на университетские курсы
Запись на университетские курсы — классический пример из учебников [66], [85].
Это удивительно сложная прикладная область с богатым набором бизнес-правил, ко-
торые относительно часто изменяются, при этом данные за прошлые периоды долж-
ны тщательно храниться вместе с действовавшими на то время бизнес-правилами.
Средний по размерам университет проводит набор студентов и аспирантов дневной и I
вечерней формы обучения для подготовки по ряду специальностей. Учебная структура унив- |
ерситета состоит из факультетов. Факультет имеет в своем составе несколько кафедр. Хотя !
обучение и присвоение степени по определенной специальности является прерогативой ।
факультета, обучение по специальности может включать дисциплины, преподаваемы на \
других факультетах. В действительности, университет гордится свободой, предоставляемой
им студентам в выборе дисциплин, изучаемыхдля получения специальности.
Гибкость выбора учебных курсов оказывает дополнительную нагрузку на университетскую ।
систему набора. Индивидуально подобранным программам обучения должны быть противо-
поставлены правила, регулирующие получение степени по выбранной специальности. Такие
правила можно сформулировать, например, в виде структуры дисциплин, изучение которых
является обязательной предпосылкой получения диплома, так, чтобы студент мог прослушать
обязательные для данной специальности курсы. Выбор студентами дисциплин может быть
ограничен несоответствием расписаний, максимальной вместимостью аудиторий и т.д.
Гибкость в получении^образования, предлагаемого университетом, стала одной из при-
чин устойчивого роста количества студентов. Однако, для сохранения своих традицион-
но сильных сторон система набора — по-прежнему, частично ручная — должна быть за-
менена новым программным решением. Предварительный поиск готовых программных
пакетов не дал результатов. Университетская система набора достаточно уникальна,
чтобы оправдать разработку ПО собственными силами.
От системы требуется оказывать помощь в предварительной деятельности по записи на
курсы и управляться с процедурами набора. Предварительная деятельность по записи
должна включать рассылку оценок последнего семестра студентам наряду с инструк-
циями по записи на лекции. В период записи на курсы система должна принимать заяв-
ленные студентами программы обучения и проверять их на предмет обязательности,
конфликтов расписания, вместимости аудиторий, специальных санкций и т.д. Решения
по некоторым проблемам могут требовать консультаций с научными руководителями
или профессорами, ответственными за преподавание дисциплин.
2.3. Постановки задач для исследуемых примеров 109
Двух одинаковых университетов не существует. У каждого есть собственные любо-
пытные особенности, которые можно использовать при разборе примеров, чтобы уде-
лить основное внимание определенным аспектам системного анализа и проектирова-
ния. Основное внимание при разборе данного примера посвящается сложностям, кото-
рые возникают при моделировании состояний, связанным с обработкой временных
факторов (временной информации) и добыванием бизнес-правил в структуры данных.
2.3.2. Магазин видеопроката
Наш второй пример — обычное бизнес-приложение, характерное для малого биз-
неса. Это приложение предназначено для поддержки работы небольшого магазина
видеопроката. В видеомагазине имеется широкий выбор последних и наиболее попу-
лярных фильмов на видеокассетах и компакт-дисках. Основным видом деятельности
магазина является прокат видеофильмов.
Типичную компьютерную систему для поддержки работы небольшого видеомага-
зина можно получить посредством настройки готового ПО или настройки какого-
либо другого патентованного решения. Система может базироваться на одной из по-
пулярных систем управления базами данных (СУБД), способной функционировать на
компьютере, ресурсов которого хватает для решения задач малого бизнеса.
Несмотря на то, что базис системы составляет ПО баз данных, она может быть по-
началу развернута на одной машине. GUI-интерфейс должен, вероятно, разраба-
тывться с использованием простого языка четвертого поколения (4GL), с возможно-
стями создания экранных изображений, генерации программного кода и простым
подключением к базе данных.
Отличительной чертой магазина видеопроката как примера для анализа является
развитая цепочка видов деятельности — начиная с заказа видеопродукции с помощью
управления ассортиментом и до расчетов с пользователями за прокат видеофильмов.
В известном смысле — это модель цепочки ценностей, функционирующей в ограни-
ченных масштабах (см. 1.2.2).
Вновь открывшийся видеомагазин намерен предложить прокат видеокассет и дисков ши-
рокой публике. Директор магазина полон решимости начать свою деятельность, опираясь
! на поддержку компьютерной системы. Директор уже навел справки по некоторым про-
граммным пакетам для малого бизнеса, которые могли бы пригодиться для настройки и
: последующего развития. Для оказания помощи в выборе пакета магазин нанял бизнес-
аналитика, который занимается определением и спецификацией требований.
' Поначалу ассортимент магазина составляет около тысячи видеокассет и пятьсот видео-
дисков. Запас уже заказан у одного поставщика, однако, для будущих заказов директор
намерен прибегать к услугам большего числа поставщиков. Все видеокассеты и диски
< снабжены штрих-кодом, так что сканер, интегрированный в систему, может поддержи-
вать операции выдачи напрокат и возврата видеофильмов. Членские карточки клиентов
< также снабжены штрих-кодом.
Существующие клиенты имеют возможность резервировать видео таким образом, что-
бы комплект видеофильмов был собран к определенной дате. Система должна обладать
гибким поисковым механизмом для ответов на запросы клиентов, включая вопросы, ка- *
сающиеся фильмов, которых нет в ассортименте магазина (но которые он может зака- !
; зать по просьбе клиента). I
I
110 Глава 2. Основания анализа требований
2.3.3. Управление контактами с клиентами
Управление контактами с клиентами — это “горячая” проблемная область. Боль-
ше известное под аббревиатурой CMS (Customer Management System — система
управления работой с клиентами) управление контактами представляет собой важ-
ную составляющую ERP-систем (Enterprise Resource Planning — планирование ре-
сурсов предприятия). ERP-системы автоматизируют так называемые конторские
(back office) приложения обработки деловых операций. К трем наиболее типичным
компонентам ERP-систем относятся: бухгалтерский учет, производство и управле-
ние людскими ресурсами. CMS-системы принадлежат к компонентам управления
людскими ресурсами.
ERP-система— очень масштабное настраиваемое решение. Некоторые специали-
сты называют их мега-пакетами. Вполне естественно, что CMS-компонета ERP-
решения может быть очень сложной. В нашем примере мы касаемся только неболь-
шой части проблемной области CMS.
Приложения по управлению контактами с клиентами отличаются весьма интерес-
ными решениями в отношении GUI-интерфейса, с помощью которого работники
службы связей с клиентами (Customer Relations) или аналогичного подразделения мо-
гут планировать свою деятельность, касающуюся клиентов. По сушеству GUI-
интерфейс системы управления контактами работает как ежедневник по записи зада-
ний и событий, связанных с клиентами, и позволяет следить за их ходом.
Подобный электронный ежедневник должен быть ориентирован на использова-
ние базы данных, позволяющей осуществлять динамическое планирование и отсле-
живать задания и события в отношении большого количества работников фирмы.
Подобно большинству систем управления людскими ресурсами приложения по
управлению контактами с клиентами требуют изощренной схемы авторизации для
управления доступом к закрытой информации.
| Компания, занимающаяся иследованием рынка, обладает стабильной клиентской базой
I организаций, которые приобретают отчеты по анализу рынка. Некоторые крупные кли- i
1 енты приобретают у компании также специализированное ПО, предназначенное для ,
I создания отчетов. Этих клиентов компания также обеспечивает необработанной и агре-
! гированной информацией для генерации их собственных отчетов.
j Компания постоянно ищет новых клиентов, даже если новые клиенты заинтересованы '
। только в получении однократных, узкоспециализированных отчетов по рынку. Хотя пер-
i спективные клиенты — это в полном смысле еще клиенты, компания стремится устано-
; вить с ними контакт — отсюда, система управления контактами с клиентами (контакты
। бывают с перспективными, реальными и прошлыми клиентами).
I Новая система управления контактами должна разрабатываться своими силами и нахо-
j диться в распоряжении всех работников компании, но с предоставлением различного
I уровня доступа. Сотрудники отдела обслуживания клиентов (Customer Services
? Department) берут шефство над системой. Система должна обеспечить гибкое планиро-
; вание и перепланирование видов деятельности, связанных с контактами, так чтобы со-
• трудники могли успешно кооперировать свои усилия в завоевании новых клиентов и
j стимулировании существующих взаимоотношений с клиентами.
Резюме 111
2.3.4. Телемаркетинг
Многие организации продают свои товары и услуги с использованием телемарке-
тинга. Телемаркетинг — это прямое обращение к потребителям с помощью телефона.
Система телемаркетинга требует поддержки детально продуманного процесса плани-
рования телефонных звонков, осуществляемых продавцами, оказания помощи в под-
держании разговора и фиксирования результатов разговора.
Одной из характерных особенностей систем телемаркетинга является сильная за-
висимость от способности базы данных активно планировать и динамически пере-
планировать телефонные звонки при поддержке параллельных разговоров. Другим
интересным аспектом таких систем является возможность автоматического набора
запланированного телефонного номера.
< Благотворительное общество продает лотерейные билеты для пополнения своего бюд-
| жета. Пополнение бюджета осуществляется в рамках кампании, направленной на под-
• держку текущих важных благотворительных мероприятий. Общество хранит список бла-
i готворителей (жертвователей). Для каждой новой кампании часть этих благотворителей
» заранее выбирается для обращения к ним с использованием телемаркетинга, а также,
; возможно, с помощью прямых обращений по почте.
i Чтобы завоевать новых приверженцев, общество использует некоторые новейшие схемы.
! Эти схемы включают специальные призовые кампании для вознаграждения благотворите-
I лей, закупающих лотерейные билеты в массовом количестве, для привлечения новых
; жертвователей и т.д. Общество не обращается к случайным потенциальным благотворите-
s лям с использованием телефонных справочников или других подобных средств.
! Для поддержки своей деятельности общество решило заключить контракт на разработ-
i ку нового телемаркетингового приложения. От новой системы требуется поддерживать
• около пятидесяти сотрудников службы телемаркетинга, работающих одноаременно.
: Система должна давать возможность планировать телефонные звонки в соответствии с
' заранее заданными приоритетами и другими известными ограничениями.
’ От системы требуется устанавливать соединения в соответствии с запланированными
, телефонными звонками. В случае неудачных попыток соединения звонки должны быть
: перепланированы так, чтобы можно было попытаться дозвониться позже. Обратные
> звонки от приверженцев также должны упорядочиваться. Результаты разговора, вклю-
; чая заказ лотерейных билетов и какие-либо изменения, касающиеся данных о благотво-
< ригелях, должны сохраняться.
Резюме
В данной главе нам удалось охватить значительную часть вопросов, связанных с
основаниями анализа требований. Были введены основополагающие термины и по-
нятия, касающиеся объектной технологии. При изложении принципов объектного
моделирования были использоааны многочисленные поясняющие примеры, включая
детальное наставление. Для новичков задания, должно быть, показались пугающими
или унылыми. Награда за настойчивость не заставит себя ждать — она придет в сле-
дующих главах.
Объектная система состоит из взаимодействующих объектов-экземпляров. Каждый
объект обладает состоянием, поведением и идентичностью. Последнее понятие явля-
ется, наверное, самым существенным для правильного понимания объектных систем;
112 Глава 2. Основания анализа требований
в то же время его также труднее всего оценить людям, имеющим за плечами опреде-
ленный опыт в отношении традиционных компьютерных приложений. Перемеще-
ние по связям представляет собой modus operandi объектной технологии — нечто, что
воспитанному на технологии реляционных баз данных читателю в действительности
трудно переварить.
Класс— это шаблон, по которому создаются объекты. Он определяет атрибуты, ко-
торые объект может содержать, и операции, которые объект может вызывать. Атрибу-
ты могут относиться к элементарному типу или обозначать другие классы. Атрибуты,
которые обозначают другие классы, служат объявлением ассоциаций. Ассоциации —
это один из видов отношений между объектами. В качестве других типов отношений
выступают агрегации и обобщения.
Отношение обобщения обеспечивает основу для полиморфизма и наследования.
Коммерческие программные среды могут поддерживать множественное наследование,
но маловероятно, чтобы они поддерживали множественную или динамическую класси-
фикацию. С наследованием связано понятие абстрактного класса. Класс может обладать
атрибутами и операциями, которые применимы только к нему, но не применимы ни к
одному из его объектов-экземпляров. Подобные атрибуты и операции требуют введе-
ния понятия объекта-класса.
Понятия объектной технологии были закреплены в наставлении, сконцентрированном
на разработке приложения для Internet-магазина. В наставлении был введен полный набор
методов моделирования языка UML — моделирование прецедентов, видов деятельности,
классов, взаимодействий и моделирование состояний. Перечисленные методы представ-
лены на относительно высоком уровне абстракции, при этом многие детали моделирова-
ния были опущены. В последующих главах эти детали будут уточнены.
Наконец, мы сформулировали постановки задач для четырех конкретных разбираемых
примеров, которые должны использоваться позже (наряду с наставлением) для иллюст-
рации и объяснения более сложных методов моделирования анализа и проектирования.
Разбираемые примеры относятся к таким областям, как запись на университетские кур-
сы, магазин видеопроката, управление контактами с клиентами и телемаркетинг.
И Вопросы
В1. в чем состоит необходимость различения объектов-экземпляров и объектов-классов?
В2. Что такое идентификатор объекта?
ВЗ. В чем заключается различие между временными и постоянными объектами?
В4. Что такое временная и постоянная связь? Каким образом они используются во время вы-
полнения программы?
В5. Что подразумевают, когда говорят, что тип атрибута обозначает класс? Приведите пример.
Вв. Хорошая объектная модель отличается тем, что большинство атрибутов в ней закрытых, а
большинство операций — открытых. Почему?
В7. В чем различие между понятиями видимости и области действия операции?
В8. В какой ситуации при моделировании должен использоваться ассоциативный класс? При-
ведите пример.
В9. В чем различие между композицией и агрегацией?
В10. Объясните смысл замечания о том, что в типичной объектной среде программирования
наследование применяется к классам, а не к объектам?
Упражнения 113
В11. Какова связь между переопределением и полиморфизмом?
В12. Что такое сигнатуре?
В13. В чем различие между множественной классификацией и множественным наследованием?
В14. В чем преимущества использования абстрактных классов для моделирования?
В15. Объясните, в чем состоят основные отличительные черты и принципиальные отличия меж-
ду моделью состояний, моделью поведения и моделью изменения состояний?
В1в. Может ли субъект обладать атрибутами и операциями? Объясните саой ответ.
В17. Объясните, какова роль и место диаграммы видов деятельности в системном моделировании?
В18. В чем различие между ветвлением по условию и разделением потоков управления на диа-
граммах видов деятельности? Приведите пример.
В19. Что такое классы-сущности?
В20. Что такое фактический аргумент и что такое формальный аргумент?
В21. В чем состоит различие между действием и деятельностью на диаграмме состояний? При-
ведите пример.
5| Упражнения
У1. Обратитесь к рисунку 2.13 (разд. 2.1.3.2). Предположим, что предлагаемые учебные курсы
включают лекции и практические занятия. При этом возможно, что один преподаватель от-
вечает за лекционную часть курса, а другой — за практическую.
Модифицируйте диаграмму на рис. 2.13 таким образом, чтобы учесть изложений выше факт.
У2. Обратитесь к рисунку 2.15 (разд. 2.1.3.4).
Постройте альтернативную модель, которая не использует ассоциативного класса и не ис-
пользует тернарную ассоциацию (поскольку мы вообще не рекомендуем использование
тернарных ассоциаций). Если между моделью, представленной на рис. 2.15, и вновь по-
строенной моделью существуют семантические различия, опишите их.
УЗ. Обратитесь к рисунку 2.19 (разд. 2.1.5.2.1).
Расширьте пример за счет введения новых атрибутов в классы Teacher (Преподаватель),
Student (Студент), Postgraduatestudent (Аспирант) и Tutor (Наставник).
У4. Internet-магазин — обратитесь к заданию 2 (разд. 2.2.2.2).
Пункт 6 а табл. 2.1 говорит о том, что клиенту должно быть отправлено сообщение по элек-
тронной почте, так что он может проверить состояние заказа через Internet. Прецедент,
представляющий это событие, отсутствует. Можно ли его ввести? Объясните ваш ответ.
У5. Internet-магазин — обратитесь (в качестве примера) к заданию 2 (разд. 2.2.2.2) и заданию
3 (разд. 2.2.2.4).
Подготовьте документ описания прецедента для прецедента Update Order Status
(Обновить состояние заказа). Прецедент дает возможность клиенту проверить состояние
заказа на компьютер.
Отражает ли имя прецедента его функциональное назначение? Можно ли его изменить на
другое имя?
Уб. Internet-магазин — обратитесь к заданию 9 (разд. 2.2.4.3).
На рис. 2.29 класс Customer (Клиент) не связан непосредственно с классами Payment
(Платеж), Invoice (Счет-фактура) и ConfiguredComputer (Сконфигурированный компьютер).
Можно ли связать их в ассоциацию. Если это возможно, модифицируйте соответствующим
образом диаграмму. Объясните ваше решение.
114 Глава 2. Основания анализа требований
У7. Internet-магазин — обратитесь к заданию 11 (разд. 2.2.4.5).
Рис. 2.31 представляет собой относительно простой пример, иллюстрирующий обобще-
ние. Какие сложности.могут возникнуть, если потребуется ввести различия в информацию,
вносимую в счет-фактуру для продажи стандартного компьютера (Standardcomputer) и
продажи сконфигурированного компьютера (ConfiguredComputer)? Например, может
быть предусмотрена дополнительная плата, зависящая от модификации, требуемой для
конфигурируемой системы (ConfiguredComputer), и, напротив, может быть предусмот-
рена скидка за оптовую покупку стандартной системы (standardcomputer).
Модифицируйте диаграмму таким образом, чтобы отразить подобное усложнение. Кратко
поясните свое решение.
У8. Internet-магазин — обратитесь (в качестве примера) к заданию 13 (разд. 2.2.5.1) и зада-
* ' нию 6 (разд. 2.2.3.2).
Изобразите диаграмму последовательностей для вида деятельности Display Purchase
Form (Отобразить закупочную форму) (рис. 2.26).
У9. Internet-магазин — обратитесь к решению упражнения 8, приведенного выше.
Введите дополнительные операции в классы, обозначенные объектами в диаграмме по-
следовательностей.
У10. Internet-магазин — обратитесь к заданию 16 (разд. 2.2.6.1).
Диаграмма состояний, показанная на рис. 2.37, удовлетворяет ограничению, е соответст-
вии с которым допускается только один частичный платеж. Предположим, что это не так, и
разрешается осуществлять большее количество частичных платежей. Модифицируйте со-
ответствующим образом указанную диаграмму.
Установление
требований
В сравнении с другими этапами разработки системы установление требований в наи-
меньшей степени касается технических сторон проекта. В действительности речь идет
об успешном решении социальных, коммуникативных и управленческих вопросов. Не-
достаточно тщательное выполнение этого этапа может привести к более серьезным по-
следствиям, чем в случае с другими этапами. Лавинообразный рост расходов, вызванных
не зафиксированными, упущенными или неверно понятыми требованиями заказчиков,
может впоследствии оказаться просто невыносимым для процесса разработки.
Эта глава охватывает широкий спектр вопросов, касающихся установления требо-
ваний. Первая часть главы посвящена методам выявления, согласования и утвержде-
ния требований, а также принципам управления требованиями. Остаток первой час-
ти касается вопросов прослеживаемости и управления изменениями — темы, которая
более подробно обсуждается в главе 10.
Во второй части главы вводятся базовые графические методы моделирования для
описания бизнес-модели, относящейся к организации и прикладной области. Кроме
того, здесь рассматривается структура документа, описывающего требования.
3.1. Принципы установления требований
Установление требований —первый этап жизненного цикла разработки системы.
Система, подлежащая разработке, определяется с помощью вида деятельности, кото-
рый получил название системного планирования (разд.1.2). Цель установления требова-
ний состоит в том, чтобы дать развернутое определение функциональных — а также
нефункциональных — требований, которые участники проекта ожидают утвердить в
реализуемой и разворачиваемой системе.
Требования определяют услуги, ожидаемые от системы (формулировки сервисов) и
ограничения, которым система должна подчиняться (формулировки ограничений). Эти
формулировки сервисов можно объединить в несколько групп: одна из групп описы-
вает границы системы, вторая — необходимые бизнес-функции (функциональные требо-
вания), а третья — требуемые структуры данных (требования к данным). Формулировки
116 Глава 3. Установление требований
ограничений можно классифицировать в соответствии с различными категориями
ограничений, накладываемых на систему, такие как требуемое “впечатление и ощу-
щение от использования программы”, производительность, безопасность и т.д.
Требования необходимо получить от заказчиков (пользователей и владельцев сис-
темы). Этот вид деятельности, называемый выявлением требований (requirements elicita-
tion), осуществляется аналитиком бизнес-процессов (или системным аналитиком).
Для этого подходят различные методы, начиная с традиционных интервью с заказчи-
ком и заканчивая (при необходимости) построением программного прототипа, с по-
мощью которого раскрываются дополнительные требования.
Собранные требования должны быть подвергнуты тщательному анализу для выяв-
ления в них повторов и противоречий. Это неизменно приводит к пересмотру требова-
ний и их повторному согласованию с заказчиками.
Требования, удовлетворительные с точки зрения заказчика, документируются.
При этом требованиям дают определение, классифицируют, нумеруют и присваивают
им приоритеты. Структура документа, описывающего требования, соответствует шаб
лону (template), выбранному в организации для этой цели.
Хотя документ, фиксирующий требования, носит в значительной мере описатель-
ный характер, вполне возможно включить в него высокоуровневую схематичную биз-
нес-модель. Как правило, бизнес-модель состоит из модели границ системы, модели биз-
нес-прецедентов и модели бизнесклассов.
Требования пользователя подобны движущейся цели. Чтобы справиться с измен-
чивыми требованиями, необходимо уметь управлять изменениями. Управление требо-
ваниями включает такие виды деятельности как оценка влияния изменений одних
требований на другие, а также на неизменяемую часть системы.
3.2. Выявление требований
Бизнес-аналитик выявляет требования к системе посредством консультаций. К
участию в консультациях привлекаются заказчики и эксперты в проблемной области.
В некоторых случаях бизнес-аналитик обладает достаточным опытом в проблемной
области, и помощь эксперта может не потребоваться. В этом случае Бизнес-
аналитик представляет собой разновидность Эксперта проблемной области, что
отражено в модели, показанной на рис. 3.1, с помощью отношения обобщения.
(Следует, однако, иметь ввиду, что рис. 3.1 — это не модель прецедентов: нотация для
прецедентов используется здесь только для удобства.)
Требования, выявленные с помощью эксперта проблемной области, составляют
основу знаний о проблемой области. Они фиксируют широко признанные, не зави-
сящие от времени бизнес-правила, применимые к большинству организаций и систем.
Требования, выявленные в ходе консультаций с заказчиками, выражаются в сценари-
ях прецедентов. Они выходят за рамки базовых знаний о проблемной области и фик-
сируют уникальные черты организации — способ ведения бизнеса “здесь и сейчас” ли-
бо пожелания в отношении того, как следует вести бизнес.
Задача бизнес-аналитика состоит в том, чтобы объединить два набора требований
в бизнес-модели. Как показано на рис. 3.1, Бизнес-модель содержит Модель биз-
нес-классов и Модель бизнес-прецедентов. Модель бизнес-классов пред-
ставляет собой диаграмму классов верхнего уровня, которая идентифицирует и свя-
зывает между собой бизнес-объекты. Модель бизнес-прецедентов — это диаграмма
прецедентов верхнего уровня, которая идентифицирует основные функциональные
строительные блоки системы.
3.2. Выявление требований 117
Рис. 3.1. Взаимные влияния моделей, характерные для процесса определения
требований
В общем случае, классы проблемной области (бизнес-объекты) не должны выво-
диться из прецедентов [75]. Однако, на практике правильность модели бизнес-
классов должна подтверждаться посредством сравнения с Моделью бизнес-
прецедентов. Это сравнение, как правило, приводит к некоторой настройке или
расширению Модели бизнес-классов.
Следуя Хофферу (Hoffer) [37] мы различаем традиционные и современные мето-
ды выявления фактов и сбора информации.
3.2.1. Традиционные методы выявления требований
К традиционным методам выявления требований относятся использование ин-
тервью и анкет, наблюдение и изучение деловых документов. Это простые и эконо-
мичные методы.
Эффективность традиционных методов обратно пропорциональна риску проекта. Вы-
сокий риск означает, что систему трудно реализовать — не вполне ясны даже обобщенные
требования. Для таких проектов традиционных методов вряд ли будет достаточно.
3.2.1.1. Интервьюирование заказчиков и экспертов в
проблемной области
Использование интервью представляет собой основной метод выявления фактов
и сбора информации. Большинство интервью проводятся с заказчиками. Интервью с
заказчиками позволяют выявить по большей части “прецедентные” требования, т.е.
требования вытекающие из “прецедентов” (рис. 3.1). Если бизнес-аналитик не облада-
118 Глава 3. Установление требований
ет достаточным опытом в проблемной области, можно также проинтервьюировать
соответствующих экспертов.
Интервью с экспертами в прикладной области зачастую представляет собой про-
сто процесс передачи знаний — занятие по обучению бизнес-аналитика. Интервью с
заказчиками отличает большая сложность [46], [81].
Заказчики могут иметь весьма смутное представление о своих требованиях. Они
могут не желать сотрудничать или не умеют выражать свои требования в понятной
форме. Они также могут запрашивать реализацию требований, которые превосходят
бюджет проекта или нереализуемы. И наконец, весьма вероятно, что требования, ис-
ходящие от различных групп пользователей, могут оказаться противоречивыми.
Существуют два основных типа интервью: структурированное (формальное) и не-
структурированное (неформальное). Структурированное интервью готовится заранее, от-
личается ясностью постановки вопросов, а многие вопросы могут быть заданы заранее.
Заранее сформулированные вопросы можно разделить на две категории: вопросы с от-
крытым множеством ответов (open-ended question) (ответы на эту категорию вопросов зара-
нее не готовятся) и вопросы с замкнутым множеством ответов (closed-ended question) (ответы
на эту категорию вопросов можно выбрать из списка подготовленных ответов).
Структурированному интервью должно сопутствовать неструктурированное интер-
вью. Неструктурированное интервью больше напоминает неформальную встречу, ко-
торой не свойственны заготовленные впрок вопросы или заранее поставленные це-
ли. Цель неструктурированного интервью — подвигнуть заказчика к тому, чтобы он
поделился своими мыслями и в процессе беседы подошел к требованиям, которых
бизнес-аналитик мог и не ожидать и, следовательно, не мог задать нужные вопросы.
Как структурированное, так и неструктурированное интервью нуждаются в некото-
рой отправной точке и контексте для обсуждения. Это может быть небольшой документ
или записка, отправленная по электронной почте интервьюируемому перед встречей,
цель которых — объяснить цели интервьюера или поставить некоторые вопросы.
Существуют три категории вопросов, которых, в общем случае, необходимо избе-
гать [91].
Небеспристрастные вопросы, в которых интервьюер выражает (прямо или косвенно)
свое мнение по вопросу (“Должны ли мы работать так, как мы работаем?”).
Предвзятые вопросы, аналогичные небеспристрастным, но отличаются от
последних тем, что мнение интервьюера является, очевидно, тенденциозным (“Вы
ведь не станете этого делать, не так ли?”).
Наводящие вопросы, которые предполагают ответ в самом вопросе (“Вы ведь
сделаете именно так, не правда ли?”).
Успех интервью зависит от многих факторов, но едва ли не главными среди них
являются навыки интервьюера в области коммуникации и межличностного общения. Хотя
основная задача интервьюера — задавать вопросы и владеть ситуацией, не менее важ-
но в ходе беседы внимательно слушать и проявлять терпение к интервьюируемому
так, чтобы он чувствовал себя непринужденно. Для сохранения хороших личных от-
ношений и в расчете на положительный отклик со стороны интервьюируемого необ-
ходимо отправить ему в течение одного-двух дней после интервью записку, содержа-
щую краткие итоги интервью.
3.2. Выявление требований 119
3.2.1.2. Анкетирование
Использование анкет или анкетирование (questionnaires) — эффективный способ
сбора информации от многих заказчиков. Обычно анкеты используются в дополне-
ние к интервью, а не вместо них. Исключение могут составлять проекты с низким
риском, цели которых ясно очерчены. Для таких проектов обычно достаточно ис-
пользовать анкеты с вопросами, которые носят пассивный характер и не отличаются
большой глубиной.
В общем случае, анкетирование менее продуктивно, чем использование интервью,
поскольку в вопросы или возможные ответы нельзя внести дополнительную ясность.
Анкетирование пассивно — это можно расценивать и как достоинство, и как недоста-
ток. Это достоинство, поскольку у респондента есть время подумать над ответом, а
анкета может остаться анонимной. Это недостаток, поскольку респонденту нелегко
прояснить для себя вопросы.
Анкета (или вопросник) должна быть разработана таким образом, чтобы, по возмож-
ности, облегчить ответы на вопросы. В частности, следует избегать вопросов с неопреде-
ленным множеством ответов— большинство вопросов должны относиться к вопросам с
замкнутым, списком ответов. Подобные вопросы могут принимать три формы [91].
Многоалътернативные вопросы (multiple-choice questions). При ответе на эти вопросы
респондент должен указать один или более ответов, выбрав их из прилагаемого
списка. Кроме того, иногда допускаются дополнительные комментарии к вопросам
со стороны респондентов.
Рейтинговые вопросы (rating questions). При ответе на этот тип вопросов респондент
должен выразить свое мнение в отношении высказанного утверждения. Для этого
могут использоваться такие рейтинговые значения, как “абсолютно согласен”,
“согласен”, “отношусь нейтрально”, “не согласен”, “абсолютно не согласен” и “не знаю".
Вопросы с ранжированием (ranking questions). Этот тип вопросов предусматривает
ранжирование ответов с помощью присваивания им последовательных номеров,
процентных значений и использования других средств упорядочения.
Тщательно продуманная, облегчающая ответы анкета поощряет респондента к то-
му, чтобы сразу вернуть заполненный документ. Однако, при оценке результатов ан-
кетирования бизнес-аналитик должен предусмотреть возможность искажения ин-
формации из-за того, что те люди, которые не отвечали на вопросы, могли бы отве-
тить на них иначе, чет принимавшие участие в опросе [87].
3.2.1.3. Наблюдение
В некоторых ситуациях бизнес-аналитик находит трудным получить полную ин-
формацию с использованием интервью и анкет. У заказчика по тем или иным причи-
нам может отсутствовать возможность (или умение) предоставить необходимую ин-
формацию, либо он может не иметь полного представления о бизнес-процессе в це-
лом. В подобных случаях в качестве эффективного метода выявления фактов может
выступать наблюдение (observation). Как-никак, лучший способ научиться завязывать гал-
стук — понаблюдать за процессом.
Наблюдение может выступать в двух формах.
Пассивное наблюдение (passive observation}, в ходе которого бизнес-аналитик
наблюдает за различными видами деловой деятельности без вмешательства или
120 Глава 3. Установление требований
прямого участия в них. В некоторых случаях для того, чтобы наблюдение было как
можно менее навязчивым, можно даже использовать видеокамеры.
Активное наблюдение (active observation), в ходе которого бизнес-аналитик участвует в
деятельности и становится фактически частью команды.
Чтобы результаты наблюдений были представительными, наблюдения необходи-
мо проводить в течение продолжительного периода времени, в разные временные
интервалы и при разной рабочей нагрузке (выборочные периоды). Основная труд-
ность, связанная с наблюдением, состоит в том, что люди, за которыми наблюдают,
склонны вести себя иначе, чем в обычной обстановке. В частности, они стремятся ра-
ботать в соответствии с формальными правилами и процедурами. Это приводит к ис-
кажению реального положения дел за счет утаивания “рациональных” приемов рабо-
ты — как положительных, так и отрицательных. Следует помнить, что “работа по пра-
вилам” — это одна из эффективных форм забастовочного движения.
3.2.1.4. Изучение документов и программных систем
Изучение документов и программных систем является неоценимым методом выявле-
ния как требований типа прецедентов, так и требований, связанных со знанием про-
блемной области (см. разд. 3.2). Этот метод используется всегда, хотя он может ка-
саться только отдельных сторон системы.
Требования, формулируемые в виде прецедентов, или прецедентные требования (use case
requirements) выявляются посредством изучения существующих организационных до-
кументов и системных форм и отчетов (если, конечно, для текущей системы сущест-
вует автоматизированное решение, что типично для больших организаций). Одним
из наиболее полезных способов постижения сути требований на основе прецедентов
является фиксация дефектов (естественно, при их наличии) и формирование запро-
сов на изменение для существующей системы.
К организационным документам, подлежащим изучению, относятся: формы деловых
документов (по возможности — заполненные), описания рабочих процедур, должно-
стные обязанности, методические руководства, бизнес-планы, схемы организацион-
ных структур, внутриофисная корреспонденция, протоколы совещаний, учетные за-
писи, внешняя корреспонденция, жалобы клиентов и т.д.
Системные формы и отчеты, подлежащие изучению, включают: копии экранов, от-
четы вместе с соответствующей документацией — системные руководства по эксплуа-
тации, пользовательская документация, техническая документация, системные моде-
ли анализа и проектирования и т.д.
Требования, основанные на знании проблемной области, выясняются посредством изу-
чения журналов и учебников, которые относятся к данной сфере. Изучение патенто-
ванных программных пакетов наподобие ERP-систем (Enterprise Resource Planning
Systems — системы планирования ресурсов предприятия) также может стать богатым
источником знаний о проблемной области. Следовательно, посещения библиотек и
поставщиков ПО являются частью процесса выявления требований (конечно, Inter-
net позволяет осуществить многие такие “визиты”, не покидая офиса).
3.2.2. Современные методы выявления требований
К современным методам выявления требований относится использование про-
граммных прототипов, а также такие методы, как JAD (Joint Application Develop-
ment — совместная разработка приложений) и RAD (Rapid Application Development —
3.2. Выявление требований 121
быстрая разработка приложений). Эти подходы предлагают более глубокое проник-
новение в суть требований, но за счет большей цены и усилий. Однако, долговремен-
ные вложения в эти методы могут окупиться с лихвой.
Применение современных методов обычно связано с высоким проектным риском.
Существует множество факторов, обусловливающих высокий риск проекта. К таким
факторам относятся неясные цели, недокументированные процедуры, нестабильные
требования, слабое знание дела пользователями, неопытные разработчики, недоста-
точная приверженность пользователей разработке и т.д.
3.2.2.1. Прототипирование
Прототипирование (prototyping)— это наиболее часто используемый современный
метод выявления требований. Программные прототипы конструируются для визуали-
зации системы или ее части для заказчиков с целью получения их отзывов.
Прототип представляет собой демонстрационную систему— “наскоро и грубо”
сделанную рабочую модель решения, которая представляет пользовательский GUI-
интерфейс и моделирует поведение системы при инициировании пользователем раз-
личных событий. Информационное наполнение экранов чаще жестко запрограмми-
ровано в программе прототипа, чем получается автоматически из базы данных.
Сложность (и растущие “аппетиты” заказчиков) современных GUI-интерфейсов
делают прототипирование обязательным элементом разработки ПО. Прототипы по-
зволяют довольно неплохо оценить реализуемость и полезность системы до начала ее
реализации.
В общем случае, прототип — это весьма эффективный способ выявления требова-
ний, которые трудно получить от заказчика с помощью других средств. Чаще всего
такая ситуация встречается для систем, которые должны предоставить в распоряже-
ние пользователей новые бизнес-функции. Подобная ситуация также характерна для
случаев противоречивых требований и наличия проблем в кооперации между заказ-
чиками и разработчиками.
Существуют две основные разновидности прототипов [46].
“Одноразовый”прототип (“throw-away"prototype), который после того, как выявление
требований завершено, просто отбрасывается. Разработка “одноразового”
прототипа нацелена только на этап установления требований ЖЦ ПО. Как
правило, этот прототип концентрируется на наименее понятных требованиях.
Эволюционный прототип (evolutionary prototype), который сохраняется после
выявления требований и используется для создания конечного программного
продукта. Эволюционный прототип нацелен на ускорение поставки продукта. Как
правило, он концентрируется на ясно изложенных требованиях, так что первую
версию продукта можно предоставить заказчику довольно быстро (хотя ее
функциональные возможности, как правило, неполны).
Дополнительным доводом в пользу использования именно “одноразового” прототи-
па может служить стремление избежать риска “консервации” скорых и грубых и, как
следствие, неэффективных решений в конечном продукте. Однако мощь и гибкость со-
временных средств создания ПО ослабляют этот довод. Если управление проектом осу-
ществляется надлежащим образом, то причины, по которой нельзя было бы избавиться
от неэффективных предложенных для прототипа решений, не существует.
122 Глава 3. Установление требований
3.2.2.2. Совместная разработка приложений (JAD-метод)
JAD-метод полностью сответствует своему названию— это совместная разработка
приложений (Joint Application Development), осуществляемая в ходе одного или нескольких
совещаний с привлечением всех участников проекта (заказчиков и разработчиков)
[95]. Хотя мы относим JAD-подход к современным методам выявления требований,
этот метод был впервые введен в конце 1970-х годов компанией IBM.
Существует много разновидностей JAD-метода и много фирм, предлагающих услу-
ги по организации и проведению JAD-совещаний. Проведение JAD-совещаний может
занимать несколько часов, несколько дней или даже пару недель. Количество участ-
ников не должно превышать 25-30 человек. В совещании принимает участие следую-
щий круг лиц [37], [91].
Ведущий— человек, который проводит и модерирует встречу (поэтому иногда его
называют модератором). Этот человек должен обладать исключительными
способностями в области коммуникации, не должен относиться к числу участников
проекта (помимо того, что он является лидером JAD-сессии), обладает
основательным знанием проблемной области (однако не обязательно хорошо
владеет проблемами разработки ПО).
Секретарь— человек, который фиксирует ход JAD-сессии с использованием
компьютера. Этот человек должен уметь быстро вводить текст в компьютер и
хорошо владеть вопросами разработки ПО. Для документальной фиксации хода
сессии и разработки первоначальных моделей решений секретарь может
использовать CASE-средства.
Заказчики (пользователи или руководители) — это основные участники, которые
излагают и обсуждают требования, принимают решения, утверждают проектные
цели и т.д.
Разработчики— бизнес-аналитики и другие члены проектной бригады. Эти
участники больше слушают, чем говорят— они присутствуют на совещании для
того, чтобы уяснить фактическую сторону дела и собрать информацию, а не
занимать всецело внимание других участников в процессе совещания.
JAD-метод зиждется на групповой динамике. Групповые усилия более перспектив-
ны с точки зрения получения лучших решений проблем. Группы способствуют повы-
шению продуктивности, быстрее обучаются, склонны к более квалифицированным
заключениям, позволяют исключить многие ошибки, принимают рискованные реше-
ния (иногда это может носить негативный характер!), концентрируют внимание уча-
стников на наиболее важных вопросах, объединяют людей и т.д.
Если JAD-сессия проводится в соответствии с правилами, можно добиться удиви-
тельно хороших результатов. Однако, не следует забывать о предупреждении: "...
компания Ford Motor в 1950-х годах потерпела неудачу, пытаясь вывести на рынок
модель Edsel — автомобиль, разработанный комитетом” [95].
3.2.2.3. Быстрая разработка приложений (RAD-метод)
Метод быстрой разработки приложений (Rapid Application Development — RAD) — это не-
что большее, чем метод выявления требований — это целостный подход к разработке
ПО [37]. Как ясно из названия метода, он предполагает быструю поставку системных
решений. Техническое превосходство отступает на второе место в сравнении со ско-
ростью поставки.
3.3. Согласование и проверка обоснованности требований 123
Согласно Вуду (Wood) и Сильверу (Silver) [95] технология RAD сочетает в себе
пять методов, перечисленных ниже.
Эволюционное прототипирование (разд. 3.2.2.1).
CASE-средства с возможностями генерации программ и циклической разработкой с
переходом от проектных моделей к программе и обратно.
Специалисты, владеющие развитыми инструментальными средствами (Specialists with Ad-
vanced Tools — SWAT) — RAD-бригада разработчиков. Лучшие аналитики,
проектировщики и программисты, которых только может привлечь организация.
Бригада работает в рамках строгого временного режима и размещается вместе с
пользователями.
ИнтерактивныйJAD-Memod—JAD-сессия (разд. 3.2.2.2), во время которой секретарь
заменяется бригадой SWAT, оснащенной CASE-средствами.
Жесткие временные рамки (timeboxing)— метод управления проектом, который
отводит бригаде SWAT фиксированный период времени (timebox) для завершения
проекта. Этот метод препятствует “расползанию рамок проекта”; если проект
затягивается, то рамки решения сужаются, чтобы дать возможность завершить
проект своевременно.
Использование RAD-подхода может оказаться привлекательным вариантом для
многих проектов, в особенности, для небольших проектов, которые не затрагивают
сферу ключевых бизнес-процессов организации, и которые, таким образом, не задают
план решения для других проектов по разработке ПО. Маловероятно, чтобы быстрые
решения были оптимальными или долговременными для ключевых сфер деятельно-
сти организации. С использованием RAD-метода связан ряд проблем; некоторые из
них перечислены ниже.
1. Несовместимый проект GUI-интерфейса.
2. Вместо общих решений, способствующих многократному использованию ПО,
специализированные решения.
3. Неполная документация.
4. Трудное для поддержки и масштабирования ПО и т.д.
3.3. Согласование и проверка
обоснованности требований
Требования, полученные от пользователей, могут дублироваться или противоре-
чить друг другу. Некоторые требования могут быть неясными или нереальными Дру-
гие требования могут остаться невыясненными. По этой причине прежде, чем требо-
вания попадут в документ описания требований, их необходимо согласовать.
В действительности согласование и проверка обоснованности требований осуществляет-
ся параллельно с выявлением требований. После того как требования выявлены, они
подвергаются определенному уровню проверки. Для всех современных методов вы-
явления требований, которые связаны с так называемой “групповой динамикой”, это
вполне естественно. Как бы там ни было, после того как выявленные требования соб-
124 Глава 3. Установление требований
раны вместе, они в любом случае должны быть подвергнуты тщательному обсуждению
и проверке.
Согласование и проверка требований не могут быть отделены от процесса подго-
товки документа описания требований. Обычно согласование требований основано на
черновом варианте документа. Требования, перечисленные в черновом варианте до-
кумента, обсуждаются и при необходимости модифицируются. Побочные требования
удаляются. Вновь выявленные требования добавляются.
Для проверки обоснованности требований (requirements validation) необходима более
полная версия документа, в котором все требования четко идентифицированы и
классифицированы. Участники проекта изучают документ и проводят совещания по
их формальному пересмотру. Пересмотры (reviews) часто структурированы в виде так
называемых процедур сквозного контроля (walkthroughs) или инспекций (inspections). Пере-
смотры являются разновидностью тестирования (testing) (разд. 10.1.1).
3.3.1. Требования, выходящие за рамки проекта
Выбор проекта в сфере ИТ и, следовательно, подлежащей реализации системы (и
их четких границ) определяется в рамках вида деятельности, получившего название
системного планирования (разд. 1.2). Однако, детализированные взаимозависимости
между системами могут быть раскрыты только на этапе анализа требований. Установ-
ление границ системы (системных рамок) — задача этапа анализа требований, так что
проблема “растягивания рамок” может решаться на ранних этапах процесса разра-
ботки как составная часть этой задачи.
Чтобы иметь возможность решить, лежит ли конкретное требование в рамках сис-
темы или выходит за рамки, необходима эталонная модель, по отношению к которой
и должно приниматься решение. Исторически роль подобной эталонной модели сыг-
рала контекстная диаграмма (context diagram) — высокоуровневая диаграмма популярно-
го метода структурного моделирования под названием диаграмма потоков данных
(Data Flow Diagrams — DFD). Хотя в языке UML место этой диаграммы заняла диа-
грамма прецедентов, контекстная диаграмма по-прежнему остается превосходным
методом установления границ системы (разд. 3.5.1).
Существуют, впрочем, и другие причины, по которым требование может быть
расценено, как выходящее за рамки проекта [81]. Например, требование может
представлять большую трудность для реализации в компьютеризованной системе и
остается прерогативой человека, участвующего в процессе. Либо требование может
иметь низкий приоритет и исключается из первой версии системы. Требование
может быть также реализовано с помощью аппаратного обеспечения или внешних
устройств и, таким образом, может оказаться вне контроля со стороны программ-
ного обеспечения.
3.3.2. Матрица зависимости требований
Полагая, что все требования четко идентифицированы и пронумерованы (разд.
3.4.1), можно сконструировать матрицу зависимостей требований (requirements dependency
matrix) (или матрицу взаимодействия (interaction matrix требований)) [81], [46]. В столбце
и строке заголовка перечислены упорядоченные идентификаторы требований, как
показано на рис. 3.2.
3.3. Согласование и проверка обоснованности требований 125
Требование Т1 Т2 ТЗ Т4
Т1 X X X X
Т2 Конфликт X X X
ТЗ X X
Т4 Перекрытие Перекрытие X
Рис. 3.2. Матрица зависимости требований
Верхняя правая часть матрицы (над диагональю включительно) не используется.
Оставшиеся ячейки указывают на то, перекрываются ли два любых требования, про-
тиворечат друг другу или независимы друг от друга (пустые ячейки). Противоречивые
требования необходимо обсудить с заказчиками и при возможности переформулиро-
вать для смягчения противоречий (фиксацию противоречия, видимую для последую-
щей разработки, необходимо сохранить). Перекрывающиеся требования также должны
быть сформулированы заново, чтобы исключить совпадения.
Матрица зависимости требований представляет собой простой, но эффективный
метод обнаружения противоречий перекрытий, когда количество требований отно-
сительно невелико. В противном случае описанный метод все же можно применить,
если удается сгруппировать требования по категориям (разд. 3.4.1), а затем сравнить
их отдельно в пределах каждой категории.
3.3.3. Риски и приоритеты требований
После того, как в результате снятия противоречий и устранения повторов в тре-
бованиях выработан пересмотренный набор требований, их необходимо подвергнуть
анализу рисков и назначить им приоритеты. Анализ рисков (risk analysis) направлен на
идентификацию требований, которые являются потенциальными источниками труд-
ностей в разработке. Назначение приоритетов {prioritization) необходимо для того, что-
бы обеспечить возможность без труда изменить рамки проекта в случае возникнове-
ния непредвиденных задержек.
Требования могут быть “рискованными” вследствие влияния различных факторов.
Требованиям свойственны следующие типичные виды рисков [81].
Технический риск, когда требование технически трудно реализовать.
Риск, связанный со снижением производительности, когда требование — будучи
реализовано — может неблагоприятно сказаться на времени реакции системы.
Риск, связанный с нарушением безопасности, когда требование — будучи реализовано —
может создать бреши в защите системы.
Риск, связанный с процессом разработки, когда для реализации требования
необходимо использование необычных методов разработки, незнакомых
разработчикам (например, методов формальной спецификации).
Риск, связанный с нарушением целостности баз данных, когда требование не может
быть легко проверено и может привести к противоречивости данных.
Политический риск, когда требование может оказаться трудным выполнить по
внутриполитическим причинам.
Риск, связанный с нарушением законности, когда требование может привести к
нарушению действующих законов или ожидаемого изменения закона.
126 Глава 3. Установление требований
Риск, связанный с изменчивостью, когда требование может потенциально изменяться
или эволюционировать в течение процесса разработки.
В идеале приоритеты требованиям назначают отдельные заказчики в процессе вы-
явления требований. Затем они согласовываются на совещаниях и снова изменяются
после приложения к ним факторов риска.
Для исключения неопределенности и облегчения назначения приоритетов коли-
чество групп приоритетов не должно быть слишком велико. Обычно используется от
трех до пяти приоритетов. Их можно обозначить как “высокий”, “средний”, “низкий”
и “неопределенный”. Альтернативный перечень приоритетов может выглядеть, на-
пример, так: “существенное”, “полезное”, “трудно определимое” и “отложенное”.
3.4. Управление требованиями
Требованиями необходимо управлять. Управление требованиями в действитель-
ности представляет собой часть общего управления проектом. Оно связано с тремя
основными вопросами.
1. Идентификация, классификация, организация и документирование требований.
2. Изменение требований (с помощью процессов, которые устанавливают спосо-
бы выдвижения, согласования, проверки достоверности и документирования
неизбежных изменений к требованиям).
3. Прослеживаемость требований (с помощью процессов, которые поддерживают
отношения взаимозависимости между требованиями и другими системными ар-
тефактами, а также, собственно, между требованиями) (обратитесь к главе 10).
3.4.1. Идентификация и классификация требований
Требования описываются на естественном языке, например, следующим образом.
“Система должна запланировать следующий телефонный звонок клиенту по
запросу телемаркетера”.
“Система должна автоматически набирать запланированный телефонный номер и
одновременно отображать на экране телемаркетера информацию, включающую
телефонный номер, номер клиента, имя клиента”.
“В случае успешного соединения система должна отобразить вводный текст, с которым
телемаркетер может обратиться к клиенту для того, чтобы завязать разговор”.
Типичная система может состоять из сотен или тысяч формулировок требований,
наподобие тех, что приведены выше. Для надлежащего управления таким огромным
количеством требований их необходимо пронумеровать с помощью некоторой схемы
идентификации (identification scheme) Схема может включать классификацию требований
в виде групп, которые легче поддаются управлению.
Существует несколько методов идентификации и классификации требований [46].
Уникальный идентификатор— обычно последовательный номер, присвоенный
вручную или сгенерированный с использованием базы данных CASE-средства (т.е.
базы данных (или репозитория), в которой CASE-средства хранят артефакты,
выработанные в результате анализа или проектирования).
3,4. Управление требованиями 127
Последовательный номер внутри иерархии документа— присваивается с учетом положения
требований в пределах документа описания требований (например, седьмое
требование в третьем разделе второй главы может быть пронумеровано как 2.3.7).
Последовательный номер в пределах категории требований— присваивается в дополнение
к мнемоническому имени, которое обозначает категорию требований (где под
категорией требований подразумевают функциональное требование, требование К
данным, требования к производительности, требования к безопасности и т.д.)
Каждый из методов идентификации обладает своими за и против. Наибольшей
гибкостью и защищенностью от ошибок отличаются уникальные идентификаторы, ге-
нерируемые с помощью базы данных. Базы данных обладают встроенными возможностя-
ми генерации уникальных идентификаторов для каждой новой записи данных в усло-
виях одновременного доступа к данным со стороны многих пользователей. <
Некоторые базы способны дополнительно поддерживать сопровождение ‘ не-
скольких версий одной и той же записи (за счет расширения значения уникального
идентификатора с помощью номера версии). Наконец, базы данных могут обладать
возможностями поддержки ссылочной целостности связей между артефактами моде-
лирования, включая требования, и могут, таким образом, обеспечить необходимую
поддержку управления и прослеживаемости требований.
3.4.2. Иерархии требований
Требования можно упорядочить в виде иерархически упорядоченной структуры,
представляющей отношение родитель-потомок. Отношение родитель-потомок подобно
отношению композиции (разд. 2.1.4). Родительское требование составлено из дочерних
требований. Дочернее требование — это фактически “под-требование” родительского
требования.
Иерархические отношения позволяют ввести дополнительный уровень классифика-
ции требований. Это может непосредственно отражаться (или не отражаться) в иден-
тификационном номере (с помощью использования точки в записи составного име-
ни). Поэтому требование, пронумерованное как 4.9, может быть девятым “потомком”
“родителя” с идентификационным номером, равным 4.
Приведенный ниже набор формулировок представляет собой иерархически упо-
рядоченные требования.
1. “Система должна запланировать следующий телефонный звонок клиенту по за-
просу телемаркетера”.
1.1. “Система должна активизировать клавишу Next Call (Следующий звонок)
при открытии формы Telemarketing Control (Управление телемарке-
тингом) или при завершении предыдущего вызова”.
1.2. “Система должна удалить звонок из начала очереди запланированных
звонков и придать ему статус текущего звонка”.
1.3. Другие требования...
Иерархии требований позволяют определять требования на различных уровнях аб-
стракции. Это согласуется с общим принципом моделирования, в соответствии с ко-
торым при переходе к более низкому уровню абстракции модели систематически обо-
гащаются все новыми деталями. В результате для родительских требований можно
сконструировать обобщенные требования, а детализированные модели можно свя-
зать с дочерними требованиями.
128 Глава 3. Установление требований
3.4.3. Управление изменениями
Требования изменяются. Требования могут изменяться, они могут быть удалены, а но-
вые требования могут быть добавлены на любом этапе разработки. Изменения нельзя рас-
сматривать как “удар”, а вот неуправляемые изменения — это настоящий удар по проекту.
Чем дальше продвинулась разработка, тем дороже обходится внесение изменений.
Фактически, минимальные затраты, необходимые для выправления проекта после
внесения изменений, всегда растут и зачастую растут экспоненциально. Изменение
только что сформулированных требований, которые не связаны с другими требова-
ниями, — это простое упражнение в редактировании. Изменение тех же требований,
после того как они реализованы, может обойтись чрезвычайно дорого.
Изменения могут быть связаны с субъективными ошибками, но зачастую они вы-
званы изменениями внутренней политики или внешними факторами, такими как
конкурентные силы, глобальные рынки или технологические достижения. Вне зави-
симости от причин, для документирования запросов на изменения {change request) оценки
влияния, оказываемого изменениями {change impact), и осуществления изменений необхо-
дима сильная стратегия управления изменениями.
Поскольку изменение требований обходится дорого, для каждого запроса на изме-
нение необходимо создавать формальный бизнес-прецедент. Обоснованное изменение,
которое не встречалось раньше, оценивается с точки зрения его технической осущест-
вимости, влияния на остальной проект и затрат. После согласования требование вклю-
чается в соответствующие модели и реализуется в программном обеспечении.
Управление изменениями, помимо прочего, включает отслеживание больших объе-
мов взаимосвязанной информации в течение длительного периода времени. Без инст-
рументов поддержки управление изменениями обречено. В идеале, изменения требова-
ний должны храниться и отслеживаться с помощью средств конфигурационного управления
ПО, которое используется разработчиками для контроля версий моделей и программ на
протяжении ЖЦ разработки. Подходящие CASE-средства должны либо обладать собст-
венными возможностями конфигурационного управления, либо возможностями взаи-
модействия с автономными средствами конфигурационного управления.
3.4.4. Прослеживаемость требований
Прослеживаемость требований {requirements traceability) — это всего лишь часть, хотя и
крайне важная часть, управления изменениями {change management). Блок прослеживае-
мости требований технологии управления изменениями поддерживает отношения
прослеживаемости, чтобы фиксировать изменения, исходящие от или вносимые в тре-
бования на протяжении ЖЦ разработки.
Рассмотрим требование: “Система должна запланировать следующий телефонный
звонок клиенту по запросу телемаркетера”. Это требование можно впоследствии смо-
делировать с помощью диаграммы последовательностей, которая активизируется из
GUI-интерфейса с помощью кнопки запуска действия, помеченной как Next Call, и
триггера, запрограммированного в базе данных. Если между всеми этими элементами
существует отношение прослеживаемости, изменение любого элемента вновь откры-
вает отношение для обсуждения — траектория системы “подпадает под подозрение”
(говоря языком одного из инструментальных средств).
Отношение прослеживаемости может охватывать многие модели последователь-
ных этапов ЖЦ. Непосредственной модификации подлежат только смежные связи по
прослеживаемости. Например, если элемент А восходит к элементу В, а элемент В
3.5. Бизнес-модель требований 129
восходит к элементу С, изменение, внесенное в любой из конечных точек отношения,
должно осуществляться в два этапа: сначала посредством модификации связи A-В, а
затем В-С. (Более подробно прослеживаемость и управление требованиями рассмат-
риваются в главе 10).
3.5. Бизнес-модель требований
На этапе установления требований осуществляется выявление требований и их оп-
ределение, преимущественно, в виде формулировок на естественном языке. Фор-
мальное моделирование требований с использованием языка UML проводится позже
на этапе спецификации требований. Тем не менее, во время установления требований
постоянно ведется деятельность по обобщенному визуальному представлению соб-
ранных требований, называемая бизнес-моделированием требований.
Для установления рамок системы требуется, по меньшей мере, высокоуровневая ви-
зуальная модель, позволяющая обозначить ключевые прецеденты и ввести наиболее
существенные бизнес-классы. На рис. 3.3 показаны зависимости между этими тремя мо-
делями этапа установления требований и модели остальных этапов ЖЦ разработки.
Ведущая роль диаграмм прецедентов в ЖЦ разработки нашла свое отражение на
рис. 3.3, из которого ясно, что источником тестовых прецедентов, пользовательской
документации и проектных планов выступают модели прецедентов. Более того, диа-
граммы прецедентов и модели классов используются параллельно и поочередно иг-
рают роль “лидера гонки” в рамках последовательных итераций разработки. Проек-
тирование и реализация также тесно переплетены и могут инициировать обратную
связь с моделями спецификации требований.
Рис. 3.3. Использование бизнес-моделей на различных этапах выработки требований
130 Глава 3. Установление требований
3.5.1. Модель рамок системы
Вследствие того, что требования подвержены постоянным изменениям, наверное,
наибольшее беспокойство при разработке доставляет так называемое “расползание ра-
мок" системы. Хотя некоторые изменения требований неизбежны, необходимо стро-
го следить за тем, чтобы заявленные изменения не выходили за пределы принятых
рамок проекта.
На самом деле, попытка ответить на вопрос: “Каким образом мы определяем рам-
ки системы?” показывает, что ответ не лежит на поверхности. Это связано, в первую
очередь, с тем, что любая система является всего лишь частью большей по своим
масштабам среды — частью совокупности систем, которые вместе образуют эту среду.
Системы взаимодействуют, обмениваясь информацией и обращаясь к услугам друг
друга. Следовательно, поставленный выше вопрос можно переформулировать сле-
дующим образом: “Должны ли мы реализовать требования или же выполнение тре-
буемых функций возлагается на другую систему?”.
Чтобы ответить на вопрос о рамках системы, необходимо знать, в каком контексте
функционирует наша система. Необходимо знать, какие внешние сущности (external enti-
ties) — другие системы, организации, люди, машины и т.д.— рассчитывают на получение
услуг от нас или готовы предоставить услуги нам. В бизнес-системах подобные услуги
приобретают форму информации и представляются потоками данных (data flow).
Поэтому рамки системы можно определить, обозначив внешние сущности и вход-
ные/выходные потоки данных между внешними сущностями и нашей системой. Наша
система получает входную информацию и выполняет ее необходимую обработку с целью
выработки выходной информации. Всякое требование, которое не может быть поддер-
жано за счет внутрисистемных возможностей обработки, выходит за рамки системы.
Язык UML не обладает средствами построения визуальной модели, позволяющей
определить границы системы. Поэтому зачастую для решения этой задачи прибегают
к помощи давно известных контекстных диаграмм потоков данных— DFD— (разд.
3.3.1). На рис. 3.4 показана контекстная диаграмма для приложения Телемаркетинг.
3.5.1.1. Пример моделирования рамок системы
Рассмотрите постановку задачи для приложения Телемаркетинг (раздел 2.3.4) и постройте '
для нее контекстную диаграмму. Кроме того, примите к сведению следующие замечания.
1. Камлании планируются на основе рекомендации доверенных лиц общества, которые
решают, насколько являются своевременными и подобающими те или иные благотво- !
рительные мероприятия. Кампании должны быть согласованы с местными органами
исполнительной власти. Разработка проекта и планирование кампании поддерживает-
ся отдельной прикладной системой campaign Database (База данных кампаний).
2. Существует также отдельная база данных Supporter Database (База данных благо- >
теорителей), предназначенная для хранения и ведения информации обо всех благо-
творителях — прошлых и настоящих. Эта база данных используется для отбора бла- ;
готворителей, с которыми необходимо установить контакт в ходе конкретной кампа- '
нии. Отобранный сегмент благотворителей передается для работы с ним во время
кампании с использованием телемаркетинга.
3. Заявки от благотворителей на лотерейные билеты регистрируются во время сеансов те-
лемаркетинга для их анвлиза системой обработки заказов (Order Processing). Система
обработки заказов отслеживает состояние заявок в базе данных благотворителей.
3.5. Бизнес-модель требований 131
Рис. 3.4. Модель рамок системы — контекстная диаграмма (Телемаркетинг)
Контекстная диаграмма, к которой вы, возможно, также пришли в результате ра-
боты над данным упражнением, показана на рис. 3.4. “Шарик” в центре диаграммы
представляет нашу систему. Прямоугольники вокруг него обозначают внешние сущ-
ности. Стрелки изображают потоки данных. Подробное содержание информации,
передаваемой потоками данных, на рисунке не показано — содержимое потоков дан-
ных определяется отдельно и хранится в репозитории CASE-системы.
Система Telemarketing получает информацию о текущей кампании от внешней
сущности Campaign Database. Эта информация включает количество и цены биле-
тов, перечень призов для победителей лотереи, продолжительность кампании и т.д.
Аналогично, приложение сущность Telemarketing получает подробную инфор-
мацию о благотворителях от сущности Supporter Database. Во время телемарке-
тингового звонка может появиться новая информация о благотворителе (например, о
том, что благотворитель собирается сменить свой телефонный номер). База
Supporter Database должна быть соответствующим образом актуализирована — по-
этому поток данных Supporter Details (Детальная информация о благотворите-
лях) двунаправленный.
Основная деятельность разворачивается между приложениями-сущностями
Telemarketing и Supporter (Благотворитель). Поток данных Conversation
(Разговор) содержит информацию, которой обмениваются собеседники во время те-
лефонного разговора. Ответ благотворителя на предложение телемаркетера приоб-
рести лотерейные билеты передается с потоком данных Outcome (Результат). Для ре-
гистрации деталей, касающихся билетов, заказанных благотворителем, используется
отдельный поток данных Ticket Placement (Размещение билетов).
Дальнейшая обработка заказов на билеты выходит за рамки нашей системы. Поток
данных Ticket Order (Заказ билетов) перенаправляется внешней сущности Order
Processing (Обработка заказов). Можно предположить, что после ввода заказов,
другие сущности могут обработать платежи от благотворителей, отправку билетов по
почте, розыгрыш призов и т.д. Это нас не интересует, поскольку текущее состояние
заказов, платежей и т.д. доступны нам через внешние сущности Campaign Database
и Supporter Database.
132 Глава 3. Установление требований
3.5.2. Модель бизнес-прецедентов
Модель бизнес-прецедентов (business case model) [47] представляет собой модель преце-
дентов на верхнем уровне абстракции (разд. 2.2.2). Модель бизнес-прецедентов опре-
деляет обобщенные бизнес-процессы — бизнес-прецеденты. Бизнес-прецедент соот-
ветствует тому, что иногда называют возможностями системы (system feature).
(Возможности системы определяются в документе, описывающем видение системы
(system vision). Если при разработке системы представляется документ описания виде-
ния системы, он может использоваться взамен модели бизнес-прецедентов).
Диаграмма бизнес-прецедентов концентрируется на архитектуре бизнес-
процессов. Эта диаграмма дает возможность взглянуть на предполагаемое поведение
системы так сказать “с высоты птичьего полета”. Неформальное описание каждого из
бизнес-прецедентов должно быть кратким, ориентированным на деловую сторону сис-
темы, и концентрироваться на основных потоках видов деятельности. Модель бизиес-
прецедента не вполне подходит для того, чтобы объяснить разработчику, что же
должна делать система.
На этапе спецификации требований бизнес-прецеденты превращаются в прецеденты.
Именно на этом этапе определяются детальные прецеденты, и неформальное описа-
ние расширяется за счет включения в него подпроцессов и альтернативных процес-
сов, некоторых копий экранов, демонстрирующих GUI-интерфейс, а также взаимо-
связей между введенными прецедентами.
Субъекты (actor) диаграммы бизнес-прецедентов отличаются от внешних сущностей
на диаграмме контекста. Различие заключается в способе взаимодействия субъектов с
системой. Субъекты активны. Они управляют процессом. Они активизируют преце-
денты, отправляя им сообщения о событиях. Прецеденты управляются событиями.
Линии, связывающие субъектов и прецеденты, — это не потоки данных. Эти линии
связи представляют поток событий, исходящих от субъектов и поток откликов, исхо-
дящих от прецедентов.
Субъекты обладают любопытной двойственной природой. По отношению к системе
субъекты могут быть как внешними, так и внутренними сущностями. Они являются внеш-
ними сущностями, поскольку они взаимодействуют с системой, оставаясь вне ее. В то
же время они — внутренние сущности, поскольку система может поддерживать инфор-
мацию о субъектах, так что она может “со знанием дела” взаимодействовать с
“внутренними” субъектами. Системная спецификация — как модель системы — должна
описывать систему и ее среду. Среда содержит субъекты. Система сама может хранить
информацию о субъектах. Следовательно, спецификация заключает в себе две моде
ли, связанные с субъектами, — модель субъекта и модель данных о субъектах, которые
подлежат регистрации.
3.5.2.1. Пример моделирования бизнес-прецедентов
Р7 ПримерЗ.2. Телемаркетинг
Рассмотрите постановку задачи для приложения Телемаркетинг (раздел 2.3.4 и 3.5.1.1)
и постройте для нее диаграмму бизнес-прецедентов.
Один из возможных вариантов диаграммы бизнес-прецедентов показан на рис. 3.5.
3.5. Бизнес-модель требований 133
Рис. 3.5. Модель бизнес-прецедентов (Телемаркетинг)
На диаграмме представлены два субъекта: Telemarketer (Телемаркетер) и
Supporter (Благотворитель). Субъект Telemarketer просит систему запланировать
телефонный звонок благотворителю и осуществить соединение. При успешном со-
единении Supporter участвует как субъект. Бизнес-прецедент Schedule Phone
Conversation (Планирование телефонного разговора) (который в данном случае
включает установление соединения) становится частью функции, видимой извне
обоими субъектами.
Во время разговора субъекту Telemarketer может потребоваться получить доступ и
внести изменения в детализированную информацию о кампании и благотворителе. Эти
функции фиксируются в виде бизнес-прецедента (CRUD Campaign and Supporter
Details (Подробная информация о кампании и благотворителе). (CRUD — популярная
аббревиатура, которая обозначает четыре основных операции над данными: Create,
Read, Update, Delete (“Создать”, “Читать”, “Обновить” “Удалить”).
Наконец, бизнес-прецедент Enter Conversation Outcome (Ввод результатов раз-
говора) предназначен для ввода успешных или неуспешных результатов телемаркетин-
говоп деятельности. Этот прецедент имеет очевидное значения для обоих субъектов.
Указание отношений между прецедентами CRUD Campaign and Supporter
Details и Enter Conversation Outcome не обязательно. В общем случае все от-
ношения между прецедентами можно опустить, чтобы избежать беспорядка и загро-
мождения диаграммы. Как правило, прецеденты некоторым образом связаны с боль-
шинством остальных прецедентов, и включение в диаграмму всех отношений проти-
воречит ее предназначению.
3.5.3. Модель бизнес-классов
Модель бизнес-классов (business class model) — это модель классов. Точно так же, как в слу-
чае модели бизнес-прецедентов, различие заключается в уровне абстракции. Модель
134 Глава 3. Установление требований
бизнес-классов определяет основные “бизнес-объекты” системы — структуры данных
бизнес-процессов, которые составляют основу системы и определяют ее деятельность.
Модель бизнес-классов представляется на высоком уровне абстракции. На этом
уровне нас меньше интересует содержание атрибутов классов— достаточно имен
классов и их краткого описания.
Довольно любопытно отметить, что нередкой бывает ситуация, при которой субъ-
екты модели бизнес-прецедентов представляются как классы в модели бизнес-классов.
Это подтверждает нашу мысль о том, что субъекты зачастую выступают по отноше-
нию к системе как внешние и внутренние сущности (разд. 3.5.2).
3.5.3.1. Пример моделирования бизнес-классов
ПримерЗ.З.Телемаркетинг
j Рассмотрите постановку задачи, диаграмму контекста и диаграмму бизнес-
? прецедентов для приложения Телемаркетинг (раздел 2.3.4, 3.5.1.1 и 3.5.2.1) и построй-
i те для нее диаграмму бизнес-классов. Следующие соображения можно использовать
f как подсказки.
1. Акцент в системе сделан на планирование звонков. Само по себе планирование
} звонков является вычислительной процедурой, т.е. здесь решение является строго
алгоритмическим по природе. Тем не менее, очереди запланированных звонков и
; результаты звонков должны запоминаться в некоторой структуре данных.
s 2. Как обсуждалось выше, может потребоваться хранить информацию о субъектах в
классах.
Модель бизнес-классов в первом приближении показана на рис. 3.6. Диаграмма со-
держит шесть классов, два из которых (Supporter и Telemarketer) являются про-
изводными от субъектов модели бизнес-прецедентов. Алгоритм планирования звон-
ков получает телефонный номер и другую информацию от класса Supporter и пла-
нирует звонок одному из имеющихся в наличии телемаркетеров (Telemarketer).
Алгоритм в конечном счете долей быть реализован в базе данных системы в виде
хранимой процедуры {storedprocedure) (разд. 9.1.2.1).
Рис. 3.6. Модель бизнес-классов (Телемаркетинг)
Класс Call Scheduled (Планируемый звонок) содержит текущую очередь звон-
ков, включая звонки, которые в текущий момент являются активными. Результаты
звонков регистрируются в классе CallOutcome (Результат звонка), а также распро-
страняются в другие задействованные классы, такие как CampaignTicket (Билет
кампании) и Supporter.
3.6. Документ описания требований 135
Класс Campaign содержит класс CampaignTickets и связан с классом Scheduled
отношением “один ко многим”. Аналогично, объекты классов Supporter и
Telemarketer могут обладать многими объектами класса CallScheduled. Ассоциация
между классами CallScheduled и CallOutcome имеет кратность “один к одному”.
3.6. Документ описания требований
Документ, описывающий требования, является осязаемым результатом этапа уста-
новления требований. Большинство организаций вырабатывают документ описания
требований в соответствии с заранее определенным шаблоном. Шаблон определяет
структуру (содержание) и стиль документа.
Ядро документа описания требований состоит из формулировок (изложения) тре-
бований. В разделе 3.1 указывалось, что требования могут быть сгруппированы в виде
формулировок сервисов (зачастую называемых функциональными требованиями) и фор-
мулировок ограничений. Формулировки сути сервисов могут быть затем разделены на
требования к функциям (function requirements) и требования к данным (data requirements). (В
литературе термин “функциональные требования" (functional requirements) в широком и в
узком смысле используется как взаимозаменяемый. При использовании в узком смыс-
ле он соответствует тому, что мы называем требованиями к функциям).
Не говоря уже о самих требованиях, документ описания требований должен обра-
щаться к проектным вопросам. Обычно проектные вопросы рассматриваются в нача-
ле документа, а затем в конце документа. Во вводной части документа рассматриваете
ся бизнес-контекст проекта, включая цель проекта, участников проекта и основные
ограничения. Ближе к заключительной части документа поднимаются другие проект-
ные вопросы, включая план-график выполнения проектных работ, бюджет, риски,
документацию и т.д.
3.6.1. Шаблоны документа
Шаблоны для документов описания требований широко доступны. Их можно найти
в учебниках, стандартах, выпускаемых такими организациями как ISO, IEEE и т.д., на
Web-страницах консалтинговых фирм, программных средствах разработки и т.д. Со
временем каждая организация разрабатывает свои собственные стандарты, которые
соответствуют принятой в организации практике, корпоративной культуре, кругу чи-
тателей, типам разрабатываемых систем и т.д.
Шаблон документа описания требований определяет структуру документа и содержит
подробные указания о содержании каждого из разделов документа. Указания могут вклю-
чать содержание вопросов, мотивацию, примеры и дополнительные соображения [71].
На рис. 3.7 показано типичное оглавление документа описания требований. По-
следующие разделы включают объяснение к приведенному оглавлению.
3.6.2. Предварительные замечания к проекту
Часть документа описания требований, содержащая предварительные замечания к
проекту, преимущественно дает ориентиры тем руководителям и участникам проекта,
ответственным за принятие решений, которые, вероятно, не станут подробно изу-
чать документ целиком. В начале документа необходимо ясно обозначить цели и рамки
проекта, а затем описать деловой контекст системы.
1
136 Глава 3. Установление требований
Документ описания требований должен создать прецедент для системы. В частно-
сти, необходимо упомянуть обо всех усилиях, приложенных для обоснования необхо-
димости системы на этапе планирования системы (разд. 1.2). Документ описания тре-
бований должен прояснить вопрос о том, каким образом предлагаемая система может
способствовать достижению деловых целей и решению задач организацией.
Необходимо обозначить участников проекта (разд. 1.1.2) системы. Важно, чтобы
заказчик выступал не в виде безликого подразделения или офиса — необходимо при-
вести конкретные имена. К концу дня человек должен быть в состоянии решить, при-
емлемо ли поставляемое ПО для организации.
Документ описания требований
' " Содержание документа
' И рёдйарйттеЛьйыезамечамиякпроек^
1.1. 'Целиирамкипрф|ега! J ‘‘ ’’
1.2. Деловой кбнтексГ
'* '1.3.^чФтнШ проек^’’
1.4. Идей в отношении решений
* 1.5. Офор документа
Системныесервисы
’ 2.1. Рамки системы '''ч., _ ч .
: 2.2. Функциональные требования.
,2.3. Требования к данным , . ,
X ^СифгемнЫе ограничения ?
.^^^.^^(ребЬванияж интерфейсу:^,;' л
3.2. Требования к производительности £7'
' 3!ЗЙ₽ёфИ^я
д.; Х£3.4.'Эксг^^ <- > - • '
>< ^Проектныевопросы.
приложениям “
' > - ^Рлоссарий1 ? '
Аховые документа х
Рис. 3.7. Содержание документа описания требований
Хотя документ описания требований может быть как угодно далек от технических
решений, все же важно обсудить идеи., касающиеся решения, на самых ранних этапах ЖЦ
разработки. Особый интерес представляют готовые решения. Всегда неплохо рас-
смотреть вариант приобретения готового продукта вместо его разработки “с нуля”.
Документ описания требований должен предоставлять перечень существующих
программных пакетов и компонент, которые должны быть в дальнейшем изучены в
качестве вариантов возможных решений. Обратите внимание, что приобретение го-
3.6. Документ описания требований 137
тового решения изменяет процесс разработки, однако это не избавляет от необходи-
мости проведения анализа требований и проектирования системы!
Наконец, неплохо в заключение раздела предварительных замечаний к проекту
документа описания требований привести обзор оставшейся части документа. Это
может подтолкнуть занятого читателя к тому, чтобы изучить остальные части доку-
мента, а также способствует лучшему пониманию содержания документа. Обзор также
может содержать пояснения в отношении методологии анализа проектирования, вы-
бранной разработчиками.
3.6.3. Системные сервисы
Основная часть документа описания требований посвящена определению систем-
ных сервисов (разд. 1.3.1 и 3.1). Эта часть может занимать до половины всего объема до-
кумента. Это также, пожалуй, единственная часть документа, которая может содер-
жать обобщенные модели — модели бизнес-требований (разд. 3.5).
Рамки системы можно моделировать с помощью диаграммы контекста (разд. 3.5.1).
В пояснениях к диаграмме контекста должны быть четко определены рамки системы.
Без подобного определения проект не может быть застрахован от попыток “растя-
нуть” его рамки.
Функциональные требования можно моделировать с помощью диаграммы бизнес-
прецедентов (разд. 3.5.2). Однако, диаграмма охватывает перечень функциональных
требований только в самом общем виде. Как отмечалось в разд. 3.4, все требования
необходимо обозначить, классифицировать и определить.
Требования к данным можно моделировать с помощью диаграммы бизнес-классов
(разд. 3.5.3). Так же, как и в случае функциональных требований, диаграмма бизнес-
классов не даст полного определения структур данных для бизнес-процессов. Каждый
бизнес-класс требует дальнейших пояснений. Необходимо описать атрибутное на-
полнение классов и определить идентифицирующие атрибуты классов. В противном
случае невозможно правильно представить ассоциации.
3.6.4. Системные ограничения
Системные сервисы определяют, что должна делать система. Системные ограничения
(разд. 1.3.1 и 3.1) определяют, насколько система ограничена при выполнении обслу-
живания. Системные ограничения связаны со следующими видами требований.
Требования к интерфейсу.
Требования к производительности.
Требования к безопасности.
Эксплуатационные требования.
Политические и юридические требования.
Требования к интерфейсу определяют, как система взаимодействует с пользователями. В
документе описания требований определяется только “впечатление и ощущение” от GUI-
интерфейса. Начальное проектирование (закрашивание экрана) GUI-интерфейса прово-
дится во время спецификации требований и позже во время системного проектирования.
В зависимости от области приложения требования к производительности могут
играть довольно значительную роль в успехе проекта. В узком смысле они задают ско-
рость (время отклика системы), с которой должны выполняться различные задания. В
138 Глава 3. Установление требований
широком смысле, требования к производительности включают другие ограничения —
в отношении надежности, готовности, пропускной способности и т.д.
Требования к безопасности описывают пользовательские права доступа к информа-
ции, контролируемые системой. Пользователям может быть предоставлен ограни-
ченный доступ к данным или ограниченные права на выполнение определенных опе-
раций с данными.
Эксплуатационные требования определяют программно-техническую среду, если она
известна на этапе проектирования, в которой должна функционировать система. Эти
требования могут оказывать влияние на другие стороны проекта, такие как подготов-
ка пользователей и сопровождение системы
Политические требования и юридические требования зачастую подразумеваются, чем
явно формулируются в документе описания требований. Подобная ошибка может
обойтись очень дорого. Пока эти требования не выведены явно, программный про-
дукт может быть трудно развернуть по политическим или юридическим причинам.
Возможны и другие виды ограничений. Например, в отношении некоторых систем
могут предъявляться повышенные требования к легкости их использования
(требования в отношении пригодности к использованию) или легкости их сопровождения
(требования в отношении пригодности к сопровождению).
Значение выработки недвусмысленных определений для системных ограничении
трудно переоценить. Существует немало примеров проектов, которые провалились
из-за упущенных или неверно понятых ограничений. Эта проблема в равной мере от-
носится как к заказчикам, так и к разработчикам. Недобросовестные или нерассуди-
тельные разработчики могут разыграть “карту системных ограничений”, чтобы полу-
чить преимущество в своем стремлении уклониться от ответственности.
3.6.5. Проектные вопросы
Заключительная часть документа описания требований обращается к другим про-
ектным вопросам. Один из важных разделов этой части называется “Открытые вопросы .
Здесь поднимаются все вопросы, которые могут сказаться на успехе проекта и которые
не рассматривались в других разделах документа. Сюда относится ожидаемое возраста-
ние значения некоторых требований, которые в текущий момент выходят за рамки
проекта. Сюда можно отнести также любые потенциальные проблемы и отклонения в
поведении системы, которые могут начаться в связи с развертыванием системы.
В этой же части необходимо представить предварительный план-график выполне-
ния основных проектных заданий (разд. 1.3.8). Сюда же относится предварительное
распределение людских и других ресурсов. Для выработки стандартных плановых
графиков можно использовать программные средства управления проектами, напри-
мер, такие как система PERT (program evaluation-and-review technique — метод оценки
и пересмотра планов) или карты Гантта [51].
Прямым результатом составления план-графика может быть разработка предвари-
тельного бюджета. Стоимость проекта может быть выражена скорее в виде диапазона
значений затрат, а не конкретного значения. При наличии надлежащим образом до-
кументированных требований для оценки затрат можно использовать один из подхо-
дящих методов (например, балльную функциональную оценку (functionpoint analysis)).
Резюме 139
3.6.6. Приложения
Приложения содержат остальную, полезную для понимания требований, инфор-
мацию. Основным добавлением здесь служит глоссарий. Глоссарий определяет терми-
ны, сокращения и аббревиатуры, используемые в документе описания требований.
Значение толкового глоссария трудно переоценить. Неверное истолкование терми-
нологии таит в себе большую опасность для проекта.
Одна из особенностей, которую часто упускают из виду при составлении документа
описания требований, состоит в том, что в проблемной области, определяемой доку-
ментом, можно довольно неплохо разобраться с помощью изучения документов и
форм, используемых в процессах делопроизводства. При возможности следует вклю-
чать в документ заполненные формы — “пустые” формы не дают такого же уровня по-
нимания бизнес-процессов.
Раздел ссылок содержит перечень документов, которые упоминаются или исполь-
зуются при подготовке документа описания требований. К ним могут относиться кни-
ги и другие опубликованные источники информации, но — что, пожалуй, даже более
важно — необходимо также упомянуть протоколы совещаний, служебные записки и
внутренние документы.
Резюме
В этой главе были полностью рассмотрены вопросы, связанные с установлением
требований. Установление требований предшествует их спецификации. Установле-
ние требований касается их выявления и оформления в виде документа, который но-
сит преимущественно описательный характер. В результате спецификации требова-
ний — рассматриваемой в следующей главе — вырабатываются более формализован-
ные модели требований.
Выявление требований связано с их поиском по двум направлениям — в области зна-
ний о проблемной области и в области прецедентов. Эти два направления исследова-
ния требований дополняют друг друга и приводят к определению модели деловой
деятельности для разрабатываемой системы.
Существуют различные методы выявления требований, среди которых можно назвать
такие методы как проведение интервью С заказчиками и экспертами в проблемной
области, анкетирование, наблюдение, изучение документации и программных сис-
тем, создание прототипов, JAD- и RAD-методы.
Полученные от заказчиков требования могут перекрываться и противоречить друг
другу. Устранение дублирования и снятие противоречий — задача бизнес-аналитика, ко-
торый решает ее с помощью согласования и проверки обоснованности требований. Для над-
лежащего решения этой задачи бизнес-аналитик должен построить матрицу зависимо-
сти требований, а также приписать требованиям определенные риски и приоритеты.
Большие проекты связаны с управлением большими массивами требований. Для та-
ких проектов весьма существенным моментом является обозначение и классификация
формулировок требований. Затем можно определить иерархию требований. Осуществ-
ление подобных шагов обеспечивает необходимый уровень прослеживаемости тре-
бований на последующих стадиях проекта, а также надлежащую обработку запросов на
изменение требований.
Несмотря на то что установление требований не включает формального модели-
рования систем, уже на этом этапе ЖЦ разработки ПО можно построить бизнес-модель
140 Глава 3. Установление требований
основных требований. Бизнес-модель может быть представлена в виде трех общих диа-
грамм — диаграммы контекста, диаграммы бизнес-прецедентов и диаграммы бизнес-
классов.
Документ, который создается в результате выполнения этапа установления требо-
ваний— документ описания требований— начинается с общего описания замечаний к
проекту (которое создается, в основном, в интересах представления проекта руково-
дству). Основные части документа описывают системные сервисы и системные ограниче-
ния. Заключительная часть документа связана с остальными проектными вопросами,
включая подробности, касающиеся проектного план-графика и бюджета.
[И Вопросы
В1. В процессе установления требований мы стремимся согласовать общие требования, свя-
занные с представлениями о проблемной области, и требования, полученные в результате
анализа прецедентов. Объясните, в чем состоит различие между этими двумя типами тре-
бований? Может ли один из них превалировать над другим в процессе установления тре-
бований? Объясните свои доводы.
В2. При проведении интервью рекомендуется избегать небеспристрастных, предвзятых и на-
водящих вопросов. Можете ли вы представить себе ситуацию, при которой подобные во-
просы могли бы принести выгоду проекту?
ВЗ. Что такое прототипирование? Насколько оно полезно для установления требований?
В4. Что такое JAD-метод? В чем заключаются основные преимущества JAD-метода по сравне-
нию с другими методами установления требований?
BS. Что такое “растягивание рамок проекта"? Как справиться с этим явлением при установле-
нии требований?
В6. Перечислите и дайте определения проектных рисков.
В7. Почему требования необходимо пронумеровать?
В8. Что такое “подозрительная траектория изменений системы”?
В9. В чем отличие субъектов диаграммы бизнес-прецедентов от внешних сущностей диа-
граммы контекста?
В10. Опишите типичную структуру (оглавление) документа описания требований.
|В| Упражнения
; Рассмотрите постановку задачи для коммерческой деятельности по измерению затрат
! на рекламу (Advertising Expenditure Measurement — АЕМ).
i
•: 1. Организация, занимающаяся АЕМ-деятельностью, собирает данные по рекламе в
; отношении различных торговых точек, предлагающих средства аудиовизуальной
i информацию, теле- и радиостанций, газет, журналов, а также кинематографа, на-
• ружной и internet-рекламы.
2. Собранные данные позволяют охватить две области анализа, интересующие АЕМ-
\ клиентов. Клиенты могут заказать отчет о том, действительно ли реклама, за кото-
> рую они платят, появляется так, как было предусмотрено (это называется монито-
? рингом рекламной кампании). Клиент может также заказать отчет, который очерчи-
; вает их конкурентные позиции в отношении рекламы применительно к отрасли, в ко-
торой они работают (это называется отчетом о затратах). Отчеты о затратах
Упражнения 141
касаются уровня, которого достигли затраты рекламодателя или затраты на реклам-
s ный товар с точки зрения различных критериев (время, географические регионы,
средства информации и т.д.).
3. Отчеты о затратах составляют основу АЕМ-деятельности. Фактически, любой АЕМ- j
клиент (не только клиент, занимающийся рекламой) может приобрести отчет в виде f
программного обеспечения для генерации отчетов, изготовленного под заказ или в !
виде отпечатанных отчетов. Клиентская база АЕМ-предприятия состоит из индиви-
дуальных рекламодателей, рекламных агентств, средств массовой информации,
консультантов, покупающих средства информвции, а также руководителей подраз-
делений сбыта и маркетинга, органов, планирующих развитие средств информвции,
покупателей и т.д.
s 4. АЕМ-предприятие заключает контракты со многими торговыми точками, предла- ,
тающими средства информации, касающиеся получения от них на регулярной осно- '
ве электронных файлов журнвлов, которые содержат информацию по содержанию ’
; рекламы в этих торговых точках. Информация из регистрационных журналов пере-
носится в базы данных АЕМ, а затем подвергается тщательной проверке — отчасти
’ автоматически, отчасти вручную. Задача проверки состоит в том, чтобы подтвер- ,
дить, что все зафиксированные детали, касающиеся рекламы, овладеют достовер- .
ностью и логичностью в контексте информационной среды. Существенную часть
АЕМ-деятельности составляет ручной ввод (мониторинг) данных по рекламе, для ко-
торой не существует электронных учетных журналов.
5. После ввода и проверки реклама подвергается ревалоризации — процессу оцени- \
вания затрат, необходимых на ту или иную рекламу.
У 1. Измерение затрат на рекламу (АЕМ) — обратитесь к приведенной выше постановке зада-
чи. Изобразите контекстную диаграмму для АЕМ-системы. Сделайте пояснения к модели.
У 2. Измерение затрат на рекламу (АЕМ) — обратитесь к приведенной выше постановке задачи.
Изобразите диаграмму бизнес-прецедентов для АЕМ-системы. Сделайте пояснения к модели.
У З. Измерение затрат на рекламу (АЕМ) — обретитесь к приведенной выше постановке задачи.
Изобразите диаграмму бизнес-классов для АЕМ-системы. Сделайте пояснения к модели.
Спецификация требований
Требования необходимо специфицировать (т.е. задать) графически или каким-либо
иным формальным способом. Всесторонняя спецификация системы может потребо-
вать использования многих типов моделей. Язык UML изобилует интегрированными
методами моделирования, способными помочь бизнес-аналитику справиться с этой
задачей. Спецификация — подобно процессу разработки ПО в целом — итеративный
процесс с пошаговым наращиванием уровня детализации моделей. Немаловажную
роль в успешном моделировании играет использование CASE-средств.
В результате спецификации требований вырабатываются три категории моделей:
модели состояний, модели поведения и модели изменения состояния. Для каждой из
категорий существует несколько методов работы с ними. В этой главе объясняются и
иллюстрируются на примерах все основные методы моделирования языка UML.
Несмотря на то, что мы начнем изучение с моделей состояния, затем перейдем к
моделям поведения, а затем — к моделям изменения состояний, это не отражает ре-
альной последовательности, в которой проводится моделирование. Многие модели
разрабатываются в параллель и служат источником взаимного развития. Это в осо-
бенности справедливо в отношении двух основополагающих типов моделей — моде-
лей классов и моделей прецедентов.
4.1. Принципы спецификации требований
Спецификация требований связана с доскональным моделированием требований за-
казчиков, определенных в процессе установления требований. При этом рассматрива-
ются только услуги, которые стремятся получить от системы заказчики (формулировки
сервисов) (разд.3.1). На этапе спецификации требований формулировки ограничений не
подлежат дальнейшей проработке, хотя и могут претерпеть изменения как результат
обычного цикла итерации.
В качестве входной информации процесса спецификации требований выступают
неформальные требования заказчиков, а результатом этого процесса являются моде-
ли спецификации проектных конструкций. Эти модели (разд. 2.2) дают более фор-
мальное определение различных сторон (представлений) системы. Обычно требова-
ния пользователей в процессе спецификации подразделяются на две основные кате-
гории: функциональные требования и требования к данным.
4.2. Спецификации состояний 143
В качестве результата этапа спецификации выступает расширенный (“детально
проработанный”) документ описания требований (разд. 3.6). Новый документ часто
называют документом спецификации требований (или просто “спецификацией” на жар-
гоне разработчиков). Структура исходного документа не изменяется, однако содер-
жание значительно расширяется за счет глав, которые определяют требования заказ-
чиков. Постепенно для целей проектирования и реализации документ спецификации
требований заменяет документ описания требований (на практике, расширенный до-
кумент может по-прежнему называться документом описания требований).
Модели спецификаций можно разделить на три группы.
1. Модели состояний.
2. Модели поведения.
3. Модели изменения состояний.
Модели состояний “детализируют” требования к данным. Модели поведения обеспе-
чивают детализированные спецификации для функциональных требований. Модели
изменения состояний охватывают два вида требований. Они призваны объяснить, ка-
ким образом действие функций приводит к изменению данных.
Модели представляются в виде диаграмм на языке визуального моделирования (Visual Model-
ing Language} — в нашем случае это язык UML. Обычно диаграмма служит целям моделиро-
вания одной из сторон системы — состояний, поведения или изменения состояний. За-
метное исключение составляет диаграмма классов, которая определяет все три аспекта —
состояние и поведение объектов, и, косвенно, изменения состояний объектов.
Каждая диаграмма дает представление об определенной стороне системы. Взятые
вместе диаграммы дают возможность разработчикам и пользователям взглянуть на
предлагаемое решение с разных точек зрения, выделяя одни его стороны и игнори-
руя другие. Ни одна из диаграмм в отдельности не дает полного определения систе-
мы. Систему можно понять только через взаимосвязанный набор диаграмм.
Аналогично случаю интерпретации завершенных моделей конструирование диа-
грамм — это не последовательный процесс построения одной диаграммы за другой.
Диаграммы разрабатываются в параллель, и в результате каждой последующей итера-
ции к ним добавляются новые детали. В то время, как разработчики должны следо-
вать строго определенному процессу разработки, решение о том, какая из моделей
должна играть роль “движущей силы” разработки, в значительной мере зависит от
личных предпочтений аналитика. Обычно диаграммы прецедентов и модели клас-
'ов— как наиболее важные типы моделей — конструируются параллельно, взаимно
“обогащая” друг друга идеями.
С каждой новой итерацией разработки глубина и степень детализации специфи-
кации возрастает. Многие более глубокие свойства объектов модели выражаются ско-
рее в текстовом, нежели графическом виде. Некоторые свойства определяют замысел
объекта модели, а не результат анализа. Некоторые другие свойства могут отражать
особенности CASE-средств.
4.2. Спецификации состояний
Состояние объекта определяется значениями его атрибутов и ассоциаций. Напри-
мер, объект BankAccount (Банковский счет) может находиться в состоянии
“превышение кредитного лимита”, если значение атрибута balance (баланс) отрица-
144 Глава 4. Спецификация требований
тельно. Поскольку состояния объекта определяются структурам данных, модели
структур данных называются спецификациями состояний.
Спецификация состояний дает статический взгляд на систему (поэтому моделиро-
вание состояний часто называют статическим моделированием). Здесь основной за-
дачей является определение классов проблемной области, их атрибутов и отношений с
другими классами. Вначале операции классов обычно не рассматриваются. Они выво-
дятся из моделей спецификации поведения.
В типичной ситуации сначала определяются классы-сущности, т.е. классы, которые
определяют проблемную область и характеризуются постоянным присутствием в базе
данных системы. Подобные классы иногда называются “бизнес-классами”. Классы, ко-
торые обслуживают системные события {управляющие классы) и классы, которые пред-
ставляют GUI-интерфейс (классы представления или пограничные классы) не устанавли-
ваются до тех пор, пока не станут известны поведенческие характеристики системы.
4.2.1. Моделирование классов
Модель классов — это краеугольный камень разработки объектно-ориентирован-
ной системы. Классы лежат в основании наблюдаемости свойств и поведения систе-
мы. К сожалению, классы всегда трудно поддаются определению, а свойства классов
не всегда очевидны. Весьма маловероятно, чтобы два аналитика пришли к одному и
тому же множеству классов и их свойств для одной и той же нетривиальной проблем-
ной области. Хотя модели классов могут отличаться, конечный результат и степень
удовлетворенности пользователя могут быть в равной мере достаточными (или в рав-
ной мере недостаточными).
Моделирование классов — это не детерминированный процесс. Не существует об-
щего рецепта отыскания и определения наилучших классов. Этот процесс в значи-
тельной мере носит итеративный и пошаговый наращиваемый характер. К факторам,
определяющим успешное проектирование классов, относится уровень квалификации
и опыта аналитика, в частности, перечисленные ниже возможности.
1. Знания в области моделирования классов.
2. Понимание проблемной области.
3. Опыт в области аналогичных и успешных проектов.
4. Способность смотреть вперед и предвидеть последствия решений.
5. Готовность к пересмотру модели с целью устранения недостатков и т.д.
Последний момент связан с использованием CASE-средств. Широкомасштабное
применение CASE-технологии может стать препятствием на пути разработки системы
в технологически незрелых организациях (разд. 1.1.4.2). Однако использование CASE-
средств для повышения личной продуктивности всегда оправдано.
4.2.1.1. Выявление классов
Два разных аналитика, как правило, не могут прийти к идентичным моделям клас-
сов для одной и той же проблемной области, и точно так же два разных аналитика не
пользуются одним и тем же мыслительным процессом при выделении классов. Лите-
ратура изобилует подходами, предлагаемыми для выявления классов. Аналитики мо-
гут поначалу даже следовать одному из этих подходов, однако последующие итерации,
4.2. Спецификации состояний 145
как правило, обязательно приводят к использованию нешаблонных и в чем-то даже
случайных механизмов.
Барами (Bahraini) [4] подробно изучил главные особенности четырех основных
подходов к выявлению классов (class discovery). Ниже перечислены эти подходы.
1. Подход на основе использования именных групп.
2. Подход на основе использования общих шаблонов для классов.
3. Подход на основе использования прецедентов.
4. Подход CRC (class-responsibility-collaborators — класс-обязанности-“сотрудники”).
Барами [4] поставил в соответствие каждому из подходов опубликованные работы,
однако — по нашему мнению— только последний подход обладает неоспоримым ис-
точником. Теперь мы обобщим эти подходы, а затем приведем примеры, в которых
используется комплексный подход (mixed approach).
4.2.1.1.1. Подход на основе использования именных групп
Подход на основе использования именных групп (т.е. имен существительных в предло-
жениях) предполагает, что аналитик читает формулировки документа описания тре-
бований в поисках именных групп. Каждое имя существительное рассматривается как
потенциальный класс (candidate class). Затем список всех классов разделяется на сле-
дующие три группы.
1. Релевантные или подходящие классы.
2. Нечеткие или сомнительные классы.
3. Нерелевантные или неподходящие классы.
К нерелевантным (irrelevant) относятся классы, которые выходят за рамки проблем-
ной области. Для них не удается дать формулировку их назначения. Опытные анали-
тики-практики вероятнее всего не включают неподходящие классы в первоначальный
список потенциальных классов. Таким образом удается избежать формальных шагов
по идентификации и исключению нерелевантных классов.
К релевантным (relevant) относятся классы, которые безусловно принадлежат про-
блемной области. Имена существительные, представляющие имена этих классов, час-
то встречаются в документе описания требований. Кроме того, значение и назначе-
ние этих классов можно обосновать на основе общих знаний о прикладной области, а
также на основе изучения аналогичных систем, руководств, документов и патенто-
ванных программных пакетов.
К нечетким (fuzzy) относятся классы, которые нельзя уверенно и безоговорочно
признать подходящими. Они составляют наибольшую проблему. Их необходимо про-
анализировать более глубоко, а затем либо включить в список релевантных классов,
либо исключить из списка нерелевантных. Окончательное отнесение этих классов к
той или другой группе, собственно, и проводит различие между хорошей и плохой
моделью классов.
Подход па основе использования именных групп предполагает наличие полного и
корректного документа описания требований. На практике это предположение редко
соответствует действительности. Но даже если оно обоснованно, кропотливое изуче-
146 Глава 4. Спецификация требований
ние больших объемов текста не обязательно должно привести к получению исчерпы-
вающего и точного результата.
4.2.1.1.2. Подход на основе использования общих шаблонов
для классов
Подход на основе использования общих шаблонов для классов позволяет вывести потен-
циальные классы на основе теории родовой классификации объектов. Теория класси-
фикации касается разделения мира объектов на удобные группы, что позволяет более
эффективно строить рассуждения о них.
Барами [4] приводит следующий перечень групп (шаблонов) для выявления по-
тенциальных классов.
Понятийный (или концептуальный} класс (concept class) представляет собой идею,
которую разделяет или с которой согласна значительная общность людей. В
отсутствие понятий люди не способны эффективно общаться или даже общаться
на некоем удовлетворительном уровне. Например, Reservation
(Резервирование) — это понятийный класс, относящийся к системе
резервирования мест в авиакомпаниях.
Событийный класс (events class). Событие— это нечто, что не требует времени
применительно к нашей временной шкале. Например, Arrival (Прибытие) — это
событийный класс, относящийся к системе резервирования мест в авиакомпаниях.
Организационный класс (organization class). Организация — это любой вид
целенаправленного объединения или совокупности сущностей. Например,
TravelAgency (Бюро путешествий) — это класс, относящийся к системе
резервирования мест в авиакомпаниях.
Класс "людей” (people class). Под “людьми” здесь понимается скорее роль, которую
человек играет в той или иной системе, а не физическое лицо. Например,
Passenger (Пассажир) — это класс, относящийся к системе резервирования мест в
авиакомпаниях.
Класс местоположений (places class). Местоположение определяет физическое
расположение объектов, связанных с информационной системой. Например,
Traveloffice (Офис бюро путешествий )— подобный класс, относящийся к
системе резервирования мест в авиакомпаниях.
Дж. Рамбау (J. Rumbaugh), А. Джекобсон (I. Jacobson) и Г. Буч (G. Booch) [76]
предлагают другую схему классификации.
Физический класс (physicalclass) (например, Airplane (Самолет)).
Бизнескласс (business class) (например, Reservation).
Логический класс (logicalclass) (например, FlightTimetable (Расписание рейсов)).
Прикладной класс (application class) (например, ReservationTransaction
(Операция резервирования)).
Компьютерный класс (computer class) (например, Index (Индекс)).
Поведенческий класс (behavioral class) (например, Reservationcancellation
(Отмена резервирования)).
4.2. Спецификации состояний 147
Подход на основе использования общих шаблонов классов служит в качестве полез-
ного руководства, но не определяет систематического процесса, посредством которого
можно было бы выделить надежное и полное множество классов. Этот подход можно с
успехом использовать для определения начального множества классов или для провер-
ки того, должны ли некоторые классы (полученные другими способами) присутствовать
в нашем множестве или, напротив, отсутствовать в нем. Однако, подход на основе ис-
пользования общих шаблонов классов слишком слабо связан со специфическими требо-
ваниями пользователей, чтобы претендовать на исчерпывающее решение.
Особая опасность, связанная с подходом на основе использования общих шаблонов
классов, заключается в неверном истолковании имен классов. Например, что означает
Arrival (Прибытие)? Означает ли это прибытие на взлетно-посадочную полосу (время
приземления), прибытие к терминалу (время высадки), прибытие в зал возврата багажа
(время таможенного досмотра) и т.д.? Аналогично, слово Reservation (в данном слу-
чае резервация. Прим, ред.) в среде североамериканских индейцев имеет совершенно
иное значение по сравнению с тем, что имелось в виду до сих пор.
4.2.1.1.3. Подход на основе использования прецедентов
Подходу на основе использования прецедентов придается особое значение в языке UML.
Можно даже сказать, что этот подход рекомендуется использовать в рамках UML (если
быть точным — то в рамках методологии RUP (Rational Unified Process)). Графическая
модель прецедентов сопровождается неформальными описаниями, а также диаграмма-
ми последовательностей и кооперации для отдельных прецедентов (разд. 2.2 и далее в
этой главе). Эти дополнительные описания и шаги определения диаграмм (и объектов)
требуется выполнить для каждого прецедента. На основе этой информации можно
прийти к обобщениям, необходимым для выявления потенциальных классов.
Подход, направляемый прецедентами, обладает особенностями, присущими под-
ходу снизу-вверх. После того, как прецеденты становятся известны, а представление о
системе с точки зрения взаимодействия, по меньшей мере, частично определено с по-
мощью диаграмм последовательностей, объекты, используемые в этих диаграммах,
приводят к выявлению классов.
В действительности этот подход в чем-то похож на подход, использующий именные
группы. Их объединяет тот факт, что прецеденты специфицируют требования. Оба
подхода направлены на изучение формулировок, изложенных в документе описания
требований, чтобы выявить в итоге потенциальные классы. То, что эти формулировки
излагаются в повествовательной форме или представлены графически, имеет второ-
степенное значение. В любом случае на этом этапе ЖЦ разработки ПО большую часть
прецедентов можно описать только в текстовой форме без диаграмм вза- -одействия.
Подход, основанный на прецедентах, страдает теми же недостатт и, что и под-
ход, использующий именные группы. Будучи по сути подходом сниз) ерх в смысле
точности, он опирается на полноту и корректность моделей прецеден гов. В результа-
те, он даже может привести к нежелательному разбалансированию итеративного и
наращива юго процесса разработки ПО, при котором модели прецедентов должны
быть завершены еще до построения моделей классов. В общем, каковы бы ни были
цели и средства, это приводит к функциональному подходу (Junction-driven approach)
(сторонники объектно-ориентированного подхода предпочитают называть его про-
блемно-ориентированным (problem-driven)).
148 Глава 4. Спецификация требований
4.2.1.1.4. Подход CRC
Подход CRC (Class-Responsibility-Collaborators — класс-ответственность-“сотруд-
ники”) представляет собой нечто большее, чем метод выявления классов, — это при-
влекательный способ интерпретации и изучения объектов (а также и обучения объ-
ектному подходу). Наибольшую известность подход CRC получил благодаря работам
Ребекки Вирфс-Брок (Rebecca Wirfs-Brock) и ее коллег Б. Вилкерсон (В. Wilkerson) и
Л. Винер (L. Wiener) [94], [93].
Подход CRC включает в себя сеансы “мозгового штурма”, проведение которых облег
чается за счет использования специально подготовленных карточек. Карточки состоят из
трех отделений: имя класса записывается в верхнем отделении, “обязанности” класса пере-
числены в левом отделении, а “сотрудники" перечислены в правом отделении. Обязанно-
сти— это услуги (операции), которые класс готов выполнить в интересах других классов.
Для выполнения многих обязанностей необходимо участие (обслуживание) со стороны
других классов. Такие классы перечисляются как “сотрудники”.
Процесс CRC— это живой процесс, во время которого разработчики “играют в
карты”, они заполняют карточки именами классов и назначают им “обязанности’’ и
“сотрудников” в ходе исполнения сценария обработки информации (например, сце-
нария прецедента). В тех случаях, когда возникает потребность в некоей услуге, а су-
ществующие классы не покрывают ее, создается новый класс, которому назначаются
соответствующие “обязанности” и “сотрудники”. Если класс становится “слишком за-
нятым”, он разделяется на несколько меньших классов.
Подход CRC отличается от других подходов тем, что при его использовании выде-
ление классов является результатом анализа сообщений, передаваемых между объек-
тами для выполнения задач обработки информации. Акцент делается на унифициро-
ванном методе распределения “интеллекта” в системе, и некоторые классы могут
быть скорее получены, исходя из подобной технической потребности, чем выявлены
в качестве “бизнес-объектов” как таковых. В этом смысле метод CRC может быть бо-
лее приемлемым для проверки правильности выбора классов уже выявленных с по-
мощью других методов. Подход CRC также полезен при установлении свойств классов
(которые логически следуют из “обязанностей” и типов “сотрудников” класса).
4.2.1.1.5. Комплексный подход
На практике процесс выявления классов в разное время, вероятнее всего, следует
разным подходам. Зачастую, он включает элементы всех четырех подходов, рассмот-
ренных выше. Немаловажными факторами при этом выступают общая эрудиция экс-
перта, его опыт и интуиция. Процесс в чистом виде не следует ни методу сверху-вниз,
ни методу снизу-вверх — он все время идет “из средины”. Подобный подход к выявле-
нию классов мы называем комплексным подходом (mixed approach).
Вот один из возможных сценариев. Начальное множество классов можно сформи-
ровать на основе общих знаний и опыта эксперта. При этом дополнительно можно
руководствоваться подходом на основе общих шаблонов классов. Остальные классы
можно добавить, основываясь на анализе обобщенного описания проблемной облас-
ти с использованием подхода на основе именных групп. Если в распоряжении анали-
тика имеются прецеденты, можно воспользоваться подходом, направляемым преце-
дентами, чтобы добавить новые и проверить состоятельность существующих классов.
Наконец, подход CRC позволяет применить “мозговой штурм” для проверки пра-
вильности выбора выделенного к этому времени множества классов.
4.2. Спецификации состояний 149
4.2.1.1- 6. Некоторые правила выявления классов
Ниже приведен далеко не полный перечень руководящих принципов или правил, ко-
торым должен следовать аналитик при выборе потенциальных классов. Вновь напо-
минаем о том, что здесь мы имеем дело только с классами-сущностями.
1. Для каждого класса должно быть ясно сформулировано его назначение в системе.
2. Каждый класс — это шаблон описания множества объектов. Единичные классы,
для которых можно представить существование только одного объекта, весьма
маловероятны среди “бизнес-объектов”. Подобные классы обычно составляют
в приложении “общее знание” и как правило жестко запрограммированы в
программах приложения. Например, если система спроектирована для единст-
венной организации, существование класса Organization (Организация) мо-
жет быть не оправданно.
3. Каждый класс (т.е. класс-сущность) должен содержать набор атрибутов. Хоро-
шим приемом является установление идентифицирующих атрибутов (ключей),
чтобы помочь нам судить о мощности (cardinality) класса (т.е. ожидаемом коли-
честве объектов данного класса в базе данных). Следует, однако, помнить о
том, что класс не обязательно должен обладать пользовательским ключом.
Объекты классов идентифицируются с помощью идентификаторов объектов
(СТО) (разд. 2.1.1.3).
4. Каждый класс должен отличаться от атрибута. Представляется ли понятие
классом или атрибутом зависит от области приложения. Цвет автомобиля
обычно воспринимается как атрибут класса Саг (Автомобиль). Однако на фаб-
рике по производству красок Color (Цвет) — это определенно класс со своими
собственными атрибутами (яркостью, насыщенностью, прозрачностью и т.д.).
5. Каждый класс содержит набор операций. Однако на данном этапе мы не касаемся
вопросов идентификации операций. Операции, входящие в интерфейс класса
(сервисы, предоставляемые классом системе), являются логическим следстви-
ем формулировки назначения класса (пункт 1).
4.2.1.1.7. Примеры выявления классов
Давайте проанализируем требования с целью выделения потенциальных классов. В
первом утверждении подходящими классами являются классы Degree (Степень) и
Course (Курс). Эти два класса удовлетворяют пяти правилам, перечисленным ранее.
Мы пока не уверены, должен ли .и каким образом класс Course быть сужен до классов
CompulsoryCourse (Обязательный курс) и ElectiveCourse (Выборочный курс). На-
пример, ясно, что курс является обязательным или выборочным в зависимости от сте-
пени. Возможно, что различие между обязательными и выборочными курсами может
быть зафиксировано с помощью ассоциации или даже атрибута класса. Таким образом,
CompulsoryCourse и ElectiveCourse рассматриваются как нечеткие классы.
Второе утверждение идентифицирует только атрибуты класса Course, а именно
course_level (уровень курса) и credit_point_value (количество условных оч-
ков). Третье утверждение характеризует ассоциацию между классами Course и
Degree. Четвертая формулировка вводит атрибут min_total_credit_points
(минимальное общее количество условных очков) в качестве атрибута класса Degree.
150 Глава 4. Спецификация требований
^7 "Пример 4.1 Запись «ауниверситетские курсы
) Рассмотрите следующие требования к системе Запись на университетские курсы и вы-
делите потенциальные классы. ;
; 1. Для получения каждой университетской степени существует несколько обязатель- >
' ных и несколько выборочных курсов.
| 2. Каждому курсу соответствует заданный уровень и значение условных очков (Credit-
point — условное очко, начисляемое за прослушивание какого-либо курса (за один
курс может быть начислено несколько очков); студент обязан набрать на данном го-
ду обучения такое число курсов, чтобы число очков за них было не ниже определен-
; ного значения. Прим. ред.).
'• 3. Курс может быть составной частью системы получения произвольного количества
s степеней.
> 4. Каждая степень определяет минимальное общее значение условных очков, требуе-
’ мое для получения степени (например, для степени бакалавра (вычислительные и
информационные системы) требуется 68 очков, включая обязательные курсы).
5. Студенты могут составлять из дисциплин программы обучения, приспособленные к
‘‘ их индивидуальным нуждам и обеспечивающие им получение степени, на которую
они претендуют.
Последнее утверждение позволяет нам выделить три новых класса: Student
(Студент), Courseoffering (Предлагаемый курс) и StudyProgram (Программа обу-
чения). Первые два, безусловно, являются релевантными классами, а вот
StudyProgram можно превратить в ассоциацию между классами Student и
Courseoffering. Поэтому StudyProgram классифицируется как нечеткий класс.
Наши рассуждения отражены в табл. 4.1.
— sir* - - . гл :-z .'Г'1 <• ?«-. . - ..’
Пример 4.2. Магазин видеопроката
< Рассмотрите следующие требования к системе Магазин видеопроката и выделите по-
; тенциальные классы.
; 1. Магазин видеопроката держит в запасе огромную видеотеку современных популярных
видеофильмов. Конкретный фильм может храниться на видеокассетах или дисках.
; 2. Видеокассеты могут быть записаны в формате “Beta” или “VHS". Видеодиски запи-
; саны в формате DVD.
3. Для каждого фильма установлен конкретный период проката (исчисляемый в днях) с
i соответствующей платой за прокат за этот период.
1 4. Видеомагазин должен быть в состоянии немедленно дать ответ на любой запрос по
I наличию фильмов в запасе, а также количеству кассет или дисков (текущие условия
j по каждой ленте и диску должны быть известны и зафиксированы).
Таблица 4.1. Потенциальные классы (Запись на университетские курсы)
Релевантные классы Нечеткие классы
Course (Курс) Degree (Степень) Student (Студент) Courseoffering (Предлагаемый курс) CompulsoryCourse (Обязательный курс) и ElectiveCourse (Выборочный курс) StudyProgram (Программа обучения)
4.2. Спецификации состояний 151
Первое утверждение содержит несколько имен существительных, но только неко-
торые из них можно превратить в потенциальные классы. “Видеомагазин” — это не
класс, поскольку он составляет всю систему (в базе данных может быть только один
объект этого класса — так называемый единичный класс). Аналогично, понятия “запаса”
и “видеотеки” слишком общие, чтобы рассматривать их в качестве классов, по край-
ней мере на этом этапе. Релевантными классами представляются MovieTitle
(Название фильма), VideoTape (Видеокассета) и VideoDisk (Видеодиск).
Второе утверждение вводит дополнительную специализацию видеопроката как про-
ката видеокассет и дисков. Мы можем предложить три новых класса: BetaTape,
VHSTape и DVDDisk. Однако поскольку мы имеем дело только с одним типом видео-
дисков, в конечной модели можно не оставлять оба класса: VideoDisk и DVDDisk.
Какой из двух классов оставить, зависит от конечного уровня специализации приме-
нительно к видеокассетам и дискам. Заметим, что мы пока не уверены в том, будут ли
классы BetaTape и VHSTape обладать какими-либо отличительными атрибутами (за
исключением того факта, что один из них принадлежит типу Beta, а другой — VHS).
Третье утверждение говорит о том, что каждое наименование фильма отличается
условиями проката, связанными с ним. Однако не ясно, что понимается под
“фильмом” — наименование фильма или же носитель фильма (кассета или диск)? Нам
необходимо прояснить это требование с заказчиками. Тем временем, мы можем
предпочесть объявить класс Rentalconditions (Условия проката) как нечеткий,
вместо того, чтобы хранить информацию о периоде проката и плате за прокат в клас-
се для наименования фильма или для носителя фильма.
Последняя формулировка убеждает нас в том, что классы BetaTape, VHSTape и
DVDDisk (пли VideoDisk) — релевантные. Нам требуется хранить информацию о те-
кущих условиях для каждой кассеты и диска. Однако атрибуты наподобие
video condition (условия видеопроката) или number_currently_available
(количество, имеющееся в наличии) можно в общем объявить в абстрактном классе
верхнего уровня (назовем его VideoMedium (Видеоноситель)), после чего они могут
быть унаследованы конкретным подклассом (таким как VHSTape). Итоги наших рас-
суждений отражены в табл. 4.2.
Таблица 4.2. Потенциальные классы (Магазин видеопроката)
Релевантные классы Нечеткие классы
MovieTitle (Название фильма) Rentalconditions (Условия проката)
VideoMedium (Видеоноситель)
VideoTape (Видеокассета)
VideoDisk (или DVDDisk)
BetaTape
VHSTape
Первое утверждение содержит понятия “клиент”, “контракт” и “товар”. Наша об-
щая эрудиция и опыт подсказывают нам, что это типичные классы. Однако понятия
контракта и товара не входят в рамки системы Управление контактами с клиентами и
должны быть отброшены.
152 Глава 4. Спецификация требований
Рассмотрите следующие требования к системе Управление контактами с клиентами и .
! выделите потенциальные классы.
i 1. Система поддерживает функции “постоянного контакта” с нашей наличной и потен-
j циальной клиентской базой, так чтобы откликаться на ее нужды и заполучать новые
контракты на приобретение наших товаров.
- 2. Система хранит имена, номера телефонов, обычные почтовые и курьерские адреса
‘ и т.д. организаций и наших контактных лиц в этих организациях.
’ 3. Система позволяет нашим сотрудникам планировать задания и мероприятия, кото-
j рые необходимо провести в отношении наших контактных лиц. Сотрудники плани-
руют задания и мероприятия для других сотрудников или для себя.
, 4. Задание — это группа мероприятий, которые осуществляются для достижения оп-
ределенного результата. Результатом может быть превращение потенциального
клиента в клиента, организация доставки товара или решение проблемы клиента. К
обычным типам мероприятий относятся телефонный звонок, визит, отправка факса,
устройство обучения и т.д.
Customer (Клиент) — это релевантный класс, однако мы можем предпочесть на-
звать его Contact (Контакт), имея в виду, что не все контакты осуществляются с на-
шими настоящими клиентами. Различие между наличным и потенциальным клиентом
может оправдать или не оправдать введение таких классов как Currentcustomer
(Наличный клиент) и ProspectiveCustomer (Потенциальный клиент). Поскольку
уверенности у нас нет, мы объявляем эти классы нечеткими.
Второе утверждение проливает новый свет на приведенные выше рассуждения.
Нам необходимо провести различие между контактной организацией и контактным
лицом. Имя Customer не кажется слишком удобным для названия класса. Помимо
прочего, понятие Customer подразумевает только наличного клиента и, кроме того,
это может заключать в себе как понятие организации, так и контактного лица. Наше
новое предложение состоит в том, чтобы назвать классы следующим образом:
Organization (Организация), Contact (Контакт) (подразумевается контактное ли-
цо), CurrentOrg (Наличная организация) (т.е. организация, являющаяся нашим на-
личным клиентом) и ProspectiveOrg (Потенциальная организация) (т.е. организа-
ция, являющаяся нашим потенциальным клиентом).
Во втором утверждении упоминается несколько атрибутов классов. Однако обыч-
ный и курьерский почтовые адреса представляют собой составные атрибуты и при-
менимы к обоим классам: Organization и Contact. Поэтому PostalAddress и
Courier Address — законные нечеткие классы.
Таблица 4.3. Потенциальные классы (Управление контактами с клиентами)
Релевантные классы Нечеткие классы
Organization (Организация) CurrentOrg
Contact(Контакт) ProspectiveOrg
Employee (Сотрудник) PostalAddress
Task (Задание) CourierAddress
Event (Мероприятие)
4.2. Спецификации состояний 153
В третьей формулировке вводится три релевантных класса Employee
(Сотрудник), Task (Задание) и Event (Мероприятие). Это предложение объясняет
суть плановой деятельности.
Последнее утверждение посвящено дальнейшему прояснению смысла и взаимоот-
ношений между классами, однако здесь не вводится ни одного нового класса.
4.2.1.2. Спецификация классов
После того, как перечень потенциальных классов сформирован, необходима их
дальнейшая спецификация: классы требуется включить в диаграмму классов и опре-
делить их свойства. Некоторые свойства можно ввести и отобразить внутри графиче-
ских пиктограмм, представляющих классы на диаграмме классов. Многие другие
свойства, включенные в спецификацию класса, имеют только текстовое представле-
ние. CASE-средства, как правило, обладают возможностями редактирования, позво-
ляющими легко вводить или модифицировать подобную информацию посредством
диалоговых окон, снабженных вкладками, или с помощью аналогичных способов.
Как объяснялось в начале этой главы, классы задаются на определенном уровне
абстракции. Более развитые возможности моделирования языка UML здесь не ис-
пользуются — они рассматриваются в главе 5 и последующих главах.
4.2.1.2.1. Именование классов
Каждому классу необходимо присвоить имя. При работе с некоторыми CASE-
средствами помимо имени классу можно также присвоить код, возможно, отличный
от имени. Код может удовлетворять соглашениям по именованию, требуемым целе-
вым языком программирования или СУБД. Для генерации программного кода из
проектной модели используется именно код класса, а не имя.
Мимоходом, мы приняли определенное соглашение в отношении имен классов. Это
соглашение заключается в том, что имя класса начинается с заглавной буквы. Для состав-
ных имен в качестве первой буквы каждого слова также используется заглавная буква (вместо
того, чтобы отделять слова знаком подчеркивания или дефисом), Это всего лишь реко-
мендуемое соглашение, однако среди разработчиков оно нашло довольно много при-
верженцев. (В разд. 6.1.3.2 к имени каждого класса рекомендуется добавить однобуквен-
ный префикс для обозначения программного слоя, к которому принадлежит класс).
Имя класса должно быть именем существительным в единственном числе
(например, Course) либо, при возможности, сочетанием прилагательного и сущест-
вительного в единственном числе (например, CompulsoryCourse). Ясно, что класс
представляет собой шаблон для множества объектов и использование в качестве имен
существительных во множественном числе не несет никакой дополнительной ин-
формации. Иногда существительное в единственном числе не отражает истинного
предназначения класса. В подобных ситуациях допустимо использование существи-
тельных во множественном числе (например, Rentalconditions (Условия проката)
в примере 4.2).
Имя класса должно быть осмысленным. Оно должно отражать истинную природу класса.
Ойо должно заимствоваться из словаря пользователей (а не жаргона разработчиков).
Лучше использовать более длинные имена, чем скрывать их смысл за шифром.
Можно с уверенностью сказать, что имена длиной более тридцати символов слишком
громоздки (а некоторые программные среды их просто не воспринимают, если CASE-
154 Глава 4. Спецификация требований
средства работают с именами классов, а не кодами классов). Возможно также исполь-
зование более длинных описательных имен в дополнение к именам и кодам классов.
4.2.1.2-2. Выявление и спецификация атрибутов классов
Графическая пиктограмма, представляющая класс, состоит из трех отделений
(имя класса, атрибуты, операции) (разд. 2.1.2). Спецификация атрибутов классов
принадлежит к спецификации состояний и рассматривается в этом разделе. Специфи-
кация операций рассматривается позже в этой главе в разделе, посвященном специфи-
кации поведения (разд. 4.3).
Выделение атрибутов осуществляется параллельно с выделением классов. Иден-
тификация атрибутов своего рода “побочный эффект” установления классов. Это не
означает, что выявление атрибутов — простая задача. Напротив, это процесс, тре-
бующий значительных усилий и многократных итераций.
Исходные модели спецификации определяют только атрибуты, являющиеся сущест-
венными для понимания состояний, в которых могут находиться объекты класса. Ос-
тальные атрибуты можно до поры до времени игнорировать (однако аналитик должен
быть уверен в том, что установленная, но проигнорированная на определенном этапе
информация не будет по ошибке утеряна и будет зафиксирована впоследствии). Мало-
вероятно, чтобы все атрибуты класса были приведены в документе описания требова-
ний, однако важно не включать в спецификацию те атрибуты, которые не вытекают из
требований. В последующих итерациях можно добавить больше атрибутов.
Для имен атрибутов мы рекомендуем придерживаться простого соглашения: в
именах атрибутов использовать только строчные буквы, а слова в составных именах от-
делять подчеркиванием.
4.2.1.2.3. Примеры спецификации классов
' Пример4.4. Запись науниверситетскиекурсы
1 Обратитесь к примеру 4.1 и рассмотрите следующие дополнительные требования, из-
воженные в документе описания требований.
I 1. Выбор студентами учебных курсов может быть ограничен из-за конфликтов распи-
сания, а также за счет ограничения на количество студентов, которое может быть
f набрано на текущий предлгаемый курс.
t 2. Предлагаемая студентом программа обучения вводится в интерактивную систему записи
! на курсы. Система проверяет программу на непротиворечивость и сообщает о любых
‘ проблемах. Проблемы требуется решать при помощи научного руководителя. Оконча-
; тельная программа является предметом научного согласования со стороны представите-
I ля заведующего кафедрой, а затем направляется секретарю учебного заведения.
В первом утверждении упоминаются конфликты расписания, однако мы не знаем дос-
товерно, как следует моделировать эту проблему. Возможно, что речь здесь идет о преце-
денте, который процедурно определяет конфликты расписания. Вторую часть этой же
формулировки можно смоделировать за счет ведения атрибута enrolment_quota (квота
набора) в класс Courseoffering. Теперь также ясно, что класс должен обладать атрибу-
тами year (год) и semester (семестр).
Вторая формулировка укрепляет нас во мнении о необходимости введения класса
StudyProgram. Можно видеть, что класс StudyProgram сочетает в себе ряд дисцпп-
4.2. Спецификации состояний 155
лин, предлагаемых к изучению в текущий момент. Поэтому класс Studyprogram так-
же должен обладать атрибутами year и semester.
Ближайшее рассмотрение нечетких классов CompulsoryCourse и
ElectiveCourse приводит нас к выводу, что учебный курс является обязательным
или выборочным относительно определенной ученой степени. Один и тот же курс мо-
жет быть обязательным по отношению к одной степени, выборочным, что касается
другой, и вообще не допустимым применительно к некоторым другим степеням. Раз
так, то CompulsoryCourse и ElectiveCourse не являются классами в полном смыс-
ле слова. (Заметим, что здесь мы не затрагиваем область моделирования классов с ис-
пользованием обобщения (разд. 2.1.5) — моделирование обобщения рассматривается
в разделе 4.2.4.)
На рис. 4.1 представлена модель классов, соответствующая проведенным нами
рассуждениям. Кроме того, на рисунке используются символы {стереотипы {stereotype))
«РК>> и <<СК>> для обозначения первичных ключей и потенциальных ключей, со-
ответственно (разд. 8.4.1.2). Это уникальные идентификаторы объектов для рассмот-
ренных классов. Здесь же заданы типы данных для атрибутов.
Классы StudyProgram и Courseoffering не имеют пока идентифицирующих
атрибутов. Они будут введены в эти классы после установления ассоциативных связей
между классами (разд. 2.1.3 и 4.2.2).
jn-, 1 , "X" .... ~ . "" “............. ‘ "•’* »
О Пример 4.5. Магазин видеопроката i
Обратитесь к примеру 4.2. Предположим, что мы прояснили требование 3 об условиях (
прокате. Ниже приведен перечень дополнительных требований.
. 1. Плата за прокат отличается в зависимости от видеоносителя: кассета или диск !
(однако для двух типов кассет — Beta и VHS — она одинакова). |
2. Хотя магазин держит в запасе видеодиски только одного формата — DVD, пользова- ;
тели желали бы расширить в будущем систему проката и на другие форматы дисков. i
3. Работники видеомагазина стремятся запомнить коды наиболее популярных лент, [
Зачастую при идентификации фильма они используют именно код фильма, а не его j
название. Это полезная практика, поскольку фильм с одним названием мог выпус- ;
каться разными режиссерами.
Первое утверждение разъясняет, что условия проката отличаются для кассеты
(VideoTape) и диска (VideoDisk), содержащих один и тот же фильм. Поэтому имеет
смысл ввести отдельный класс Rentalconditions (который должен ассоциировать-
ся с классами VideoTape и VideoDisk).
Из формулировки второго требования вытекает необходимость сосуществования
обоих классов: VideoDisk и DVDDisk. Иерархия обобщения с корнем VideoMedium
теперь становится довольно очевидной, однако мы откладываем обсуждение отноше-
ния обобщения до раздела 4.2.4.
На основании анализа третьего предложения мы вводим в класс MovieTitle ат-
рибуты кода фильма movie_code (в качестве ключевого атрибута) и режиссера —
director. Остальные атрибуты были рассмотрены в примере 4.2.
Па рис. 4.2 показана модель классов для приложения Магазин видеопроката, по-
строенная в результате обсуждения требований примеров 4.2 и 4.3. Атрибут
VideoMedium. number_currently_available является атрибутом с областью дейст-
вия-класс {статическим атрибутом) (разд. 2.1.6). Атрибут MovieTitle. is_in_stock,
отражающий наличие в запасе фильма с данным названием, является производным
156 Глава 4. Спецификация требований
(derived) атрибутом, т.е. он может быть вычислен на основе имеющегося в наличии те-
кущего количества фильмов — VideoMedium. number_currently_available.
__________Degree__________
«РК» degree_name: String
total credit points: Integer
__________Course___________
«РК» course_code: String
«СК» course_name: String
credit points: Integer
StudyProgram
year: Date
semester: Integer
________Student__________
«РК» studentjd: String
student name: String
Courseoffering
year: Date
semester: Integer
enrolment quota: Integer
Рис. 4.1. Спецификация классов (Запись на университетские курсы)
_________MovieTitle__________
«РК» movie_code: String
movie_title: String
director: String
/ isJn stock: Boolean
_____________VideoMedium_______________
video_condition: Byte
$ percentage excellent condition: Decimal
VideoTape
Video Disk
__________RentalConditions
rental_period_in_days: Integer;
rental charge per period: Currency
BetaTape
VHSTape
DVDDisk
Puc. 4.2. Спецификация классов (Магазин видеопроката)
Анализ первого утверждения говорит нам о том, что понятие наличного клиента вы-
водится на основе ассоциации между классами Organization и Contract. Эта ассо-
циативная связь может быть довольно динамичной. Следовательно, нужда в классах
CurrentOrg и ProspectiveOrg отпадает. Более того, наша система не касается управ-
ления контрактами и не отвечает за поддержку класса Contract. Лучший вариант, ко-
торый просматривается в данном случае — смоделировать решение с помощью произ-
водного атрибута Organization. is_current. который обозначает наличную органи-
зацию и при необходимости может изменяться подсистемой управления контрактами.
4.2. Спецификации состояний 157
Второе утверждение наводит на мысль о необходимости введения двух классов для
адресов: PostalAddress и CourierAddress.
Оставшиеся формулировки требований дают дополнительную информацию о со-
держании атрибутов классов. Кроме того, здесь можно высказать несколько сообра-
жений, связанных с ассоциативными отношениями и ограничениями целостности
(они будут рассмотрены позже).
F"? Пример 1 I
: Обратитесь к примеру 4.3 и рассмотрите следующую дополнительную информацию. I
1. Клиент рассматривается как наличный, если существует контракт с этим клиентом \
на поставку наших товаров или услуг. Однако, функции управления контрактами вы- <
ходят за рамки нашей системы.
2. Система позволяет вырабатывать различные отчеты по нашим контактам на основе поч- :
тового и курьерского адресов (напрймер, находить всех клиентов по почтовому коду). i
3. Дата и время создания задания фиксируются. Можно также сохранить значение !
“дохода", ожидаемого от осуществления задания. »
4. Мероприятия для сотрудника отображаются на экране его компьютера в виде стра- :
ницы календаря (один день на страницу). Приоритет каждого мероприятия (низкий, ;
средний, высокий) визуально выделяется на экране. \
5. Не со всеми мероприятиями связвно понятие “срок исполнения" — некоторые из
них являются “бессрочными” (они могут выполняться в любое время в течение дня, •
на который они запланированы).
6. Время создания мероприятия не может изменяться, а срок исполнения — может.
7. По завершении мероприятия дата и время его завершения фиксируются.
8. Система также хранит отличительные признаки для сотрудников, которые создают
задания и мероприятия, которым запланировано осуществление мероприятия (
(“поручено сотруднику”) и которые завершили мероприятие.
Спецификация классов для приложения Управление контактами с клиентами пред-
ставлена на рис. 4.3. Как видно из рисунка, отношения между классами в модели от-
сутствуют. Поэтому, к примеру, восьмое утверждение, которое связывает сотрудников
с заданиями и мероприятиями, не нашло отражения в модели.
Первая формулировка позволяет нам установить несколько атрибутов класса
Campaign. Класс Campaign содержит следующие атрибуты campaign_code (код кам-
пании) (первичный ключ), campaign_title (название кампании), date_start (дата
начала) и date closed (дата закрытия).
Последнее предложение утверждения 1 касается призов кампании. При его бли-
жайшем рассмотрении можно прийти к выводу о том, что Prize (Приз) — самостоя-
тельный класс: приз разыгрывается, ему присуще такое свойство как победитель, и он
должен обладать другими явно не выраженными свойствами, такими как описание,
ценность и место в ряду других призов кампании.
Мы вводим класс Prize в модель классов вместе с атрибутами, о которых говорилось
выше: prize_descr, prize_value и prize_ranking. Мы замечаем, что дата розы-
грыша призов совпадает для всех призов кампании. Мы вводим атрибут даты розыгры-
ша date drawn в класс Campaign. Приз выигрывает благотворитель. Мы можем зафик-
сировать этот факт позже в связи с введением ассоциации классов Prize и Supporter.
Формулировка 2 гласит, что у каждого билета есть номер, однако этот номер не
уникален среди всех билетов (он уникален только в рамках кампании). Мы вводим ат-
158 Глава 4. Спецификация требований
рибут ticket_number, однако, не придаем ему статус первичного ключа для класса
CampaignTicket. Два других атрибута CampaignTicket представляют цену билета
(ticket_value) и статус билета (ticket_status). Общее количество билетов и ко-
личество проданных билетов— атрибуты класса Campaign (num_tickets и
num_tickets_sold).
m&cj .-як*;»
Обратитесь к разделу 2.3.4 (Постановка задачи 4) и к разделу 3.5, в котором представ-
лены бизнес-модель требований для приложения Телемаркетинг. Рассмотрите, в част-
ности, диаграмму бизнес-классов на рис. 3.6 (разд. 3.5.3.1). Примите к сведению сле-
дующую дополнительную информацию.
’ 1. Каждая кампания имеет свое название, которое, как правило, используется при ее
[ упоминании. Кроме того, кампания обладает уникальным внутренним кодом для
; внутренних ссылок. Каждая кампания проводится в течение заданного периода вре-
} мени. Вскоре после закрытия кампании проводится розыгрыш призов и объявляют-
j ся владельцы выигрышных билетов.
2. Все билеты пронумерованы. В рамках кампании все билеты обладают уникальными
> номерами. Общее количество билетов, выпущенных для кампании, количество биле-
> тов, проданных до настоящего времени, и текущее состояние каждого билета из-
вестны (например, “наличный”, “заказан", “оплачен", “выигрышный”).
; 3. Для установления производительности телемаркетеров благотворительного обще-
{ ства фиксируется продолжительность звонков и успешные результаты звонков (т.е.
звонков, завершившихся заказом билетов).
; 4. В системе ведется обширная информационная база, касающаяся благотворителей.
Помимо обычных деталей, относящихся к контактам (адрес, телефонный номер и
; т.д.) эта информация включает исторические подробности, такие как дата первого и
{ последнего участия благотворителя в кампаниях вместе с общим количеством кам-
паний, в которых они участвовали. В системе также хранятся данные обо всех из-
вестных предпочтениях и ограничениях, связанных с благотворителем (например,
/ таких как нежелательное время для звонков и обычно используемая им при покупке
। билетов кредитная карточка).
। 5. Телемаркетинговые звонки должны обрабатываться в соответствии с определенны-
t ми приоритетами. Звонки, на которые не получен ответ или зафиксирован ответ ав-
\ тоответчика, требуется перепланировать, чтобы попробовать дозвониться позже.
J Важно изменять время повторных попыток дозвониться.
I 6. Можно пытаться дозвониться снова и снова до тех пор, пока не будет исчерпан ли-
I мит попыток. Этот лимит может отличаться для различных типов звонков. Нвпример,
> лимит для обычного “звонка-приглашения” может отличаться от лимите для “звонка-
! напоминания" благотворителю о невыполненном платеже.
| 7. Возможные результаты звонков классифицируются, чтобы облегчить ввод данных в
f систему телемаркетерами. Типичными видами результата являются: “успех" (т.е.
; билеты заказаны), “неудача", “перезвонить позже", “нет ответа", “занято”,
{ “автоответчик", “факс”, “неверный номер”, “разъединение".
Утверждение 3 обнаруживает несколько открытых вопросов. Какие структуры дан-
ных требуются нам для расчета продуктивности телемаркетеров? Чтобы ответить на
этот вопрос нам требуется определить некоторые показатели, с помощью которых
можно выразить продуктивность. Один из возможных вариантов состоит в том, чтобы
подсчитывать среднее количество звонков в час и среднее количество успешных звон-
ков в час. Затем можно вычислить показатель продуктивности, разделив количество ус-
4.2. Спецификации состояний 159
пешных звонков на общее количество звонков. Теперь введем в класс Telemarketer
соответствующие атрибуты: average_per_hour и success_per_hour.
PostalAddress
street: String
pojxx: String
city: String
state: String
post_code: String
country: String
CourierAddress________
street_and_directions: String
city: String
state: String
country: String
__________Organization__________
«РК» organizationjd: Integer
organization_name: String
phone: String
fax: String
email: String
is current: Boolean
_________Contact__________
«РК» contactJd: Integer
family_name: String
first_name: String
phone: String
fax: String
email: String
Task
description: String
createddt: Date
value: Currency
______Event_______
description: String
created dt: Date
duedt: Date
completed_dt: Date
priority: Byte
_________Employee__________
«РК» employeejd: String
family_name: String
first_name: String
middle name: String
Рис. 4.3. Спецификация классов (Управление контактами с клиентами)
Для вычисления показателей продуктивности телемаркетера необходимо запоми-
нать продолжительность каждого звонка. Хранилищем для этой информации служит
класс CallOutcome (Результат звонка). В этот класс мы вводим атрибуты для начала и
закрытия кампании: start_time и end_time. Мы предполагаем, что результат каж-
дого звонка связан телемаркетером посредством ассоциации.
Результатом анализа утверждения 4 является включение ряда атрибутов в класс
Supporter. Вот эти атрибуты: supporter_id (первичный ключ),. supporter_name,
phone_number, mailing_address, date_first, date_last, campaign_count,
preferred hours и credit_card_attributes. Некоторые из этих атрибутов
(mailing address, preferred_hours) достаточно сложны для того, чтобы превра-
тить их в дополнительные классы позже в процессе разработки. Пока же мы храним их
как атрибуты.
Утверждение 5 касается класса CallScheduled (Запланированный звонок). Мы
вводим в него атрибуты phone_number, priority и attempt_number. У нас нет пол-
ного понимания того, как поддерживать требование о том, что последующие звонки
должны производится в разное время дня. Очевидно, что это должно быть возложено
160 Глава 4. Спецификация требований
на алгоритм планирования, однако нам потребуется поддержка структур данных. К сча-
стью, некоторый свет на эту проблему проливает следующая формулировка.
Результатом анализа утверждения 6 является введение класса CallType (Тип звон-
ка). Этот класс содержит следующие атрибуты: type_descr, call_attempt_limit, а
также alternate_hours. Последний атрибут — это сложная структура данных, анало-
гичная атрибуту preferred_hours класса Supporter, которая в конце концов станет
отдельным классом.
Последнее утверждение классифицирует результаты звонков. Это прямое указание
на необходимость введения соответствующего класса — OutcomeType. Возможные типы
результата могут храниться в атрибуте outcome_type_descr. Не ясно, какие еще атри-
буты можно включить в OutcomeType, однако мы убеждены, что по мере изучения де-
тализированных требований, эти атрибуты будут установлены. Одним из них может
быть атрибут follow_up_action, назначение которого — хранить информацию о ти-
пичных последующих шагах применительно к каждому типу результата.
На рис. 4.4 представлена модель классов, завершающая приведенные выше рассу-
ждения. Ассоциативные отношения, уже установленные в модели бизнес-классов
(рис. 3.6), сохранены. Новые ассоциации не введены.
Рис. 4.4. Спецификация классов (Телемаркетинг)
4.2.2. Моделирование ассоциации
Ассоциации служат объединению объектов в системе. Они- способствуют взаимо-
действию между объектами. Без ассоциаций объекты могут устанавливать связь толь-
ко во время прогона программы, если они совместно используют одни и те же атрибу-
4.2. Спецификации состояний 161
ты или они имеют доступ (с помощью других средств, таких как глобальные перемен-
ные) к идентифицирующим объекты значениям других объектов.
Ассоциации представляют собой наиболее существенный вид отношений моделей,
в частности, моделей постоянных “бизнес-объектов”. Ассоциации поддерживают вы-
полнение прецедентов и, таким образом, обеспечивают совмещение спецификации
состояний и поведения.
4.2.2.1. Выявление ассоциаций
Нахождение основных ассоциаций представляет собой побочный эффект процес-
са выявления классов. При определении классов аналитик принимает решение об ат-
рибутах классов, и некоторые из этих атрибутов являются ассоциациями с другими
классами. Атрибуты могут относиться к элементарным типам данных либо могут вво-
диться в качестве других классов, устанавливая таким образом отношения с другими
классами. По существу, любой атрибут, относящийся к неэлементарным типам данных,
должен моделироваться как ассоциация (или агрегация) по классу, представляющему
этот тип данных.
Выполнение пробного прогона прецедентов позволяет выявить остающиеся ассоциа-
ции. Устанавливаются пути взаимодействия между классами, необходимые для прогона
прецедентов. Обычно ассоциации должны поддерживать эти пути взаимодействия.
Каждая тернарная ассоциация должна быть заменена циклом или бинарной ассоциа-
цией. Тернарные ассоциации привносят риск неверного семантического истолкования.
Иногда для того, чтобы полностью выразить базовую семантику, циклы, образуемые
ассоциациями, не должны коммутировать (быть замкнутыми) [51]. Это значит, что по
меньшей мере одна из ассоциаций в цикле может быть производной (derived). Подобная
ассоциация является избыточной в семантическом смысле и должна быть исключена
(хорошая семантическая модель должна быть лишена избыточности). Вполне допус-
тимо, что многие производные ассоциации, тем не менее, все же войдут в проектную
модель (например, из соображений эффективности).
4.2.2.2. Спецификация ассоциаций
Спецификация ассоциаций подразумевает выполнение следующих действий.
1. Присваивание имен ассоциациям.
2. Присваивание имен ассоциативным ролям.
3. Установление кратности ассоциации (разд. 2.1.3.2).
Правила именования ассоциаций должны соответствовать соглашениям по име-
нованию атрибутов — имена ассоциаций состоят из строчных букв, отдельные слова в
имени ассоциации разделяются подчеркиванием (разд. 4.2.1.2.2).
Если два класса связаны только одним ассоциативным отношением, задавать имя
ассоциации и ассоциативные ролевые имена между этими классами необязательно
(разд. 2.1.2.1.1). CASE-средства могут внутренне различать каждую ассоциацию через
системные идентификационные имена.
Ролевые имена можно использовать для раскрытия более сложных ассоциаций, в ча-
стности самоассоциативных отношений (self associations) (рекурсивных ассоциаций, кото-
рые связывают объекты одного и того же класса). При задании ролевых имен их сле-
дует выбирать с учетом того, что в проектной модели они станут атрибутами классов,
расположенных на противоположных концах ассоциативной связи.
162 Глава 4. Спецификация требований
Кратность должна быть задана для обоих концов (ролей) ассоциации. Если вопрос
кратности на этом этапе не ясен, нижняя и верхняя границы кратности можно опустить.
4.2.2.3. Пример спецификации ассоциации
Модель ассоциаций для приложения Управление контактами с клиентами показана
на рис. 4.5. Чтобы продемонстрировать гибкость ассоциативного моделирования,
имена ассоциаций и ролевые имена используются бессистемно.
0..1
0..1
PostalAddress
street: String
po_box: String
city: String
state: String
post_code: String
country: String
_________Organization
«РК» organizationjd: Integer
organization name: String
phone: String
fax: String
email: String
is current: Boolean
0..1
0..1
0..1
contact
theOrganization
1
org_con
CourierAddress_______
streeVand_directions: String
city: String
state: String
country: String____________
0..1______________
Contact___________
«РК» contactJd : Integer
family_name: String
firsbname: String
phone: String
fax: String
email: String
1 theOrganization
contact
Puc. 4.5. Спецификация ассоциаций (Управление контактами с клиентами)
2I
Обратитесь к примерам 4.3 и 4.6. Требования, приведенные в этих примерах, позволя- j
ют нам выявить и специфицировать ассоциации на классах для системы Управление t
контактами с клиентами. j
4.2. Спецификации состояний 163
Кратность всех ассоциаций между классами PostalAddress и CourierAddress с
эдной стороны и классами Organization и Contact с другой равна “ноль или один”.
Дадим пояснения к использованию ассоциации между классами Organization и
PostalAddress).
На одном конце ассоциации объект Organization связан максимум с одним объек-
том PostalAddress, но только в том случае, если почтовый адрес организации извес-
тен. На противоположном конце ассоциации конкретный объект PostalAddress свя-
зан с объектом Organization или объектом Contact. Следовательно, чтобы удовле-
гворять этим ограничениям, кратность должна быть равна “ноль или один”. (Даже при
>тих условиях, само ограничение необходимо отдельно зафиксировать документально с
помощью средств моделирования ограничений языка UML (разд. 5.1.2)).
Ассоциация между классами Organization и Contact демонстрирует использо-
зание как имен ассоциаций, так и ролевых имен. Ролевые имена преобразуются в
имена атрибутов модели реализации приложения Управление контактами с клиентами.
Модель реализации содержит следующие атрибуты: Organization. contact и
Contact.theOrganization. Префикс ‘ЧЬе”означает, что роль theOrganization
имеет кратность точно равную “один”. (Артикль “the” употребляется в английском
изыке для указания на определенный, конкретный объект. Прим. ред.). Кратность ро-
1и contact равна “много” (нижняя и верхняя границы не установлены).
Кратность роли contact между классами Task и Contact не задана. Требования не
эбъясняют, должно ли задание быть непосредственно связано с контактом. Поэтому у
час нет уверенности в том, может ли оно быть связано более, чем с одним контактом.
Наконец, существует три ассоциации между классами Event и Employee. Эти ас-
зоциации устанавливают, кто из сотрудников создает мероприятие, кто отвечает за
:го выполнение и кто, в конце концов, завершает его. Во время создания мероприя-
гия сотрудник, который работает над его завершением, неизвестен (поэтому крат-
чость на конце ассоциации completed со стороны работника равна “ноль или один”).
1.2.3. Моделирование отношений агрегации
и композиции
Агрегация и ее более строгая форма композиция служит проводником семантики
‘часть-целое” между составным (супермножество) классом и компонентным
подмножество) классом (разд. 2.1.4). В языке UML агрегация трактуется как ограни-
ченная форма ассоциации. Это колоссальное умаление роли агрегации в моделирова-
нии. Достаточно сказать, что агрегация, наряду с обобщением, является наиболее
зажным методом многократного использования функциональных возможностей в
эбъектно-ориентированных системах.
Моделирующая способность языка UML значительно усилилась, если бы язык
поддерживал четыре возможных семантики для агрегации [55].
1. Агрегация типа “Безраздельно обладает”.
2. Агрегация типа “Обладает”.
3. Агрегация типа “Включает”.
4. Агрегация типа “Участник”.
Агрегация типа Безраздельно обладает устанавливает следующее:
между компонентными классами и их составными классами установлено
отношение зависимости по существованию (следовательно, удаление составного
164 Глава 4. Спецификация требований
объекта распространяется вниз по иерархии отношения, так что связанные
компонентные объекты также удаляются);
агрегация транзитивна (если объект С1 является частью объекта Bl, а В1 является
частью А1, тогда С1 является частью А1);
агрегация асимметрична (нерефлексивна) (если объект является частью объекта А1,
то объект А1 не является частью ВГр,
агрегация стационарна (если объект В1 является частью объекта А1, то он не
может быть частью объекта Ai (i*l)).
Агрегация типа Обладает поддерживает первые три свойства агрегации типа
“Безраздельно обладает”, к которым относятся:
зависимость существований;
транзитивность;
асимметричность.
Агрегация типа Включает слабее, чем агрегация типа Обладает. Агрегация типа
Включает поддерживает следующие свойства:
транзитивность;
асимметричность.
Агрегация типа Участник обладает свойством целенаправленного группирования
независимых объектов— группирования, при котором не делается предположений
относительно свойства зависимости по существованию, транзитивности, асиммет-
ричности или стационарности. Это абстракция, посредством которой совокупность
членов-компонентов рассматривается как составной объект более высокого уровня.
Компонентный объект в агрегации типа Участник может одновременно принадле-
жать более, чем одному составному объекту (поэтому, кратность агрегации типа Участ-
ник может иметь значение “многие ко многим”).
Хотя агрегация получила признание как фундаментальная концепция моделирова-
ния, по меньшей мере, одновременно с обобщением [80], в объектно-ориентирован-
ном анализе и проектировании ей уделяется лишь незначительное внимание (за ис-
ключением областей приложений “совершенной парочки”, наподобие систем муль-
тимедиа). К счастью, эта тенденция в будущем может перемениться, благодаря вкладу
и проницательности методологов, работающих над шаблонами проектирования. Это
ясно видно, например, из трактовки агрегации (композиции) в плодотворной книге
Гамма (Gamma) и др. [28].
4.2.3.1. Выявление агрегаций и композиций
Поиск агрегаций ведется параллельно с поиском ассоциаций. Если ассоциация
проявляет одно или более из четырех семантических свойств, рассмотренных выше,
то ее можно моделировать как агрегацию.
При объяснении отношения агрегации лакмусовой бумажкой выступают фразы
“включаен? (“has”) и “является частью” (“ispart-of). При истолковании отношения свер-
ху-вниз по иерархии классов используется фраза “включает” (например, Книга
“включает” Главу). При интерпретации снизу-вверх используется фраза “является ча-
стью” (например, Глава “является частью” Книги). Если предложение, описывающее
отношение, прочитывается вслух с использованием этих фраз и оно лишено смысла
на естественном языке, то это отношение /(«является агрегацией.
4.2. Спецификации состояний 165
Со структурной точки зрения агрегация часто связывает воедино большое количе-
ство классов, тогда как ассоциация' степени выше двух бессмысленна (см. разд.
2.1.3.1). Когда требуется связать более двух классов воедино, отличным вариантом
моделирования может быть агрегация типа Участник.
4.2.3.2. Спецификация агрегаций и композиций
Язык UML обеспечивает только ограниченную поддержку агрегации. Сильная
форма агрегации называется в UML композицией. В композиции составной объект мо-
жет физически содержать компонентные объекты (семантически это отношение бе-
рется “по значению”). Компонентный объект может принадлежать только одному со-
ставному объекту. Отношение композиции языка UML в большей или меньшей сте-
пени соответствует нашим агрегациям типа Безраздельно обладает и Обладает.
Слабая форма агрегации в UML называется просто агрегацией. Это отношение се-
мантически берется “по ссылке” — составной объект физически не содержит компо-
нентный объект. Один компонентный объект может обладать несколькими ассоциа-
тивными или агрегативными связями в модели. Попросту говоря, агрегация в языке
UML соответствует нашим агрегациям типа Включает и Участник.
Сплошной ромб в языке UML представляет композицию. Пустой ромб используется
для определения агрегации. В остальном спецификация агрегации совпадает с обо-
значениями для ассоциации.
4.2.3.3. Пример спецификации агрегации и композиции
i Обратитесь к примерам 4.1 и 4.5. Рассмотрите следующие дополнительные требования.
!1’
Академическая характеристика студента должна быть доступна по требованию. Ха-
рактеристика должна включать информацию об оценках, полученных студентом по
каждому из курсов, на которые записался студент (и которые он не покинул без взы-
скания, т.е. в первые три недели с начала семестра).
За каждый курс отвечает преподаватель, однако этот курс могут вести и другие препо-
даватели. В течение разных семестров за один курс могут отвечать разные преподава-
тели; кроме того, в течение разных семестров курс могут вести разные преподаватели.
На рис. 4.6 показана модель классов, в которой выделено отношение агрегации.
Понятие “студент” (объект Student) “включает” академическую характеристику
(объект AcademicRecord)" — это описание композиции в языке UML (с семантикой
“по значению”). Каждый объект AcademicRecord физически помещен в один из объ-
ектов Student. Несмотря на существование ассоциации takes (брать [курс
обучения]) объект AcademicRecord включает атрибут course_code (код курса).
Это необходимо, поскольку ассоциация takes реализуется с помощью атрибута
takes_crsoff (“берет” дисциплину) объекта Student, введенного как коллекция
(collection), например, Set [Courseoffering]. Атрибут takes_crsoff не зависит от
информации во вложенном объекте AcademicRecord, хотя он безусловно связывает
объект Student с объектом Course.
Понятие “курс” (объект Course) включает дисциплину (объект Courseoffering)” —
это описание агрегации в языке UML (с семантикой “по ссылке”). Каждый объект
Courseoffering только логически содержится в одном из объектов Course. Объект
Courseoffering может также участвовать в других агрегациях и/или ассоциациях
(например, с объектами Student и AcademicInCharge (ответственный преподаватель)).
166 Глава 4. Спецификация требований
Рис. 4.6. Спецификация агрегаций (Запись на университетские курсы)
4.2.4. Моделирование отношений обобщения
Общие характеристики (атрибуты и операции) одного или более классов можно
погрузить в более общий класс. Это явление известно как обобщение. Отношение
обобщения соединяет родовой класс (суперкласс) с более специализированными клас-
сами (подклассы). Обобщение делает возможным наследование (многократное ис-
пользование) характеристик суперкласса подклассом. В традиционных объектно-
ориентированных системах наследование применяется к классам, а не к объектам
(наследуются типы, а не значения).
Помимо наследования обобщение преследует еще две цели [76].
1. Подставимость.
2. Полиморфизм.
В соответствии с принципом подставимости (substitutability) объект подкласса явля-
ется законным значением переменной суперкласса. Например, если переменная объ-
явлена с целью хранения объекта Fruit (Фрукт), то объект Apple (Яблоко) является
допустимым значением.
В соответствии с принципом полиморфизма (polymorphism) одна и та же операция
может иметь разные реализации в разных классах. Вызывающий объект может вы-
звать операцию, не зная и не заботясь о том, какая из реализаций операции выпол-
нится. Вызываемый объект знает, какому классу он принадлежит и выполняет свою
собственную реализацию.
Полиморфизм работает лучше в тех ситуациях, когда он идет “рука об руку” с на-
следованием. Зачастую полиморфная операция в суперклассе объявляется^ а реализа-
ция для нее в этом классе отсутствует. Это значит, что операция получила сигнатуру
(имя и список формальных аргументов), а реализация должна быть обеспечена в каж-
дом из подклассов. Подобная операция называется абстрактной.
4.2. Спецификации состояний 167
Абстрактную операцию не следует путать с абстрактным классом. Последний является
классом, у которого отсутствуют непосредственные объекты-экземпляры ( однако его под-
классы могут обладать объектами-экзеплярами). Экземпляров класса Vegetable (Овощи)
может не существовать. Непосредственными экземплярами являются только объекты
классов Potato (Картофель), Carrot (Морковь) и т.д.
Фактически, класс, обладающий абстрактной операцией, является абстрактным.
Конкретный класс, наподобие Apple, не может иметь абстрактных операций [37].
Хотя абстрактные операции вводятся на уровне спецификаций поведения, абстракт-
ные классы — это сфера спецификаций состояния.
4.2.4.1. Выявление обобщений
Многие суперклассы/подклассы аналитик отмечает еще в процессе формирова-
ния первоначального перечня классов. Многие другие обобщения можно обнаружить
при определении ассоциаций.
Различные ассоциации (даже принадлежащие одному и тому же классу) может потре-
боваться связать с классом на различных уровнях обобщения/специализации. Например,
класс Course может быть связан с классом Student (Student takes Course — студент берет
курс), кроме того, этот класс может быть связан с классом TeachingAssistant
(TeachingAssistant teaches Course — ассистент ведет курс). Дальнейший анализ может пока-
зать, что класс TeachingAssistant является подклассом Student.
При поиске отношения обобщения лакмусовой бумажкой выступают фразы
"может быть” ("сап-bd') и "это нечто epodd’ (“is-a-kind-of’). При истолковании отношения
сверху-вниз по иерархии классов используется фраза “может быть” (например,
Student “can-be” a TeachingAssistant — “студент “может быть” ассистентом”). При
интерпретацйи отношения снизу-вверх используется фраза “это нечто вроде”
(например, TeachingAssistant “is-a-kind-of’ Student — “ассистент “это нечто вроде”
студента”). Обратите внимание, что если также справедливо утверждение о том. что
“ассистент— это “TeachingAssistant “is-a-kind-of’ Teacher”, то мы установили
множественное наследование.
4.2.4.2. Спецификация обобщений
Отношение обобщения между классами показывает, что один класс совместно ис-
пользует структуру или поведение, определенные в одном или более классов. Обоб-
щение представляется в языке UML сплошной линией со стреловидным наконечником,
указывающим на суперкласс.
Полная спецификация обобщения включает несколько мощных возможностей.
Например, более подробное определение отношения может содержать квалифика-
цию доступа к нему, указания на то, предоставляет ли класс права другому классу, ре-
шая, что необходимо делать в случае множественного наследования и т.д. Эти вопросы
рассматриваются в главе 5.
4.2.4.3. Пример спецификации обобщений
На рис. 4.7 представлена расширенная модель классов для приложения Магазин ви-
деопроката. Иерархия обобщения выражает тот факт, что видеоноситель
(VideoMedium) “может быть” видеокассетой (VideoTape) или видеодиском
VideoDisk. Видеокассета (VideoTape) “может быть” кассетой типа BetaTape или
типа VHSTape. Видеодиск “может быть” диском типа DVDDisk (в настоящий момент
168 Глава 4. Спецификация требований
видеодиск “должен быть” диском DVDDisk, однако мы предполагаем, что в будущем
возможно появление новых подклассов для Vide о Dis к).
Рис. 4.7. Спецификация обобщения (Магазин видеопроката)
Обратитесь к примерам 4.1 и 4.5. Классы, обозначенные на рис. 4.2 (пример 4.5), заклю-
чают в себе иерархию обобщения с корнем в классе VideoMedium. Однако, до сих пор мы
не приступили к моделированию различий в состоянии и поведении между разными типа-
ми носителей videoMedium. Предположим, что руководству магазина видеопроката тре-
буется знать, является ли видеокассете (videoTape) новой марочной кассетой или она уже
перезаписана (этот факт можно зафиксировать с помощью атрибута is_taped_over).
Также предположим, что емкость памяти видеодиска (videoDisk) позволяет хранить не-
сколько версий одного фильма, каждая из которых отличается языком или окончанием.
Наша задача заключается в расширении модели, показанной на рис. 4.2, за счет включения в
нее отношений между классами и, в частности, спецификации отношения обобщения.
VideoMedium, VideoTape и VideoDisk — это абстрактные классы (их имена выде-
лены курсивом). Абстрактные классы не материализуют объекты. Объекты
VideoMedium материализуются с помощью классов BetaTape, VHSTape и DVDDisk.
Поэтому, например, ассоциация available (в наличии) может, фактически, связы-
вать объект MovieTitle с одним или более конкретным объектом класса
VideoMedium (т.е. с объектами BetaTape, VHSTape и/или DVDDisk).
То же самое справедливо в отношении ассоциации apply (применяются к). Однако
в случае ассоциации apply можно заметить некоторую неэффективность модели. Из
требований к приложению Магазин видеопроката нам известно, что условия проката од-
ного и того же фильма отличаются для видеокассет и видеодисков. Однако в отношении
всех видеокассет с одинаковым фильмом и всех видеодисков с одинаковым фильмом
применяются одинаковые условия проката. Это предполагает, что объект Rental
4.2. Спецификации состояний 169
Conditions лучше было бы связать в ассоциацию с конкретными объектами классов
VideoTape и VideoDisk. Пока же мы примиримся с этой неэффективностью.
4.2.5. Моделирование объектов
Моделирование касается проблем определения систем. Модель — это не действующая
система, и поэтому она не отражает объектов-экземпляров. В любом случае, количество
объектов в работающей системе может быть огромным, и представить их графически не-
возможно. Тем не менее, при моделировании классов мы часто представляем себе объек-
ты и рассматриваем трудные сценарии с использованием примеров объектов.
4.2.5.1. Спецификация объектов
Язык UML позволяет представить объекты графически (разд. 2.1.1.1). Мы можем
изобразить диаграмму объектов, чтобы проиллюстрировать сложные отношения ме-
жду классами или продемонстрировать изменения объектов со временем. Объектные
модели можно использовать для иллюстрации и исследования способа взаимодейст-
вия объектов во время прогона программной системы.
4.2.5.2. Пример спецификации объектов
На рис. 4.8 показана диаграмма объектов, соответствующая модели классов, пред-
ставленной на рис. 4.6. Из рисунка ясно, что объект-студент Student Don Donaldson
физически содержит два объекта AcademicRecord (для курсов СОМР224 и
СОМР326). К настоящему времени Don записался на два курса: СОМР225 и СОМР325.
Изучение одного из курсов СОМР325 было предложено провести во втором семестре
2000-го года. За чтение этого курса отвечал профессор Rick Richardson.
Рис. 4.8. Диаграмма объектов (Запись на университетские курсы)
-Г
i Наша задача в этом примере заключается а том, чтобы показать несколько объектов,
j представляющих классы из модели классов на рис. 4.6 (пример 4.9).
170 Глава 4. Спецификация требований
4.3. Спецификация поведения
Поведение системы — так как оно выглядит для внешнего пользователя — изобра-
жается в вид прецедентов (разд. 2.2.2). Модели прецедентов можно разрабатывать на
различных уровнях абстракции. Их можно применить к системе в целом для того,
чтобы специфицировать основные функциональные блоки разрабатываемого при-
ложения. Их также можно использовать для фиксации поведения пакетов UML, час-
тей пакетов или даже класса внутри пакета.
На этапе анализа прецеденты вбирают в себя системные требования, концентри-
руясь на том, что делает или должна делать система. На этапе проектирования пред-
ставление проектных решений в виде прецедентов можно использовать для специ-
фикации поведения системы в том виде, как оно должно быть реализовано.
Поведение системы, закрепленное с помощью прецедентов, требует осуществить
соответствующие вычисления и обеспечить взаимодействие объектов для выполне-
ния этих прецедентов. Вычисления можно смоделировать с помощью диаграмм видов
деятельности. Взаимодействие объектов можно задать с помощью диаграмм последова-
тельностей или диаграмм кооперации. (В данной главе используются только диаграм-
мы последовательностей, диаграммы кооперации используются далее в главах, по-
священных проектированию (разд. 6.2).)
Спецификация поведения позволяет взглянуть на систему с точки зрения ее функ-
ционирования. Зцесъ основная задача состоит в том, чтобы определить прецеденты для
области приложений и установить, какие классы участвуют в выполнении этих преце-
дентов. При этом необходимо идентифицировать операции классов и сообщения, пере-
даваемые между объектами. Хотя взаимодействие объектов инициирует изменения
состояния объектов, спецификации поведения дают функциональный взгляд на застыв-
шее состояние системы. Изменения в состоянии объектов явным образом находят вы-
ражение в спецификациях изменения состояний.
Модели прецедентов должны нарабатываться итеративно и параллельно с моде-
лями классов. Классы, введенные в спецификации состояний, подлежат дальнейшей
детальной проработке, при этом обозначаются наиболее важные операции. Следует,
однако, напомнить, что спецификация состояний определяет только классы сущностей
(“биз1 iec-объектов”).
По мере создания моделей поведения появляются еще два уровня классов.
1. Классы, которые обслуживают события, инициируемые пользователями, и
представляют бизнес-процессы (управляющиеклассы).
2. Классы, представляющие GUI-интерфейсы (пограничныеклассы) (разд. 5.2.4).
4.3.1. Моделирование прецедентов
Моделирование прецедентов тесно связано с установлением требований (см. гла-
ву 3). Требования, изложенные в текстовом виде в документе описания требований,
необходимо довести до прецедентов, зафиксированных в документе спецификации
требований. Если остальной процесс разработки направляется прецедентами, то
процесс называется проблемно-ориентированным (разд. 4.2.1.1.3).
Подобно моделированию классов моделирование прецедентов существенно ите-
ративный и наращиваемый процесс. Первоначальную диаграмму прецедентов можно
определить на основе требований верхнего уровня. Это может быть модель бизнес-
4.8. Спецификация поведения 171
прецедентов (разд. 3.5.2). Для дальнейшего уточнения прецедентов следует руково-
дствоваться более детализированными требованиями. Если в течение ЖЦ разработки
требования пользователей подвергаются изменениям, эти изменения следует отра-
зить сперва в документе описания требований, а уже затем — в модели прецедентов.
Затем изменения в прецедентах доводятся до других моделей [37], [69].
4.3.1.1. Выявление прецедентов
При выявлении прецедентов аналитик должен убедиться в том, что он твердо
придерживается сущности концепции прецедентов. Прецеденты представляют сле-
дующие компоненты общей модели системы [37], [47], [66], [76].
1. Завершенный фрагмент функциональных возможностей (включая основной) поток
логики управления, его любые вариации (подпотоки) и исключительные усло-
вия (альтернативные потоки)). '
2. Фрагмент внешне наблюдаемых функций (отличных от внутренних фунций).
3. Ортогональный фрагмент функциональных возможностей (прецеденты могут
при выполнении совместно использовать объекты, но выполнение каждого
прецедента независимо от других прецедентов).
4. Фрагмент функциональных возможностей, инициируемый субъектом (будучи
инициирован, прецедент может взаимодействовать с другими субъектами).
При этом возможно, что субъект окажется только на принимающем конце пре-
цедента (может быть, опосредовано), инициированного другим субъектом.
5. Фрагмент функциональных возможностей, который предоставляет субъекту
ощутимый полезный результат (и этот полезный результат достигается в преде-
лах одного прецедента).
Выявление прецедентов основано на анализе следующих источников информации.
1. Требования, определенные в документе описания требований.
2. Субъектов и их целей применительно к системе.
Вопросы управления требованиями рассматривались в разделе 3.4. Напомним
только, что требования представляются в отпечатанном виде. При поиске прецеден-
тов нас интересуют только функциональные требования.
Прецеденты можно определить на основе анализа задач, выполняемых субъектами.
Джекобсон (Jacobson) [39] предлагает ответить на ряд вопросов, касающихся субъектов.
Ответы на эти вопросы могут позволить обозначить прецеденты. Вот эти вопросы.
Каковы основные задачи, выполняемые каждым субъектом?
Должен ли субъект получать доступ к информации в системе или модифицировать
информацию?
Должен ли субъект информировать систему о любых изменениях в других системах?
Должен ли субъект быть проинформирован р непредвиденных изменениях в системе?
В ходе анализа прецеденты обращаются к личностным потребностям субъектов. В
некотором роде это прецеденты субъектов. Поскольку прецеденты определяют основ-
ные строительные блоки для системы, то существует необходимость в выделении сис-
темных прецедентов. Системные прецеденты извлекают все то общее, что присутствует
в прецедентах субъектов и дают возможность разработать общее решение, примени-
172 Глава 4. Спецификация требований
мое (через механизм наследования) к области прецедентов субъектов. “Субъектом”
системного прецедента является разработчик/программист, а не пользователь. Сис-
темные прецеденты идентифицируются на этапе проектирования.
4.3.1.2. Спецификация прецедентов
Спецификация прецедентов включает графическое представление субъектов,
прецедентов и четырех типов отношений, перечисленных ниже [24], [76].
1. Ассоциация.
2. Включение.
3. Расширение.
4. Обобщение прецедента.
Отношение аатрипрм устанавливает каналы связи между субъектом и прецедентом. В
качестве стереотипов для отношений “включает’ (include) и “расширяет (extend) использу-
ются слова «include» и «extend». Отношение обобщения позволяет специализиро-
вать прецедент посредством изменения любого из аспектов базового прецедента.
Отношение включения «include» позволяет вынести общее поведение за пределы
включаемого прецедента. (Это отношение пришло на смену широко применяемой в более
ранних версиях UML концепции отношения «uses» (использует)). Отношение
«extend» обеспечивает контролируемую форму расширения поведения прецедента с
помощью активизации другого прецедента в определенных точках расширения. Отноше-
ние «include» отличается от отношения «extend» в том, что “включаемый” преце-
дент является необходимым для завершения “активизирующего” прецедента.
На практике, проект может легко столкнуться с проблемами, если прилагать
слишком большие усилия для выявления отношений между прецедентами и установ-
ления, какие отношения применимы к определенной паре прецедентов. Кроме того,
обобщенные прецеденты имеют тенденцию к таким тесным связям, что взаимосвязи
станут превалировать и загромождать диаграмму, смещая акценты с надлежащей
идентификации прецедентов в сторону отношений между прецедентами.
4.3.1.3. Пример спецификации прецедентов
Обратитесь к постановке задачи для системы Запись на университетские курсы, приве- J
денной в разделе 2.3.1, а также к требованиям, определенным в примерах 4.1 и 4.4 раз-
дела 4.2.1. Наша задача состоит в том, чтобы установить прецеденты на основе анализа |
функциональных требований.
На рис. 4.9 показана обобщенная диаграмма прецедентов для приложения Запись
на университетские курсы. Модель содержит четыре субъекта и четыре прецедента. Ка-
ждый прецедент инициируется субъектом и является завершенным, внешне видимым
и ортогональным фрагментом функциональных возможностей. Все субъекты, за ис-
ключением субъекта Student, представляют собой инициирующих субъектов. Субъект
Student получает результаты экзаменов и инструкции по записи на учебные курсы
перед тем, как программа обучения в следующем семестре (учебном периоде) может
быть введена и проверена.
4.3. Спецификация поведения 173
Прецедент Provide Examination Results (Предоставить результаты экзаменов)
может “расширить” («extend») прецедент Provide Enrolment Instructions
(Предоставить инструкции по записи). Первый прецедент не всегда расширяет послед-
ний прецедент. Например, для новых студентов результаты экзаменов неизвестны. Вот
почему отношение моделируется с использованием стереотипа расширения
(«extend»), а не включения («include»).
Отношение «include» было установлено от прецедента Enter Program of
Study (Ввести программу обучения) к прецеденту Validate Program of Study
(Проверить программу обучения). Отношение «include» означает, что первый из
прецедентов всегда включает последний. Как только программа изучения введена, она
проверяется на предмет конфликтов расписания, специальных согласований и т.д.
Рис. 4.9. Диаграмма прецедентов (Запись на университетские курсы)
>
s Обратитесь к постановке задачи для системы Управление контактами с клиентами, при-
' веденной а разделе 2.3.3, а также к требованиям, определенным в примерах 4.3 и 4.6
4 раздела 4.2.1. Наша задача состоит в том, чтобы установить прецеденты на основе ана-
j лиза функциональных требований.
174 Глава 4. Спецификация требований
На диаграмме прецедентов для приложения Управление контактами с клиентами
представлены три субъекта и пять прецедентов (рис. 4.10). Эта модель обладает инте-
ресной особенностью: субъекты связаны отношением обобщения. Менеджер по об-
служиванию клиентов (Customer Services Manager) — “это нечто вродё' сотрудни-
ка по обслуживанию клиентов (Customer Services Employee), который в свою
очередь “нечто вродё1 сотрудника (Employee). Обобщающая иерархия делает диа-
грамму более выразительной. Любое мероприятие, выполненное сотрудником, может
также выполнить сотрудник по обслуживанию клиентов или менеджер по обслужива-
нию клиентов. Следовательно, менеджер по обслуживанию клиентов неявно входит в
ассоциацию (и может инициировать) любой прецедент.
Прецедент создания задания (Create Task) “включает” прецедент планирования
события (Schedule Event), как следствие того требования, что задание нельзя соз-
дать, не запланировав первое мероприятие. Отношение “расширяет” обозначает тот
факт, что завершение мероприятия может инициировать изменения деталей, связан-
ных с организацией или контактом.
Рис. 4.10. Диаграмма прецедентов (Управление контактами с клиентами)
5 Пример4.14. Магазинвидеопрбмта* т-;№. А J
мкл
: Обратитесь к постановке задачи для системы Магазин видеопроката, приведенной в ;
разделе 2.3.2, а также к требованиям, определенным в примерах 4.2 и 4.5 раздела 4.2.1. |
Наша задача состоит в том, чтобы установить прецеденты на основе анализа функцио- j
нальных требований. j
Для одного из прецедентов напишите неформальную спецификацию, включающую еле- \
дующие разделы: “Резюме", “Субъекты”, “Предпосылки", “Описание", “Исключения" \
и “Постусловия”. :
: 4.3. Спецификация поведения 175
На диаграмме прецедентов для приложения Магазин видеопроката представлены
только два субъекта и шесть прецедентов (рис. 4.11). Второстепенные субъекты, на-
подобие клиента (Customer) или поставщика (Supplier), не показаны. Эти субъекты
не инициируют ни одного прецедента. Все прецеденты инициирует работник
(Employee). Между субъектами Scanning Device (устройство сканирования) уста-
новлено отношение “зависимости" (dependency), которому аналитик присвоил стерео-
тип в виде фразы «depends on» (зависитот).
Табл. 4.4 является иллюстрацией того факта, что графическое представление преце-
дентов являет собой лишь один из аспектов полной модели прецедентов. Каждый пре-
цедент диаграммы в дальнейшем должен быть задокументирован в репозитории CASE-
средства. В частности, необходимо текстовое описание. В табл. 4.4 используется одна
популярная структура для описательной спецификации прецедентов (разд. 2.2.2.4).
Таблица 4.4. Описательная спецификация прецедента “Прокат видео”
(Магазин видеопроката)
Прецеденты Прокат видео
Краткое описание Клиент желает взять иа прокат видеокассету или диск, которые снимаются с полки магазина или были предварительно зарезер- вированы клиентом. Прц условии,, что у клиента нет неоплачен- ных счетов, сразу после внесения платы кассета выдается напро- кат." Если кдссета не возврахцаеТ|Ся.вовремя, клиенту отправляется напоминание о просроченном возврате.
Субъекты Employee (Сотрудник), Scanning Device (устройство сканирования)
176 Глава 4. Спецификация требований
Окончание табл. 4.4
Прецеденты Прокат видео
Предпосылки В наличии имеются видеокассеты или диски, которые можно взять напрокат. У клиентов есть клубные карточки. Устройство сканирования работает правильно. Работники за прилавком . знают, как обращаться с системой.
Основной поток Клиент может спросить работника о наличии видео (включая зарезервированные видеофильмы) или может взять кассету или диск с полки. Видеоноситель и членская;карточка сканируются и работнику не сообщается никаких сведений о неплатежах или задержках, так что он не задает клиенту соответствующих во- просов. Если клиент не нарушает правил, тогда он может взять максимум до восьми видеофильмов. Однако если статус клиента определен как “ненадежный”, то его просят внести задаток за один период проката каждой кассеты или диска. После получе- ния суммы задатка информация о наличии фильмов обновляет- ся, и кассета или диск передаются клиенту вместе с чеком на прокат. Клиент расплачивается наличными с помощью кредит- ной карточки или электронного перевода. Каждая запись о прокате хранит (под учетным номером клиента) дату выдачи и срок возврата видеофильма вместе с идентификатором работ ника. Для каждого видеофильма, сданного напрокат, создается отдельная запись. Прецедент генерирует напоминание о просроченном возврате клиенту, если видеофильм не был возвращен в течение двух дней по истечении даты возврата, а Также повторное напоми- нание по истечении следующих двух дней (и в этот момент кли- ент помечается как “нарушитель”)
Альтернативные потоки У клиента нет членской карточки. В этом случае прецедент “Maintain Customer” (сопровождение клиентов) может быть ак- тивизирован для выдачи новой карточки. Попытка взять напрокат слишком много видеофильмов. Видеофильмы не выдаются из-за нарушения клиентом правил. Видеоноситель или членская карточка не могут быть отскани- рованы из-за их повреждения. Электронный перевод денег или платеж по кредитной карточке отклоняются.
Постусловия Видеофильмы сданы напрокат, и база данных соответствующим образом обновлена.
Решение для примера 4.15, приведенное на рис. 4.12, состоит из нескольких прецедентов.
Субъекты непосредственно взаимодействуют с тремя прецедентами: планирования и осуще-
ствления следующего звонка (Schedule and Make Next Call), записи результатов звонка
(Record Call Outcome) и отображения деталей звонка (Display Call Details). По-
4.3. Спецификация поведения 177
следний прецедент может быть в свою очередь “расширен” до отображения подробностей о
кампании (Display Campaign Details), отображения истории благотворителя (Display
Supporter History) и отображения подробностей о призе (Display Prize Details).
Прецедент обновления информации по благотворителю (Update Supporter) “расширяет”
Display Supporter History. Запись заказа на билет (Record Ticket Order) и плани-
рование повторного вызова (Schedule Callback) может “расширить” Record Call
Outcome. Предполагается, что субъекты могут независимо связываться с прецедентами рас-
ширения, однако каналы связи для этих прецедентов явно не показаны.
Обратитесь к постановке задачи для системы Телемаркетинг, приведенной в разделе i
2.3.4, а также к требованиям, определенным в примерах 3.1, 3.1 и 3.3, а также в приме- i
ре 4.7. Наша задача состоит в том, чтобы установить прецеденты на основе анализа ;
функциональных требований.
Update Supporter
Рис. 4.12. Диаграмма прецедентов (Магазин видеопроката)
178 Глава 4, Спецификация требований
4.3.2. Моделирование видов деятельности
Диаграммы видов деятельности были введены в язык UML сравнительно недавно
(разд. 2.2.3). Подобно традиционным потоковым диаграммам неструктурным схемам,
получившим распространение в рамках структурных методов для разработки проце-
дурно-ориентированных программ, диаграммы видов деятельности представляют По-
ток логики управления в объектно-ориентированных программах (хотя и на более
высоком уровне абстракции). Различие же заключается в возмржности представления
с помощью диаграмм видов деятельности управления параллельными потоками наряду с
последовательным управлением.
Модели видов деятельности широко используются в проектировании. Однако они также
служат в качестве отличного метода изображения вычислений или технологических про-
цессов на уровне абстракции, который подходит для анализа. Графы видов деятельности
можно использовать для демонстрации различных уровней детализации вычислений.
Модели видов деятельности могут быть особенно полезны для определения пото-
ков видов деятельности в процессе выполнения прецедентов. Поскольку модели видов
деятельности не отображают объектов, которые осуществляют деятельность, граф ви-
дов деятельности можно построить даже в том случае, когда модель классов отсутст-
вует или разрабатывается. В конце концов каждый вид деятельности определяется
одной или несколькими операциями в одном или нескольких кооперирующихся клас-
сах. Детальная проработка такой кооперации может быть осуществлена с использова-
нием диаграмм кооперации (разд. 6.2.2).
4.З.2.1. Выявление видов деятельности
Каждый прецедент можно моделировать с помощью одного или нескольких графов
видов деятельности. Событие, источником которого служит субъект инициирующий
прецедент, это то же самое событие, которое запускает выполнение графа видов дея-
тельности. Процесс выполнения последовательно переходит от одного состояния вида
деятельности к другому. Состояние вида деятельности считается завершенным, когда за-
вершается его вычисление. Внешние инициируемые событиями прерывания, которые
могут вызвать завершение состояния вида деятельности, допускаются только в исклю-
чительных случаях. Если ожидается, что подобные события могут происходить часто,
то следует вместо этого воспользоваться диаграммой состояний.
Виды деятельности лучше всего выявлять на основе анализа предложений нефор-
мальной спецификации прецедентов (табл. 4.4). Каждая , фраза, содержащая глагол,
может рассматриваться как потенциальный ВИД ^деятельности. Описание альтерна-
тивных потоков вводит в граф видов деятельности ветвление и разделение потоков.
Они приводят к исключительным (непредвиденным) состояниям деятельности. Воз-
можны также параллельные потоки управления.
4.3.2.2. Спецификация видов деятельности
После выявления состояний видов деятельности спецификация видов деятельности
выглядит как довольно простой процесс соединения этих состояний линиями переходов.
Параллельные потоки инициируются (разделяются) и сливаются, что отображается на диа-
грамме в виде жирной полосы, обозначающей синхронизацию потоков. Альтернативные по-
токи создаются (разветвляются) и объединяются, что отображается в виде ромбов ветвления.
Внешние события на графе видов деятельности обычно отсутствуют. Однако су-
ществует графический метод включения внешнйх событий в граф. Аналогично, суще-
4.3. Спецификация поведения 179
ствуют графические обозначения для состояний потоков объектов для представления
объектов, которые являются входными или выходными для вида деятельности.
4.3.2.3. Пример спецификации видов деятельности
Обратитесь к примеру 4.14 и, в частности, к неформальной спецификации прецедента (
“Rent Video" (табл. 4.4). Наша задача состоит в том, чтобы построить диаграмму видов I
деятельности для этого прецеденте. ;
Рис. 4.13. Диаграмма видов деятельности для прецедента “Rent Video”
(Магазин видеопроката)
На рис. 4.13 представлена диаграмма видов деятельности для прецедента “Rent
Video”. Нет ничего удивительного в том, что диаграмма отражает неформальную спе-
цификацию прецедента (табл. 4.4). Обработка начинается со сканирования клубной
карточки клиента или видеоносителя. Эти два вида деятельности рассматриваются
независимо друг от друга (что показано с помощью символа разделения).
180 Глава 4. Спецификация требований
4.3.3. Моделирование взаимодействий
Диаграммы последовательностей и диаграммы кооперации относятся к диаграм-
мам взаимодействия. Они отражают характер взаимодействия объектов между собой,
которое необходимо для выполнения прецедента, операции или другой поведенче-
ской компоненты.
Диаграммы последовательностей показывают обмен сообщениями между объек-
тами, упорядоченными в виде временной последовательности. Диаграммы коопера-
ции выделяют отношения между объектами, по которым происходит обмен сообще-
ниями. Мы считаем диаграммы последовательностей более полезными для анализа, а
диаграммы кооперации — для проектирования.
Поскольку’ модели взаимодействия ссылаются на объекты, они требуют, чтобы по
меньшей мере первая итерация моделирования состояний была завершена, а основ-
ные классы объектов определены. Хотя взаимодействия влияют на состояния объек-
тов, диаграммы взаимодействия не отражают в явном виде изменений состояния объ-
ектов. Это относится к области спецификации изменения состояний и диаграммам
состояний (разд. 2.2.6 и 4.4).
Диаграммы взаимодействия можно использовать для определения операций
(методов) классов (разд. 2.2.5 и 4.3.4). Любое сообщение, направляемое объекту на
диаграмме взаимодействия, должно быть обслужено некоторым методом, определен-
ным в классе этого объекта.
4.3.3.1. Выявление последовательностей сообщений
Выявление последовательностей сообщений является логическим продолжением
моделирования видов деятельности. Виды деятельности, представленные на соответ-
ствующей диаграмме, отображаются на сообщения диаграммы последовательностей.
Если уровни абстракции, используемые для построения модели видов деятельности и
модели последовательностей, совпадают, то осуществить отображение видов дея-
тельности на сообщения довольно просто.
4.3.3.2. Спецификация последовательностей сообщений
При спецификации сообщений полезно проводить различие между сообщением,
представляющим собой сигнал, и сообщением, которое являет собой вызов операции
[76]. Сигнал означает асинхронное взаимодействие объектов. Отправитель может
продолжить выполнение потока сразу после отправки сигнального сообщения. Вызов
означает синхронное обращение к операции с условием возврата управления отпра-
вителю. Возвращаемое сообщение может возвращать вызывающему объекту некото-
рые значения либо просто уведомлять его об успешном завершении операции. В по-
следнем случае, возвращаемое сообщение отображать на диаграмме последователь-
ностей не обязательно.
4.3.3.3. Пример спецификация последовательностей
Па рис. 4.14 показана диаграмма последовательностей для приведенного выше
сценария. Субъект Data Entry Person (Лицо, вводящее данные) инициирует пре-
цедент, отправляя сообщение с запросом объекту граничного класса
PrograrnEntryWindow (Окно программы ввода) для того, чтобы добавить студента
(обозначенного аргументом std) к списку записавшихся на курс (аргумент crs) в дан-
ном семестре (аргумент sem).
4.3. Спецификация поведения 181
; ииратитесь к примерам ч.э ич iz, а также к прецеденту enter rroyram от otuuy , пока-
i занному на рис. 4.9. Наша задача состоит в том, чтобы построить диаграмму последова-
’ тельностей для этого прецедента.
; Мы не касаемся здесь вопросов проверки корректности введенной программы обуче-
j ния. Проверке обязательных условий, наличия конфликтов в расписании, специальных
I разрешений посвящен другой прецедент (“Validate Program of Study”). Наша задача со-
[ стоит только в том, чтобы проверить, действительно ли в текущем семестре предлага-
I ется курс, на который желает записаться студент, и открыта ли еще на него запись (есть
j ли свободные места).
: Data Entry
Person
: Program
EntryWindow
aStudent:
Student
aCourse:
Course
aCourseOffering:
Courseoffering
Л add(std,crs,sem)'
’ 'с
areYouValid(out s_check)
[s check=‘no’]destroy
areYouOpen(out c_check)
areYouOpen(out ccheck)
[c_check=‘no']destroy
addCourse(crsOID) |
BddStudent(stdOID)
i eddStudent(stdOID) ।
Puc. 4.14. Диаграмма последовательностей для прецедента “Enter Program of Study”
(Запись на университетский курсы)
Объект класса ProgramEntryWindow проверяет с помощью объекта aStudent,
имеет ли право студент записаться (например, внес ли студент s_check соответст-
вующую плату). Выходной аргумент возвращает значение “yes” или “по” объекту
: ProgramEntryWindow. Если возвращается значение “по”, запись не может продол-
жаться, и объект : ProgramEntryWindow отправляет автосообщение самому себе, что-
бы уничтожить (destroy) себя (операция деструктора). Запись условия в квадратных
скобках говорит о том, что операция деструктора является необязательной.
182 Глава 4. Спецификация требований
Использование автосообщения для указания на необходимость уничтожения объ-
екта является просто сокращенной записью. В действительности объект^экземпляр не
может уничтожить себя. Сообщение об уничтожении (destroy) должно быть от-
правлено объекту-классу. Кроме того, в языке UML имеется специальное обозначение
для операции уничтожения объекта — большой знак X, помещенный на жизненной
линии объекта в точке, в которой объект должен быть уничтожен.
Если студент aStudent может быть записан, нам требуется выяснить, открыта ли за-
пись на курс aCourse. Для обслуживания этого требования объект aCourse должен за-
просить свой текущий объект aCourseOffering (на который указывает агрегативная
связь от Course к Courseoffering (рис. 4.6)). Если в текущем объекте
aCourseOffering свободных мест уже нет, запись не может продолжаться и объект
: ProgramEntryWindow снова отправляет себе автосообщение, чтобы разрушить себя.
Если процесс записи может продолжаться, объект : ProgramEntryWindow требует
от объекта aStudent добавить себе объект aCourseOffering, а затем требует, чтобы
объект aCourseOffering добавил объект aStudent к себе. Последовательность двух
операций объекта : ProgramEntryWindow может быть изменена на обратную, если
программа гарантирует ссылочную целостность между aCourseOffering и
aStudent (т.е. если студент записался на предлагаемый курс, то в список студентов по
данному курсу должен быть внесен данный студент).
Заметим, что если для хранения объектов Student и Courseoffering используется
ПО СУБД, то объект : ProgramEntryWindow мог бы отправлять только одно из этих двух
сообщений, т.е. отправить либо сообщение addCourse, либо сообщение addStudent.
После того, как объект aStudent добавлен к объекту aCourseOffering, ПО СУБД берет
на себя ответственность за поддержание ссылочной целостности и должно зафиксировать
существование связи от aStudent к aCourseOffering и наоборот.
Заметим также, что фактические аргументы, включенные в сообщения addCourse и
addStudent, представляют собой идентификаторы объектов (OID), содержащие зна-
чения OID (дескрипторы}, указывающие на объект aStudent и aCourseOfferin, соот-
ветственно. Эти значения OID были определены, когда объект : ProgramEntryWindow
получил доступ к объектам aStudent и aCourse с помощью сообщений areYouValid и
areYouOpen, представляющих собой запросы на возможность записи и наличие мест
на курсе.
4.3.4. Моделирование открытых интерфейсов
Открытый интерфейс (public interface) класса определяется набором операций, пред-
лагаемых классом в качестве услуг другим классам в системе. Подобные операции
объявляются с открытой видимостью. Объекты могут кооперироваться для выполне-
ния прецедентов только посредством открытых интерфейсов.
Открытые интерфейсы впервые определяются ближе к окончанию этапа анализа,
когда спецификации состояний и поведения в значительной степени определены. В
ходе анализа мы определяем только сигнатуру Каждой открытой операции (имя опе-
рации, список формальных аргументов, тип возвращаемого значения). В ходе проек-
тирования мы даем определение алгоритмам для метода, реализующего операцию.
4.3.4.1. Выявление операций классов
Операции классов лучше всего определять на основе диаграмм последовательно-
стей. Каждое сообщение в модели последовательностей, отличное от возвращаемого
4.3. Спецификация поведения 183
значения, должно быть обслужено операцией в объекте-приемнике (разд. 2.2.5.2). Ес-
ли модели последовательностей полностью построены, определение открытых опе-
раций представляется автоматической задачей.
Однако на практике диаграммы последовательностей — даже если они разработа-
ны для всех прецедентов — могут не обеспечить достаточного уровня детализации,
позволяющего выявить все открытые операции. Кроме того, диаграммы последова-
тельностей для операций, которые пересекают границы прецедентов, могут отсутст-
вовать (например, когда деловые операции охватывают более одного прецедента).
Поэтому при выявлении операций могут оказаться полезными вспомогательные
методы. Один из таких методов проистекает из того соображения, что объекты отве-
чают за собственную “судьбу” и поэтому они должны поддерживать четыре элемен-
тарных операции.
1. “Создать” (Create).
2. “Читать” (Read).
3. “Обновить” (Update)4.
4. “Удалить” (Delete).
Этот набор операций известен как CRUD-операции (разд. 3.5.2.1). CRUD-операции
позволяют другим объектам отправлять сообщение объекту’ с требованием выполнить
следующие действия.
1. Создать новый экземпляр объекта.
2. Получить доступ к состоянию объекта.
3. Модифицировать состояние объекта.
4. Объекту уничтожить самого себя.
4.3.4.2. Спецификация операций классов
На этом этапе ЖЦ разработки ПО необходимо модифицировать диаграмму клас-
сов, чтобы ввести в модель сигнатуры операций. Здесь можно также определить об-
ласть действия операций. По умолчанию предполагается использование области
действия экземпляра (операция применяется к объектам-экземплярам). Область дейст-
вия-класс (статическая) должна быть объявлена явно (указанием символа перед
именем операции). Область действия-класс устанавливает, что операция приме-
нима к объектам-классам (разд. 2.1.6).
Другие свойства операции, такие как параллельность, полиморфное поведение и
спецификация алгоритма, задаются позже в процессе проектирования.
4.3.4.3. Пример спецификации операций классов
О >
- - 1 * .. V<«.„ ..._.,..5?. ; = ~=-:
: Обратитесь к примерам 4.9. и 4.17, а также классам Course и Courseoffering, приве- '•
I денным на рис. 4.6. Объекты этих двух классов использовались в диаграмме последова-
t тельностей, показвнной на рис. 4.14.
; Наша задача заключается в том, чтобы получить операции на основе диаграммы после- ;
; довательностей и ввести их в классыCourse и Courseoffering.
184 Глава 4. Спецификация требований
Операции, заданные в расширенной модели классов на рис. 4.15, получены непо-
средственно из диаграммы последовательностей, показанной на рис. 4.14. Пикто-
граммы перед атрибутами означают, что атрибуты обладают закрытой областью дей-
ствия. Пиктограммы перед операциями говорят о том, что они открытые.
Рис. 4.15. Спецификация операций классов (Запись на университетские курсы)
Вот перечень операций: Course.areYouOpen, Courseoffering.areYouOpen,
Course.addStudent и Courseoffering.addStudent. Предполагается, что объект
Course получает список студентов с помощью доступа к своим составным объектам
класса Courseoffering.
Хотя атрибуты отношения обычно не приводятся в моделях анализа (они неявно
входят в связь, обозначающую отношение), мы включили три атрибута отношения, не-
обходимых операциям. Вот эти атрибуты: Course. crs_off, Courseoffering. std и
Courseoffering.crs. Заметим, что атрибуты crs_off и std обладают параметризо-
ванными типами; они являются коллекциями (set и list) объектов.
4.4. Спецификация изменения состояний
Состояние объекта в определенный момент времени определяется значениями
его атрибутов, включая атрибуты отношения. Спецификация состояний, помимо
прочего, определяет атрибуты класса. Спецификация поведения определяет опера-
ции класса, некоторые из которых дают побочные эффекты (т.е. они изменяют состоя-
ние объекта). Однако для понимания того, каким образом объект может изменять
свое состояние во времени, нам необходим более целенаправленный взгляд на систе-
му. Подобный взгляд может обеспечить спецификация изменения состояний.
Значение спецификации изменения состояний изменяется в зависимости от об-
ласти приложения. Моделирование изменения состояний для бизнес-приложений
значительно менее критично, чем инженерных приложений и приложений реально-
го времени. Многие инженерные приложения и приложения реального времени
полностью определяются изменением состояний объектов. При моделировании по-
добных систем необходимо с первого дня сосредоточиться на изменении состояний.
Что случится, если температура окажется слишком высокой? Что будет, если клапан
не закроется? Что произойдет, если контейнер переполнится? И т.д.
В этом учебнике мы преимущественно сосредоточили свое внимание на бизнес-
приложениях, для которых изменения состояния наблюдаются менее часто. Поэтому
моделирование изменения состояний обычно осуществляется ближе к окончанию
этапа анализа (и продолжается со значительно большей глубиной на этапе проекта-
4.4. Спецификация изменения состояний 185
рования). Многие спецификации изменения состояний определяют исключительные
условия в системе. Естественно, что исключения из обычного поведения системы мо-
делируются после спецификации нормального поведения.
4.4.1. Моделирование состояний объектов
Моделирование состояний объектов осуществляется с помощью диаграмм состоя-
ний. Граф состояний (автомат) — это граф состояний и переходов. Модели состояний
строятся для каждого класса, проявляющего интересное для аналитика динамическое
поведение. Не все классы диаграммы классов относятся к этой категории.
Диаграммы состояний можно также использовать для описания динамического
поведения других моделируемых элементов, например, прецедентов, коопераций или
операций. Это, однако, встречается нечасто, и некоторые CASE-средства могут не
поддерживать подобные функциональные возможности.
4.4.1.1. Выявление состояний объектов
Процесс исследования состояний объектов основан на анализе содержимого ат-
рибутов классов и выявлении того, какие из этих атрибутов представляют особый ин-
терес с точки зрения прецедентов. Не все атрибуты влияют на изменения состояний.
Например, модификация телефонного номера клиентом не изменяет состояния
объекта Customer. У клиента по-прежнему имеется телефон, а номер телефона не
существенен. Однако удаление номера телефона может трактоваться как изменение
состояния с точки зрения некоторых прецедентов. Больше связаться с клиентом по
телефону нельзя.
Аналогично, изменение номера телефона, которое включает изменение кода ре-
гиона может представлять интерес как изменение состояния, поскольку указывает па
то, что клиент сменил свое географическое местоположение, и это изменение может
быть необходимо зафиксировать и отразить в диаграмме состояний.
4.4.1.2. Спецификация состояний объектов
Основные обозначения языка UML, касающиеся спецификации диаграмм состоя-
ний, были введены в разделе 2.2.6. Для успешного применения этой системы обозна-
чений аналитик должен понимать взаимосвязи между различными понятиями, какие
сочетания понятий являются неестественными или недопустимы и какие сокращения
возможны в рамках предлагаемой нотации. Применение CASE-средств может быть
связано с определенными ограничениями в представлении диаграмм состояний, но
вполне возможны и некоторые любопытные расширения.
Переходы между состояниями активизируются при появлении определенных со-
бытий ши выполнении определенных усилий. Это означает, например, что линия
перехода не нуждается в метке, указывающей имя события. Само условие (записываемое
в квадратных скобках) активизирует переход всякий раз, когда вид деятельности в со-
стоянии завершен и условие принимает значение “истина”.
В типичной ситуации переход запускается сигнальным событием или событием
вызова. Сигнальное событие устанавливает явную, асинхронную однонаправленную
связь между двумя объектами. Событие вызова устанавливает синхронную связь, в ко-
торой вызывающий объект ожидает ответа. Существует еще два типа пусковых собы-
тий: событие изменения и временное событие. В частности, временное событие, запус-
кающее переход, основано на абсолютном или относительном понятии времени и яв-
ляется очень полезным в некоторых моделях.
186 Глава 4. Спецификация требований
Еще одно соображение, касающееся моделирования состояний, связано с возмож-
ностью спецификации входных действий внутри пиктограммы состояния или во вхо-
дящем переходе. Аналогично, выходное действие можно поместить внутри пикто-
грамм состояний или в исходящих переходах. Хотя это и не затрагивает семантики,
выбор используемого метода может сказаться на удобстве восприятия модели [74].
4.4.1.3. Пример спецификации диаграммы состояний
Пример4h9fMar^Hци^еЬпрста^ '.'3
Обратитесь к примеру 4.9 и рассмотрите класс MovieTitle (рис. 4.7). Наша задача со- ?
’ стоит в спецификации диаграммы состояний для класса MovieTitle.
Диаграмма состояний для класса MovieTitle приведена на рис. 4.16. Диаграмма ил-
люстрирует различные способы спецификации переходов. Переходы между состоя-
ниями Available (В наличии) и Not in Stock (Нет в запасе) задают параметризо-
ванные имена событий наряду с именами действий и защитными условиями. С другой
стороны, переход из состояния Reserved (Забронировано) в Not Reserved (Не за-
бронировано) лишен явного пускового события. Этот переход запускается посредством
завершения вида деятельности в состоянии Reserved, в результате которого условие
отказа в бронировании [no more reserved] принимает значение “истина”.
MovieTitle
Рис. 4.16. Диаграмма состояний для класса “Movie Title” (Магазин видеопроката)
Резюме 187
Резюме
Эта глава является ключевой для всей книги — здесь показан UML в действии. Раз-
бор примеров, введенных в главе 2, послужил в качестве иллюстративного материала.
В дело были пущены все часто используемые UML-модели. Девиз этой главы мог бы
звучать так: в сфере моделей анализа ИС однозначных решений типа “черное-белое”,
“нуль-единица”, “истина-ложь” не существует. Для каждой проблемы существует мно-
жество потенциальных решений. Фокус состоит в том, чтобы придти к решению, ко-
торое удовлетворяет требованиям заказчика и способно работать.
Спецификация состояний описывает мир ИС со статической точки зрения классов,
содержания их атрибутов и их отношений. Существует много методов выявления
классов, но ни один из них не дает единого рецепта. Практическим ответом на
проблему выявления классов служит комплекс методов, соответствующий знаниям
и опыту аналитика. В UML классы задаются с помощью диаграмм классов. Ди-
аграммы позволяют наглядно представить классы и три типа отношений между
ними: ассоциации, агрегации и обобщения.
Спецификация поведения описывает мир ИС с операционной точки зрения (для
того, чтобы не использовать перегруженный термин — функциональная точка
зрения). Движущей силой спецификации поведения и, конечно, анализа
требований и проектирования системы в целом выступают прецеденты. Диаграммы
прецедентов дают только наглядное представление — истинная сила прецедентов
заключается в их неформальных спецификациях. Остальные поведенческие ди-
аграммы являются производными от моделей прецедентов. Они включают ди-
аграммы видов деятельности, диаграммы взаимодействия и введение операций в классы.
Спецификации изменения состояний описывают мир ИС с динамической точки
'зрения. Объекты “бомбардируются” событиями, и некоторые из этих событий
вызывают изменения состояний объектов. Диаграммы состояний позволяют
моделировать изменения состояний.
1 Вопросы
В1. Обсудите, каким образом функциональные требования и требования к данным, выявлен-
ные на этапе установления требований, связаны с моделями состояний, поведения и из-
менения состояний, разрабатываемыми на этапе спецификации требований.
В2. Приведите доводы за и против использования CASE-средств для спецификации требований.
ВЗ. Объясните, в чем заключаются основные различия четырех подходов к выявлению классов.
В4. Обсудите и сравните процессы, связанные с выявлением и спецификацией атрибутов
классов и операций классов. Как следует моделировать атрибуты и операции: в параллель
или по отдельности? Почему?
В5. Обратитесь к модели классов на рис. 4.7 (пример 4.10). Объясните, почему атрибут
MovieTitle.is_in_stock моделируется как производный атрибут, а атрибут
VideoMedium.percentage_excellent_condition — как статический.
В6. Использование тернарных и производных ассоциаций в моделях анализа нежелательно.
Почему? Приведите примеры.
В7. Обратитесь к модели классов на рис. 4.5 (пример 4.8). Рассмотрите верхнюю часть моде-
ли, в которой определяются классы и ассоциации между классами PostalAddress,
188 Глава 4. Спецификация требований
CourierAddress, Organization и Contact. Предложите альтернативные пути моделиро-
вания этих же требований. Можно ли придать модели большую гибкость, чтобы ее можно
было приспособить к возможным изменениям в требованиях? Приведите доводы за и про-
тив альтернативных решений.
В8. Приведите примеры каждого из типов агрегаций: Безраздельно обладает. Обладает,
Включает и Участник.
В9. Обратитесь к модели классов на рис. 4.6 (пример 4.9). Объясните, как изменится семанти-
ка модели, если класс AcademicRecord, связанный с ассоциацией takes, моделировать
как “ассоциацию в роли класса"?
В10. Наследование без полиморфизма возможно, но не очень полезно. Почему? Приведите
примеры.
В11. Какие из моделей UML полезны при спецификации поведения? Объясните, в чем заклю-
чаются сильные стороны каждой из этих моделей и каким образом они взаимосвязаны при
определении поведения системы?
В12. Объясните, в чем состоит различие прецедентов и деловых функций (или деловых тран-
закций)?
В13. Приведите пример отношений «include» и «extend» между прецедентами. В чем их
основное отличие?
В14. Приведите пример класса с несколькими атрибутами. Обсудите, какие из атрибутов могут
инициировать переход между состояниями, а квкие из атрибутов индифферентны к изме-
нениям состояний?
Д| Упражнения
Рассмотрите следующие дополнительные требования к приложению Запись на универ-
ситетские курсы.
1. Университет разделен на факультеты. Факультеты разделены на кафедры. Препода-
ватели работают на одной из кафедр.
2. Присвоение большинства ученых степеней является прерогативой одного факульте-
та, но некоторые ученые степени находятся в совместном ведении двух и более фа-
культетов.
3. Новые студенты получают уведомление о приеме и инструкции по записи на курсы
по почте. Студенты, продолжающие учебу, которые имеют право перезаписаться на
курсы, получают (также по почте) инструкции по записи вместе в уведомлением об
экзаменационных результатах.
4. Инструкции по записи на курсы включают расписание аудиторий для предлагаемого
курса.
5. В период записи на курсы студенты могут получить консультацию у научного руково-
дителя на факультете, на котором они числятся, по вопросу составления программы
обучения. |
6. Студенты не ограничены в изучении только тех курсов, которые предлагаются их фа- |
культетом, и в любой момент могут сменить факультет, на котором они числятся >
(заполнив форму изменения программы, которую можно получить в деканате). j
7. Чтобы взять определенные курсы, студент должен сначала пройти обязательные
курсы, получив требуемые оценки (простого прохождение курса может быть недос- |
Упражнения 189
j таточно). Студент, который не смог удовлетворительно пройти курс, может попы-
j таться сделать это вновь. Для записи на курс в третий раз или в случае требования
I освобождения от обязательных курсов необходимо получить согласие представите-
ля соответствующего деканата.
j в. Если студенты записываются на те учебные курсы, которые в совокупности дают за
; год менее чем 18 условных очков, эти студенты относятся к категории студентов
I "вечерней" формы обучения.
I 9. Для того, чтобы получить возможность записаться на программу курсов, которые в
i данном семестре дают в совокупности более 14 условных очков, требуется специ- 1
I альное разрешение.
1 10.3а каждым курсом обучения закреплен ответственный преподаватель, однако к нему
| могут быть привлечены дополнительные преподаватели. В каждом семестре за курс
! может отвечать другой преподаватель, а каждый курс в течение семестра могут вес-
j ти разные преподаватели.
j Рассмотрите следующие дополнительные требования к приложению Магазин видеопроката.
1. За кассеты и диски, возвращенные позже срока, взимается дополнительная плата
за период, превышающий срок проката. Каждый видеоноситель обладает уникаль-
ным идентификационным номером.
( 2. Фильмы заказываются у поставщика, который, в общем случае, может поставить кассеты
и диски в течение одной недели. Обычно один заказ делается на несколько фильмов.
3. Забронировать можно те фильмы, которые заказаны у поставщика и/или все копии
которых находятся в прокате. Можно также забронировать те фильмы, которых нет в
; запасе и которые не заказаны у поставщика; при этом с клиента требуется задаток
; за один период проката.
4. Клиент может также сделать несколько предварительных заказов, однако для каждо-
; го забронированного фильма готовится отдельный запрос на бронирование. Брони-
s' рование может быть отменено из-за отсутствия реакции со стороны клиента, более
’ точно, в течение одной недели с момента, когда клиенту было сообщено о возмож-
ности взять фильм напрокат. Если за фильм был уплачен задаток, он записывается
» на счет клиента.
i 5. База данных хранит обычную информацию о поставщиках и клиентах, т.е. адреса,
телефонные номера и т.д. В каждом заказе поставщику указываются заказываемые
s фильмы, их количество, форматы кассеты/диска, а также дата ожидаемой доставки,
отпускная цена, возможные скидки и т.д.
’ 6. Когда кассета возвращается клиентом или поступает от поставщика, вначале удов-
\ летворяются предварительные заказы. Работники магазина устанавливают контакт с
j клиентами, сделавшими предварительный заказ. Для правильной обработки брони-
5 рования фильмов информация, связанная с бронированием, обновляется дважды:
I после установления контакта с клиентом, когда ему сообщается, что
“забронированный фильм пришел”, и после сдачи фильма клиенту напрокат. Эти
шаги гарантируют правильное проведение операции бронирования.
7. Клиент может взять несколько кассет или дисков, однако каждому взятому видеоно-
! сителю ставится в соответствие отдельная запись. Для каждого выдаваемого напро-
кат фильма фиксируются дата и время выдачи, установленный и фактический срок
; возврата. Позже запись о покате обновляется, чтобы отразить факт возврата ви-
! деофильма и факт окончательного платежа (или возврата денег). Кроме того, запись
J хранит информацию о продавце, отвечающем за прокат фильма. Детальная инфор-
190 Глава 4. Спецификация требований
мация о клиенте и по прокату хранится в течение года, чтобы можно было легко оп- »
; ределить уровень доверия к клиенту. Старая информация по прокату сохраняется в j
течение года в целях проведения аудита. j
> >
; 8. Все операции выполняются с использованием наличности, электронного перевода •
денег или кредитных карточек. От клиентов требуется внести плату за прокат при J
выдаче кассет/дисков. ;
, 9. Если кассета/диск возвращены позже установленного срока (или не могут быть воз- г
вращены по каким-либо причинам) плата снимается либо со счета клиента, либо
принимается непосредственно от клиента.
10. Если кассета/диск задержаны более чем на два дня, клиенту отправляется уведом-
; ление о задержке. После отправки двух уведомлений о задержке одной и той же кас-
сеты/диска, клиент предупреждается о том, что он является “нарушителем” и при
, следующем его обращении в магазин руководство рассматривает вопрос о снятии с
него статуса “нарушителя".
У 1. Запись на университетские курсы — обратитесь к приведенным выше дополнительным
требованиям и к примеру 4.1 (раздел 4.2.1.1.7).
Какие новые классы можно получить на основе анализа расширенных требований?
У 2. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.2 (раздел 4.2.1.1.7).
Какие новые классы можно получить на основе анализа расширенных требований?
УЗ. Запись на университетские курсы — обратитесь к приведенным выше дополнительным
требованиям, упражнению У1 и примеру 4.9 (раздел 4.2.3.3).
Предложите, каким образом следует расширить модель классов, приведенную на рис. 4.6
(пример 4.9), чтобы учесть расширенные требования. Покажите классы и отношения.
У 4. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям,
упражнению У2 и примеру 4.10 (раздел 4.2.4.3).
Предложите, каким образом следует расширить модель классов, приведенную на рис. 4.7
(пример 4.10), чтобы учесть расширенные требоввния. Покажите классы и отношения.
У 5. Запись на университетские курсы — обратитесь к приведенным выше дополнительным
требованиям, упражнению, примеру 4.12 (раздел 4.3.1.3).
Предложите, каким образом следует расширить модель прецедентов, приведенную на
рис. 4.9 (пример 4.12), чтобы учесть расширенные требования.
Уб. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и примеру 4.14 (раздел 4.3.1.3).
Исследуйте неформальную спецификацию для прецедента Rent video, приведенную в
табл. 4.4 (пример 4.14). Пропустите последний абзац раздела “Основной поток” таблицы
(этот абзац относится скорее к прецеденту Maintain Customer). Разработайте отдель-
ную диаграмму прецедентов для отображения дочерних прецедентов Rent video.
У 7. Запись на университетские курсы — обратитесь к приведенным выше дополнительным
требованиям и примеру 4.17 (раздел 4.3.3.3).
Предложите, каким образом следует расширить диаграмму последовательностей, приве-
денную на рис. 4.14 (пример 4.17), чтобы включить проверку обязательных условий записи
на курсы — студент записывается на курс только в том случае, если он прошел обязатель-
ные курсы.
У 8. Запись на университетские курсы — обратитесь к примеру 4.18 (раздел 4.3.4.3) и реше-
нию к приведенному выше упражнению У7.
Упражнения 191
Воспользуйтесь расширенной диаграммой последовательностей для введения новых опе-
раций в релевантные классы, включая два класса, приведенные на рис. 4.14 (пример 4.18).
У9. Управление контактами с клиентами — обратитесь к примеру 4.8 (раздел 4.2.2.3).
Разработайте диаграмму состояний для класса Event.
У10. Телемаркетинг — обратитесь к примеру 4.7 (раздел4.2.1.2.3).
Добавьте ассоциации классов, пропущенные на рис. 4.4. Определите кратность каждой
ассоциации.
У11. Управление контактами с клиентами — обратитесь к примеру 4.8 (раздел 4.2.2.3).
Рассмотрите классы Organization, Contact, PostalAddress и CourierAddress. В каче-
стве расширения модели, приведенной на рис. 4.5, предусмотрите возможность введения
иерархической структуры для организации, т.е. организация может состоять из более
мелких организаций. Усильте модель классов за счет использования обобщения и одно-
временно расширьте ее, чтобы учесть иерархическое строение организации.
Углубленный анализ
В предыдущей главе мы нарисовали картину визуального объектно-ориентирован-
ного моделирования в “розовом свете”. Примеры были нетребовательными, язык ви-
зуального проектирования — простым и привлекательным для использования, зави-
симости между моделями — очевидными. Мы вольно обращались с методами модели-
рования и не слишком заботились об альтернативных решениях.
Реалии разработки программного обеспечения куда сложнее. Как мы заметили в
начале книги, простых решений для сложных проблем не существует. Объекты со-
ставляют основу современной технологии решения сложных проблем. А раз так, то
объекты обязаны обеспечить и техническую глубину, соответствующую уровню слож-
ности, к которой они обращены.
Эта глава призвана дать критическую оценку объектной технологии и ее пригод-
ности к решению сложных проблем. Мы вводим передовые концепции в моделирова-
ние классов, иерархию классов, наследование и делегирование. На протяжении всей
главы сравниваем, выносим решения, высказываем мнение и предлагаем альтерна-
тивные решения. Из-за своего технического характера многие темы, рассматривае-
мые в этой главе, переносятся прямо на системное проектирование. Это согласуется с
универсальным характером UML, а также итеративным и наращиваемым процессом
объектно-ориентированной разработки ПО.
5.1. Углубленное моделирование классов
Концепции моделирования анализа, которые рассматривались до сих пор, были
достаточны для выработки завершенных моделей анализа. Однако обеспечиваемый
этими концепциями уровень абстракции не исчерпывает всех возможных деталей,
допустимых в рамках моделирования анализа (т.е. деталей, которые не касаются ап-
паратных/программных решений, но обогащают семантику модели). UML включает
нотацию для ряда дополнительных концепций, о которых мы упоминаем только
вскользь или которых не касаемся вообще.
Дополнительные концепции моделирования включают стереотипы, ограничения,
производную информацию, видимость, квалифицированные ассоциации, ассоциа-
тивные классы, параметризованные классы и некоторые другие. Эти концепции не-
обязательны. Многие модели могут быть вполне приемлемы без них. Их применение
требует осторожности и точности, так чтобы любой, кто попробует разобраться с мо-
делями впоследствии, мог без труда понять намерения разработчика.
5.1. Углубленное моделирование классов 193
5.1.1. Стереотипы
Стереотип (stereotype расширяет существующий элемент моделирования UML. Вно-
сит некоторые изменения в семантику существующего элемента. По существу не явля-
ется новым элементом моделирования и также не изменяет структуру UML, а только
обогащает содержание существующей нотации. Он позволяет расширить и настроить
метод. Существуют различные способы применения стереотипов.
Обычно стереотипы помечены в модели с помощью имени, заключенного в особые
скобки (которые называются во французском языке guillemets и выглядят как двойные
угловые кавычки), например, «global», «РК», «include» (Следует иметь в виду, что
эти кавычки — один символ, а не два. Прим. ред.). Возможно также представлять сте-
реотип с помощью пиктограммы.
Некоторые распространенные стереотипы являются встроенными— они заранее
определены в UML. Некоторые CASE-средства включают готовые пиктограммы для
встроенных стереотипов. Большинство CASE-средств обеспечивают возможность
создания новых пиктограмм по желанию аналитика. На рис. 5.1 показан пример клас-
са, обозначенного как стереотип с помощью пиктограммы, метки, и тот же класс, не
являющийся стереотипом.
«Actor»
Customer
Customer
Customer
Стереотип
“пиктограмма"
Стереотип
“метка"
Не стереотип
Рис. 5.1. Пиктограммы и метки стереотипов
Ограничение, гласящее, что стереотип расширяет семантику, но не структуру UML,
довольно несущественно. Главная отличительная черта любой объектно-
ориентированной системы заключается в том, что она полностью состоит из объектов—
класс является объектом, атрибут также является объектом, метод — также объект и т.д.
Следовательно, превращение класса в стереотип может привести в итоге к созданию
нового элемента моделирования, который вводит новую категорию объектов.
Например, в разд. 7.6.1 и 9.2.1 показано, как можно использовать стереотипы для
создания нового метода моделирования — диаграмм навигации по окнам, диаграмм
навигации по программе. При использовании подобного способа стереотипы расши-
ряют UML для конкретной цели. А цель эта зачастую состоит в том, чтобы работать
моделированием проектирования, а не моделированием анализа. Модели проектиро-
вания согласуются с платформой реализации. Следовательно, они должны работать с
элементами моделирования, надлежащим образом представляя эту платформу.
Целевой набор стереотипов, направленный на решение вопросов моделирования
проектных решений, называется профилем (profile). В будущем стандарты UML могут
включать профили для распространенных проектных решений, таких как базы дан-
ных или CORBA (Common Object Request Broker Architecture — Общая архитектура
брокера объектных запросов).
194 Глава 5. Углубленный анализ
5.1.2. Ограничения
Стереотипы часто путают с ограничениями. Конечно, иногда различие между
этими двумя понятиями провести довольно трудно. Зачастую стереотип используется
для введения в модель нового ограничения — того, которое имеет смысл для моделиро-
вания, но не поддерживается непосредственно в UML.
С каждым элементом моделирования может быть связано ограничение, либо он
может быть превращен в стереотип. На диаграмме модели показывают только про-
стые ограничения. Их показывают в виде текста, заключенного в фигурные скобки
(или в виде символа примечания — см. разд. 5.1.3), и они графически и семантически
ограничены модельным элементом. Более доскональные ограничения (слишком
большие для графической модели) хранятся в репозитории CASE-системы обычно как
документ, созданный некоторым текстовым процессором.
i Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Вернитесь к той части требования 2, которая
: гласит: “Все билеты пронумерованы. В рамках камлании все билеты обладают уникаль-
. ними номерами.”
4 В решении к примеру 4.7 (рис. 4.4) мы не зафиксировали приведенное выше ограниче-
: ние (недостает включения атрибута campaign_code (вместе с ticket_number) в класс
- CampaignTicket как часть составного первичного ключа). j
Наша задача состоит в том чтобы, смоделировать ограничение на диаграмме классов. |
(номера билетов ticket_number
уникальны только
а рамках своей компании)
Рис. 5.2. Ограничение для класса
(Телемаркетинг)
5.1. Углубленное моделирование классов 195
На рис. 5.2 представлено простое расширение модели классов, позволяющее пока-
зать ограничение. Ограничение связано с классом CampaignTicket. В отчете, выра-
ботанном любым CASE-средством, ограничение будет приведено вместе с другими
свойствами класса.
ГГЗнм'ОпД д Управпен^ тоб^шсп11^ у кпийнтймн
Обратитесь к примеру 4.8 (разд. 4.2.2.3). Предположим, что было выявлено новое тре- ;
бование, которое не было предусмотрено в системе: планирование мероприятий со- ;•
трудниками для себя. Это значит, что сотрудник, который создал мероприятие ;
(Employee. created), не должен быть тем же сотрудником, который отвечает за выпол- I
нение мероприятия (Employee. due).
Расширьте соответствующую часть модели классов (рис. 4.5) таким образом, чтобы \
включить новое требование.
Решение для этого примера (рис. 5.3) имеет своим результатом ограничение на ассо-
циативные связи, что показано в виде прерывистой стрелки-указателя зависимости, про-
веденной от ассоциации created к ассоциации due. Ограничение привязано к стрелке.
created
completed
Рис. 5.3. Ограничение на ассоциации (Управление контактами с клиентами)
5.1.3. Примечания и дескрипторы
Если описание ограничения слишком длинно или же ограничение должно быть
выражено с использованием трех или более графических символов, можно восполь-
зоваться таким понятием UML, как примечание (note). Графически “примечание пред-
ставляет собой прямоугольник с загнутым правым верхним краем” [76].
Символ примечания может содержать текст для выражения ограничения, однако,
в общем случае, он может содержать любую информацию. Чтобы показать, что при-
мечание является ограничением, его необходимо дополнительно обозначить как сте-
реотип с помощью ключевого слова «constraint».
Подобно примечаниям, дескрипторы (tag) представляют произвольную текстовую
информацию в модели, в том числе, ограничения. Аналогично ограничениям деск-
рипторы записываются внутри фигурных скобок и принимают следующий вид
tag - значение,например:
{author = lea, atatua = 2nd iteration).
196 Глава 5. Углубленный анализ
Аналогично стереотипам и ограничениям некоторые дескрипторы предопределе-
ны в UML. Обычно дескрипторы используются для отображения информации по
управлению проектом.
i Обратитесь к примеру 4.8 (разд. 4.2.2.3) и приведенному выше примеру 5.2. Предполо-
। жим, что было выявлено новое требование, которое не было предусмотрено в системе:
> сотрудник, который создал задание, должен также создать — в этой же транзакции —
‘ первое мероприятие для этого задания.
i Расширьте соответствующую часть модели классов (рис. 4.5 и 5.3) таким образом, чтобы
: аключить новое требование. Используйте примечание ограничения. Также отобразите на
i диаграмме информацию о том, что аналитик, разработавший диаграмму — les (вероятно,
i подразумевается автор — Лешек), а диаграмма представляет собой вторую итерацию.
На рис. 5.4 показана расширенная модель. Для представления информации по
проекту используется дескриптор в левом верхнем углу диаграммы. Для представле-
ния ограничения на трех ассоциациях используется примечание. Примечание обо-
значено как стереотип с помощью слова «constraint», чтобы подтвердить, что
примечание — это ограничение.
completed
Рис. 5.4. Примечание и дескриптор как ограничения (Управление контактами с клиентами)
5.1. Углубленное моделирование классов 197
5.1.4. Видимость и инкапсуляция
Концепция видимости (visibility) и связанное с ней понятие инкапсуляции (encapsulation)
были впервые рассмотрены в разд. 2.1.2.1.2 и 2.1.2.2.2. При этом было только обозначе-
но различие между открытой и закрытой видимостью атрибутов и операций. Третий
предопределенный в UML тип видимости — защищенная (protected) — не рассматривался.
Точно так же не рассматривались различные тонкие взаимные влияния между ви-
димостью и наследованием. Кроме того, не были рассмотрены популярные и удобные
(кое-кто может возразить — неудобные) методы преодоления инкапсуляции объектов
с помощью дружественных операций.
В UML в качестве стандартных обозначений видимости приняты следующие зна-
ки: + (для открытой), # (для защищенной ) и - (для закрытой) видимости. Знаки по-
мещаются перед именем свойства. CASE-средства часто заменяют эти довольно туск-
лые обозначения. На рис. 5.5 приведен пример более привлекательной нотации.
Visibility ~
ЩргК/ate
Mlprotected
Hpublic
QprivateO
fljprotectedQ
HpubllcQ
Рис. 5.5. Обозначение видимости
с помощью CASE-cpedcmea
5.1.4.1. Защищенная видимость
Ситуация, при которой закрытые свойства (атрибуты и операции) базового класса
доступны только объектам базового класса, иногда связана с неудобствами. Во многих
случаях объектам производного класса (подкласса базового класса) необходимо раз-
решить доступ к закрытым свойствам базового класса.
Рассмотрим иерархию классов, где Person— это базовый класс, a Employee —
производный класс. Если Joe — объект класса Employee, то — по определению обоб-
щения — Joe должен иметь доступ к свойствам (по меньшей мере к некоторым атри-
бутам) класса Person (например, к такому как дата рождения — date_of_birth).
Чтобы дать возможность производному классу осуществлять свободный доступ к
свойствам его базового класса, эти (в противном случае — закрытые) свойства необхо-
димо определить в базовом классе как защищенные (protected). (Вспомним из разд.
2.1.2.1.2, что видимость применяется по отношению к классам. Если Betty — еще
один объект класса Employee, то он должен иметь доступ к любому свойству Joe: от-
крытому, защищенному или закрытому.)
Подобный сценарий справедлив для большинства известных объектно-
ориентированных сред программирования, примерами могут служить C++ и Java [25].
Язык UML не составляет исключения в этом вопросе. Здесь просто утверждается:
“Видимость является частью отношения между элементом и содержащим его контей-
нером. Контейнер может быть пакетом, классом или другим представителем про-
странства имен” [76].
198 Глава 5. Углубленный анализ
! Обратитесь к постановке задачи 4 (разд. 2.3.4) и примеру 4.7 (разд. 4.2.1.2.3). Поста-
| новка задачи содержит следующее замечание: “Эти схемы включают специальные при-
I зовые кампании для вознаграждения приверженцев, закупающих лотерейные билеты в
I массовом количестве, для привлечения новых жертвователей и т.д.’’. Это замечание
। еще не нашло отражения а модели.
j Предположим, что одна из призовых кампаний включает “билетные книжки": если бла-
j готворитель покупает целую книжку билетов, ему бесплатно вручается дополнительный
I билет основной кампании.
| Наша задача состоит в выполнении следующих действий. '
| Обновить модель класса, включив в нее класс Bonuscampaign.
; Изменить видимость атрибутов класса Campaign (рис. 5.2) таким образом, чтобы они
। были видимы классу BonusCampaign за исключением атрибута date_start. Сделать ат-
। рибуты campaign code и campaign title видимыми для остальных классов модели.
( Добавить в класс Campaign следующие вычислительные операции: computeTicketsSold
| (проданные билеты), computeTicketsLeft (остаток билетов), computeDuration,
! (продолжительность [кампании]), computeDaysLeft (оставшиеся дни). j
i Осознать, что у внешних классов нет нужды в атрибуте computeTicketsSold. Им тре- j
j буется знать только атрибут computeTicketsLeft. Кроме того, computeDuration ис- $
| пользуется только операцией Campaign.computeDaysLeft. I
j Класс BonusCampaign хранит атрибут ticket_book_size (величина билетной книжки), а ;
i операция доступа к нему называется booksize. {
Рис. 5.6. Видимость свойств класса
(Телемаркетинг)
5.1. Углубленное моделирование классов 199
На рис. 5.6 показана модель классов, соответствующая приведенному выше пояс-
нению. Стереотип «protected» на линии обобщения рассматривается в следующем
разделе. Операция computeTicketsSold в классе Campaign является закрытой.
Операция computeDuration в классе Campaign является защищенной. Остальные
две операции в классе Campaign — открытые. Операция bookSize специфична для
класса BonusCampaign и является открытой.
5.1.4.2. Видимость унаследованных свойств классов
Как декларируется в UML, характеристика видимости применяется к объектам на
различных уровнях детализации. Обычно имеется в виду, что видимость применяется
к элементарным объектам — атрибутам и операциям. Однако видимость можно задать и
по отношению к другим “контейнерам”. Это приводит к полной неразберихе с прави-
лами замещения.
Рассмотрим, к примеру, распространенную ситуацию, когда видимость определя-
ется в иерархии наследования на уровне базового класса и на уровне свойств базового
класса. Пусть, скажем, класс В — подкласс класса А. Класс А содержит смесь атрибутов
и операций — некоторые из них являются открытыми, другие — закрытыми, а осталь-
ные — защищенными. Вопрос звучит так: “К какому типу видимости относятся унасле-
дованные свойства в классе В?”
Ответ на этот вопрос зависит от уровня видимости, установленного базовому клас-
су А при объявлении его в производном классе В. Базовый класс можно объявить от-
крытым (class В: public А), защищенным (class В: protected А) или закры-
тым (class В: private А).
Типичное разрешение приведенного выше сценария выглядит следующим обра-
зом [38].
Закрытые (private) свойства (атрибуты и операции) базового класса А не видимы
для объектов класса В вне зависимости от того, как базовый класс определен в В.
Если базовый класс А определен как public, видимость унаследованных свойств в
производном классе В не изменяется (открытые (public) остаются открытыми, а
защищенные (protected) — защищенными).
Если базовый класс А определен как protected, видимость унаследованных
свойств в производном классе В изменяется на protected.
Если базовый класс А определен как private, видимость унаследованных свойств
с типом видимости public и protected в производном классе В изменяется на
private.
! Обратитесь к приведенному выше примеру 5.4. Предположим, что стереотип
! «protected» на линии обобщения означает, что класс Campaign определен в
? Bonuscampaign как защищенный:
j class BonusCampaign: protected Campaign
s Определите уровень видимости свойств унаследованного класса в классе
| Bonuscampaign. Поясните ваше решение.
200 Глава 5. Углубленный анализ
Если базовый класс определен как защищенный (protected), его открытые
(public) свойства в производном классе изменятся на защищенные. Защищенные
свойства останутся защищенными. Закрытые свойства не будут доступны производ-
ному классу (они никогда не доступны).
На рис. 5.7 и 5.8 представлены диалоговые окна CASE-репозитория, которые, со-
ответственно, отображают атрибуты и операции класса BonusCampaign после вступ-
ления в силу эффекта наследования.
Рис. 5.7. Унаследованные атрибуты в классе
BonusCampaign (Телемаркетинг)
Рис. 5.8. Унаследованные операции в классе
BonusCampaign (Телемаркетинг)
5.1. Углубленное моделирование классов 201
5.1.4.3. Дружественные классы и операции
В некоторых случаях функции (или даже классу в целом) требуется предоставить
непосредственный доступ к свойствам другого класса независимо от уровней видимо-
сти этих свойств. Подобная ситуация возникает, когда два класса тесно связаны и
операции одного из классов зависят от свойств другого класса. В качестве типичного
примера можно привести два класса: Book (Книга) и Bookshelf (Книжная полка), и
операцию класса Book под названием putOnBookShelf (Поставить на полку).
Один из способов разрешения ситуации, подобной описанной выше, состоит в
том, чтобы объявить операцию putOnBookShelf дружественной (friend) в пределах
класса Bookshelf; это может выглядеть, примерно, так friend void Book: :
putOnBookShelf().
Дружественным может быть другой класс или операция класса. Дружественность
не взаимна. Класс, дружественный по отношению к другому классу, может и не поль-
зоваться дружественностью со стороны последнего.
Дружественная операция или класс объявляются внутри класса, который наделяет
дружбой другой класс. Однако дружественная операция — это не свойство класса, по-
этому к ней неприменимы атрибуты видимости. Это также означает, что в определе-
нии дружественного отношения нельзя упоминать атрибуты класса даже по имени —
все они должны квалифицироваться по имени класса (как будто дружественная опе-
рация — это обычная внешняя операция).
В языке UML дружественные отношения показываются с помощью прерывистой
линии отношения зависимости (dependency relationship), исходящей из класса или опера-
ции к классу, который “дарит” дружбу. Стереотип «friend» привязан к стрелке зави-
симости. По общему признанию, нотация UML не полностью воспринимает и под-
держивает семантику дружественности.
। Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Рассмотрите отношение между классами *
I Campaign И CallScheduled. •
I Объекты класса CallScheduled очень активны, и при выполнении операций им требу- '
I ются специальные права. В честности, они выполняют операцию под названием ;
| getTicketsbeft, которая устанавливает, остались ли какие-то билеты, чтобы заказ *
f благотворителя мог быть удовлетворен. Существенно, что этв операция имеет прямой i
I доступ к свойствам класса Campaign (таким как num_tickets и num_tickets_sold). J
) Наша задача состоит в том, чтобы объявить операцию getTicketsbeft дружественной «
J к классу Campaign.
Решение в терминах UML для нашего примера показано на рис. 5.9. Операция
getTicketsbeft расположена внутри класса CallScheduled. Напомним, что в языке
программирования, используемом для реализации, операция getTicketsbeft объяв-
ляется дружественной внутри класса Campaign (поскольку именно класс Campaign оп-
ределяет, кто будет другом), азатем полностью определяется в классе CallScheduled
Отношение зависимости фиксирует тот факт, что класс Campaign предоставляет
некоторый дружественный статус классу CallScheduled. Из нотации не совсем ясно,
распространяется ли дружественный статус на весь класс или на некоторые операции
класса (и на какие именно).
202 Глава 5. Углубленный анализ
Рис. 5.9. Дружественность (Телемаркетинг)
5.1.5. Производная информация
Производная информация (derived information) представляет собой разновидность огра-
ничения, которое наиболее часто применяется к атрибуту или ассоциации. Производ-
ная информация вычисляется на основе других элементов модели. Строго говоря, про-
изводная информация является избыточной — при необходимости ее можно вычислять.
Хотя производная информация не обогащает семантику модели анализа, она прида-
ет модели большую четкость (поскольку в модели явно находит отражение факт воз-
можности вычисления некоторой величины). Решение о том, приводить или нет в
модели анализа производную информацию, довольно произвольно и должно после-
довательно распространяться на модель в целом.
Владение производной информацией имеет большее значение для проектных моде-
лей, в которых требуется учет возможностей оптимизации доступа к информации.
Применительно к проектным моделям можно также принять решение о том, хранить
ли производную информацию (после ее вычисления) или же динамически вычислять
ее каждый раз, когда в ней возникает необходимость. Это не новое свойство— в
прежних сетевых базах данных оно было известно как актуальные (т.е. хранимые) или
виртуальные данные.
В языке UML производная информация обозначается с помощью символа косой
черты (/), помещенного перед именем производного атрибута или ассоциации.
5.1. Углубленное моделирование классов 203
5.1.5.1. Производный атрибут
Мы уже использовали производные атрибуты ранее в нескольких примерах диа-
грамм, правда, не приводя никаких объяснений. Например, атрибут
num_tickets_sold на рис. 5.2— производный. Расширенная диаграмма для этого
рисунка показана ниже (рис. 5.10).
Значение атрибута num_tickets_sold вычисляется с помощью операции
computeTicketsSold. Выполнение операции следует агрегативной связи с классом
CampaignTicket (Билеты, используемые в кампании) и проверяет статус каждого
билета— ticket status. Если статус билета— ticket status — принимает значе-
ние “продан”, то к счетчику проданных билетов прибавляется единица. После обра-
ботки всех билетов выводится текущее значение количества проданных билетов
num_tickets_sold.
{номера билетов ticket_number
уникальны только
в рамках своей компании}
Рис. 5.10. Производный атрибут
(Телемаркетинг)
5.1.5.2. Производная ассоциация
Производная ассоциация — более спорная тема. Типичным случаем производной
ассоциации можно считать ассоциацию, образованную тремя классами, уже соеди-
ненными двумя ассоциациями, при этом третья ассоциативная связь замыкает контур.
Зачастую необходимость в третьей ассоциации возникает в связи с требованием се-
мантической корректности модели (это известно как коммутативность контура). Если
204 Глава 5. Углубленный анализ
третья ассоциация не представлена в модели явно, она может быть выведена из двух
других ассоциативных связей.
Г
> Обратитесь к наставлению по Internet-магазину в главе 2 и к диаграмме классов на
• рис. 2.32 (разд. 2.2.4.Б). Рассмотрите часть модели, включающую классы Customer,
I order и Invoice.
' Существует ли возможность ввести производную ассоциацию в модель? Если да, то до-
f бавьте ее к диаграмме.
Да, между классами Customer и Invoice возможно ввести производную ассоциа-
цию. На приведенном ниже рис. 5.11 она обозначена именем /Custlnv. Эта ассоциа-
ция выводится, благодаря слегка необычному бизнес-правилу, по которому кратность
ассоциации между классами Order и Invoice равна “один к одному”.
Рис. 5.11. Производная ассоциация (Internet-магазин)
Производная ассоциация не вносит в модель какой-либо новой информации. Всегда
можно связать клиента (Customer) с определенным заказом (Order), отыскав один за-
каз для каждой счет-фактуры (Invoice), азатем одного клиента для каждого заказа.
5.1.6. Квалифицированная ассоциация
К концепции квалифицированной ассоциации (qualified association) в среде специали-
стов по моделированию относятся по-разному. Некоторые охотно пользуются этим
понятием, другие не воспринимают его вовсе. Можно ли построить полную и доста-
точно выразительную модель классов без использования квалифицированной ассо-
5.1. Углубленное моделирование классов 205
циации — вопрос спорный. Однако если уж квалифицированная ассоциация исполь-
зуется, то использовать ее при построении моделей классов следует последовательно.
По одну сторону линии бинарной квалифицированной ассоциативной связи име-
ется “отделение” для атрибута (квалификатора (qualifier)') (ассоциация может быть ква-
лифицирована по обоим концам связи, но это довольно редкий случай). Это
“отделение” содержит один или более атрибутов, которые служат в качестве ключа
индекса для прослеживания ассоциативной связи от квалифицирующего класса (qualified
class) посредством квалификатора до целевого класса (target class) на противоположном
конце ассоциации.
Например, ассоциация между классами Flight (Рейс) и Passenger (Пассажир)
имеет кратность “многие ко многим”. Однако, если класс Flight квалифицировать с
помощью атрибутов seat_nuniber (место) и departure (отправление), то кратность
ассоциации снижается до значения “один к одному” (рис. 5.12). Составной ключ ин-
декса, введенный с помощью квалификатора (flight_number + seat_number +
departure), может быть связан только с одним объектом Passenger либо не связан
вообще ни с одним объектом этого класса.
Рис. 5.12. Квалифицированная ассоциация
При прослеживании связи в прямом направлении кратность ассоциации пред-
ставляет количество целевых объектов, связанных с составным ключом
(квалифицированный объект + значение квалификатора). При прослеживании связи
в обратном направлении кратность ассоциации описывает количество объектов, обо-
значенных составным ключом (квалифицированный объект + значение квалифика-
тора) и связанных с каждым целевым объектом [76].
Уникальность в идентификации объектов, вводимая за счет использования квали-
фикаторов, зачастую представляет собой важную семантическую информацию, кото-
рую невозможно эффективно получить другими способами (такими как ограничение
или добавление дополнительных атрибутов в целевой класс). В общем случае дубли-
ровать атрибут квалификации в целевом классе нежелательно.
j Обратитесь к наставлению по Internet-магазину в главе 2 и к диаграмме классов на рис. 2.32 ;
(разд. 2.2.4.Б). Рассмотрите часть модели, включающую классы Order и Computer. .
Измените ассоциацию между классами Order и computer на составную ассоциацию г
для явного представления ограничения: “в каждом заказе на компьютер отводится одна
позиция заказа”. >
Как мы помним, компьютер заказывается после того, как клиент составит специфика-
цию на него. Каждая такая конфигурация может быть обозначена уникальным номером.
Стандартной конфигурации также можно присвоить уникальный номер. Поэтом}’ атрибут
номера конфигурации configuration_number представляет собой квалификатор для
объекта-заказа Order. Составной ключ (order_number + configuration_number) свя-
зывает заказсодним объектом Computer (рис. 5.13).
206 Глава 5. Углубленный анализ
___________Order____________
Bjorder number: String
Border date: Date
Bshlp address: String
Border total: Currency
Border status: String
(^salesperson name: String
| configurationjd: Integer)
0?7l
1 _____________
_________Computer
Bcomputer name: String
BgetConf()
Puc. 5.13. Квалифицированная
ассоциация (Internet-магазин)
5.1.7. Ассоциативный класс или
материализованный класс
В разделе 2.1.3.4 мы рассмотрели и привели пример ассоциативного класса— ассо-
циации, которая сама является классом. Ассоциативный класс обычно используется в
тех случаях, когда между двумя классами существует ассоциация “многие ко многим” и
каждый экземпляр ассоциации (связь) обладает собственными значениями атрибутов.
Чтобы обеспечить возможность хранить эти атрибуты, требуется класс — ассоциатив-
ный класс.
На первый взгляд простая концепция ассоциативного класса таит в себе хитрое
ограничение. Рассмотрим ассоциативный класс С между классами А и В. Ограничение
состоит в том, что для каждой пары связанных экземпляров классов А и В может суще-
ствовать только один экземпляр класса С.
Если подобное ограничение неприемлемо, специалист по моделированию должен
материализовать ассоциацию, заменив класс С обычным классом D [76]. Материализм
ванный класс (reified class) D допускает две бинарные ассоциации с классами А и В. Класс D
не зависит от классов А и В. Каждый экземпляр D обладает своей собственной идентич-
ностью, так что при необходимости можно создать несколько экземпляров этого класса
для того, чтобы установить связь между одними и теми же экземплярами классов А и В.
5.1.7.1. Постановка задачи для примера с базой данных
сотрудников
Для объяснения различий между ассоциативным классом и материализованным
классом нам потребуется специальный пример. Пример касается ведения учета теку-
щей и прошлой зарплаты сотрудников. Конечно, различия между ассоциативным
классом и материализованным классом чаще всего проявляются в контексте модели-
рования временной (хронологической) информации.
5.1. Углубленное моделирование классов 207
Каждому сотруднику в организации присвоен уникальный идентификатор emp_id. Имя
сотрудника хранится в виде имени, фамилии и инициалов второго имени.
Каждому сотруднику в штатном расписании определен уровень его заработной платы.
Для каждого уровня существуют вилки окладов, т.е. минимальная и максимальная зар-
плата. Вилки окладов для данного уроаня никогда не изменяются. Если возникает необ- i
ходимость изменить минимальную или максимальную зарплату, создается новый уро- |
вень зарплаты. Кроме того, в организации хранятся начальная и конечная даты введения Г
каждого уровня зарплаты. j
В организации хранятся все предыдущие значения зарплаты сотрудника, включая на- i
чальную и конечную даты установления ему определенного уровня зарплаты. Любые ;
изменения зарплаты сотрудника в рамках одного и того же уровня также фиксируются. (
5.1.7.2. Модель, использующая ассоциативный класс
При порождении объектов ассоциативного класса им — подобно объектам любого
обычного класса— присваиваются уникальные идентификаторы (OID) (разд. 2.1.1.3).
Помимо системных OID объекты можно также идентифицировать по значениям их
атрибутов. В случае ассоциативного класса источником идентичности объекта явля-
ются атрибуты, которые обозначают ассоциированные классы (разд. 2.1.2.1.1). Зна-
чения других атрибутов не способствуют идентификации объекта.
к приведенной выше постановке задачи для примера База данных сотруд-
Постройте для нее модель классов. Используйте при этом ассоциативный класс.
Рис. 5.14. Неадекватное использование ассоциативного
класса (База данных сотрудников)
Постановка задачи для примера создает некоторые проблемы. Мы знаем, что нам
требуется класс для хранения подробной информации о сотруднике (Employee), а
также класс для хранения информации об уровнях зарплаты (SalaryLevel). Про-
208 Глава 5. Углубленный анализ
блема состоит в моделировании текущих назначений зарплаты работникам, а также
хронологии этих назначений. На первый взгляд кажется естественным использовать
ассоциативный класс SalaryHistoryAssociation.
На рис. 5.14 представлена модель классов, в которой использован ассоциативный
класс SalaryHistoryAssociation. Подобное решение неадекватно. Идентичность
объектов SalaryHistoryAssociation выводится на основании составного ключа,
созданного с использованием ссылок на первичные ключи классов Employee и
SalaryLevel (т.е. emp_idH level_id).
Никакие два объекта SalaryHistoryAssociation не могут иметь одинаковых
составных ключей (т.е. одинаковых связей с объектами Employee и SalaryLevel).
Это также означает, что проект диаграммы на рис. 5.14 не обеспечивает выполнение
требования “Любые изменения зарплаты сотрудника в рамках одного и того же уров-
ня также фиксируются”. Решение, показанное на рис. 5.14, не может рассматриваться
как удовлетворительное— требуется более корректная модель.
5.1.7.3. Модель, использующая материализованный класс
Ассоциативный класс не может иметь дублирующихся ссылок на объекты ассо-
циированных классов. Материализованный класс независим от ассоциированных
классов, и подобное ограничение на него не распространяется. Первичный ключ ма-
териализованного класса не использует атрибутов, обозначающих связанные классы.
\ Обратитесь к постановке задачи для примера База данных сотрудников (разд. 5.1.7.1). ;
j Постройте для нее модель классов. Используйте при этом материализованный класс. |
V .. ....................................... .................... .... .J
Рис. 5.15. Лучшее решение на основе материализованного
класса (База данных сотрудников)
5.2. Иерархия классов 209
5.2. Иерархия классов
Разработчики ПО знают, что трудность разработки небольшой системы не идет ни
в какое сравнение с трудностью поставки крупномасштабного решения. Небольшие
объектные системы зачастую легче понять, реализовать и развернуть. Для масштаб-
ных объектных решений характерны сложные сетевые структуры объектов, реаги-
рующих на случайные события, которые вызывают переплетающиеся цепочки взаи-
мосвязанных операций (методов). В отсутствие четкого архитектурного проекта и
строго определенного процесса разработки крупные программные проекты вполне
могут завершиться провалом.
Хорошо известный принцип когнитивной психологии — правило 7±2— гласит, что
кратковременная память человеческого мозга может одновременно справиться при-
близительно с девятью (7±2) предметами (графическими элементами, идеями, поня-
тиями и т.д.). Нижняя граница, равная пяти (7-2), указывает на то, что работа, менее
чем с пятью предметами, составляет тривиальную проблему.
Правила когнитивной психологии не в состоянии повлиять на тот факт, что нам
необходимы большие системы, а большие системы сложны. Значительная часть этой
сложности привнесена человеком, а не присуща самой системе (разд. 1.1.1).
Главным виновником тут выступает системное моделирование, которое допускает
неограниченное взаимодействие объектов. В подобных системах объекты образуют
сетевые структуры — “паутину” объектов, образованную перекрестными ссылками. Эти
ссылки образуют пути передачи сообщений. Возможны обращения к нижележащим и
вышележащим объектам. В сетевых структурах количество возможных путей взаимо-
действия между объектами с появлением в системе новых объектов растет экспонен-
циально. Как замечает Шиперски (Szyperski): “...объектные ссылки порождают связи
над произвольными областями абстракции. Поэтому верный выбор уровней приме-
нительно к системной архитектуре становится проблематичным, если вообще воз-
можным” [88].
Удачные системы организованы по иерархическому принципу — при этом сетевые
структуры оказываются ограниченными и тщательно контролируются. Применение
иерархических структур позволяет снизить степень сложности с экспоненциальной до
полиномиальной. Они вносят в систему уровни (или слои) объектов и ограничивают
взаимодействие между уровнями. В типичной иерархии непосредственно взаимодей-
ствуют только объекты соседних уровней. Таким образом удается скрыть сложность и
разнести ее по разным уровням.
5.2.1. Сложность сетевых структур
Прежде чем приступить к рассмотрению сложности объектных систем, необходи-
мо договориться о мере этой сложности. Как измерить сложность? Сложность разно-
образна и принимает разные формы. Простой, но очень показательной мерой слож-
ности может выступать количество соединений между классами. Соединение (connection)
определяется как существование постоянной или временной связи между классами
(разд. 2.1.1.3).
Каждое соединение обычно допускает двунаправленное взаимодействие классов, т.е.
от А к В и от В к А. Рис. 5.16 иллюстрирует сложность сети, состоящей из семи классов.
Между п классами существует п(п-1)/2 возможных соединений. Применение этой
формулы к нашему случаю дает в итоге 21 соединение (42 пути взаимодействия).
210 Глава 5. Углубленный анализ
Обратите внимание, что сложность измерялась по отношению к классам, а не объ-
ектам. В программах именно объекты, а не классы, пересылают сообщения другим
объектам того же или другого класса. Это создает для программиста, ответственного
за разработку логики программы и управление программными переменными и други-
ми структурами, дополнительные трудности. Однако основная проблема заключается
не в сложности отдельной программы, а в сложности всей системы программ.
Объект может отправить сообщение другому объекту лишь при наличии между
ними постоянной или временной связи. Временные связи разрешаются в пределах
однократного вызова программы, и поэтому они не усложняют систему в целом. С
другой стороны, постоянные связи существуют только при наличии соединения
(например, ассоциации), определенного в модели классов. Классы могут совместно и
многократно использоваться во многих программах.
Рис. 5.16. Сложность сетевых структур
5.2.2. Сложность иерархических структур
Решение проблемы управления сложностью состоит в редукции сетевой структуры
за счет группирования классов в виде иерархии классов. При этом подходе классы могут
естественным образом упорядочиваться в виде уровней, которые подчеркивают ие-
рархическое разбиение между уровнями, делая в то же время возможным взаимодей-
ствие внутри уровней наподобие сетевого.
Разделение на уровни иерархии дает возможность снизить сложность за счет огра-
ничения количества возможных путей взаимодействия между объектами. Это снижение
сложности достигается посредством разделения классов на уровни и разрешения непо-
средственного взаимодействия классов внутри уровня и между соседними уровнями.
Рис. 5.17 иллюстрирует сложность иерархии, составленной из семи классов, при
этом классы сгруппированы в четыре уровня. По сравнению с сетевой структурой,
показанной на рис. 5.16, сложность понизилась с 42 до 26 путей взаимодействия.
Пример на рис. 5.17 придуман в соответствии с четырьмя уровнями, предлагаемы-
ми в нашем подходе BCDE, который рассматривается в разд.6.1.3.2. В иерархической
структуре с большим количеством классов количество межуровневых соединений может
вызывать затруднения. Для уменьшения сложности межуровневых соединений межу-
5.2. Иерархия классов 211
ровневые взаимодействия могут быть направлены через несколько специально пред-
назначенных для этого классов-посредников. Это в еще большей степени снижает общую
сложность системы.
Рис. 5.17. Сложность иерархических структур
5.2.3. Пакеты
Для представления групп классов (или других элементов моделирования, напри-
мер, прецедентов) в языке UML предусмотрено понятие пакета (package) [76]. Пакеты
служат для разделения логической модели прикладной программы. Они представля-
ют собой кластеры (блоки) сильносвязанных классов, которые сами образуют некое
единое целое, но слабо связаны с другими подобными кластерами [48].
Пакеты могут быть вложенными. Это позволяет осуществлять декомпозицию боль-
ших систем на подсистемы, модули и т.д. Например, пакет, обозначенный как стерео-
тип «system», может содержать пакеты, обозначенные в виде стереотипа
«subsystem». Внешний пакет обладает доступом к любому классу, который непосред-
ственно содержится в его вложенных пакетах.
Классом может владеть только один пакет. Это не препятствует появлению класса в
других пакетах или взаимодействию с классами в других пакетах. Используя объявление
класса внутри пакета как закрытого, защищенного или открытого, можно контролиро-
вать взаимодействие и зависимости между классами в разных пакетах (разд.5.1.4).
5.2.3.1. Обозначение пакетов
Пакет изображается в виде пиктограммы папки (рис. 5.18). Вложенные пакеты
изображаются внутри внешнего пакета. Для каждого пакета должна быть построена
собственная диаграмма классов, определяющая все классы, принадлежащие пакету.
Пакеты могут быть связаны с двумя типами отношений: обобщением и зависимостью.
В качестве отношения на рис. 5.18 показана зависимость. Из рисунка видно, что пакет
NestedPackage зависит от пакета Package2. Точный характер зависимости не зада-
ется, за исключением, скажем, ситуации, когда изменения для Package2 могут потре-
212 Глава 5. Углубленный анализ
бовать внесения изменений в пакет NestedPackage. Пожалуй, наиболее часто зави-
симость между пакетами обусловлена тем, что класс одного из пакетов отправляет со-
общение классу другого пакета.
Рис. 5.18. Пакеты и зависимости
В языке UML определено несколько разных категорий отношения зависимости
(например, зависимость по использованию, зависимость по доступу, зависимость по
видимости). Мы считаем, что определение категории зависимости не приносит
большой пользы для диаграмм анализа. Истинный характер каждой зависимости дол-
жен быть зафиксирован как описательное ограничение в CASE-репозитории для ис-
пользования в проектных моделях.
Обратите внимание, что отношение обобщения между пакетами предполагает
также зависимость. Эта зависимость направлена от пакета подтипа к пакету суперти-
па. Изменения в пакете супертипа вызывают изменения в пакете подтипа.
5.2.3.2* Диаграммы пакетов
Понятия диаграммы пакетов как таковой в UML не существует, тем не менее этот
термин удобен для использования. Пакеты создаются в диаграмме классов или диаграм-
ме прецедентов. В первом случае диаграмма пакетов представляет модель системы с
точки зрения ее состояний. Во втором случае — с точки зрения поведения системы. По-
сле того, как пакет создан, назначение классов (или прецедентов) пакету должно быть
предусмотрено в отдельной диаграмме классов (или диаграмме прецедентов).
Без сомнения, диаграмма пакетов для состояний описывает архитектурную основу
системы. Поведенческая диаграмма пакетов служит только в качестве описания высо-
коуровневой функциональной структуры [15]. Диаграмма пакетов для состояний по-
могает в управлении масштабами и сложностью системы. Она также играет важную
роль в качестве механизма доступа и конфигурационного управления, способствую-
щего сотрудничеству разработчиков. ;
На рис. 5.19 показаны три пакета и Отношения зависимости между ними. Пакет
Enrolment зависит от пакетов Marking и Timetable.
5.2. Иерархия классов 218
бпитивнививнннннвц
Более пристальный взгляд на приложение Запись на университетские курсы показыва- j
ет, что система должна быть “осведомлена" о расписании занятий и степенях студентов, >
чтобы иметь возможность проверить обоснованность записи студентов в группы.
5
Нам неизвестно, существуют ли “расписание" (“marking”) и “выставление оценок” <
(“timetable") в качестве отдельных программных модулей, в которые может быть помещена *
наша система записи на курсы. Если это не так, то система записи на курсы должна вклю- J
чать подобные модули.
Наша задача состоит в том, чтобы построить модель пакетов для приложения Запись на '
университетские курсы.
Рис. 5.19. Пакеты (Запись на университетские курсы)
5.2.4. Подход ВСЕ
Подход ВСЕ (Boundary-Control-Entity — граница-управление-сущность) представ-
ляет собой подход к объектному моделированию, основанный на трехфакторном
представлении классов. Подходу ВСЕ до некоторой степени можно сопоставить хо-
рошо известный подход MVC (Model-View-Controller — модель-представлсние-
контроллер) [14], [11], [59]. В языке UML на классах предопределены три стереоти-
па: boundary (граница), control (управление) и entity (сущность) [76]. Это и определи-
ло выбор аббревиатуры ВСЕ.
Пограничные классы (boundary class) описывают объекты, которые представляют ин-
терфейс между субъектом и системой. Они выделяют часть состояния системы и
представляют ее пользователю в форме визуального отображения или звукового эф-
фекта. Пограничные объекты часто сохраняются после однократного выполнения
программы.
Управляющие классы (control class) описывают объекты, которые перехватывают
входные события, инициированные пользователем, и контролируют выполнение
бизнес-процесса. Управляющий класс представляет действия и виды деятельности
прецедентов. Управляющие объекты зачастую не сохраняются После выполнения
программы.
Классы-сущности (entity class) описывают объекты, которые представляют семантику
сущностей, принадлежащих проблемной области. Они соотносятся со структурами
данных системной базы данных. Объекты-сущности всегда сохраняются после выпол-
нения программы и участвуют во многих прецедентах.
214 Глава 5. Углубленный анализ
Как показано на рис. 5.20, в верно спроектированной иерархии пакетов субъект
может взаимодействовать только с пограничными объектами из пакета
Boundarypackage, объекты-сущности из пакета Entitypackage могут взаимодейст-
вовать только с управляющими объектами из ControlPackage и управляющие объ-
екты из ControlPackage могут взаимодействовать со объектами любого типа [ 15].
Рис. 5.20. Соединение объектов в иерархии пакетов ВСЕ
Пограничные классы соответствуют классам, представленным в разработанном
GUI-интерфейсе. Пограничные объекты зависят от объектов-сущностей (через неко-
торые управляющие объекты). Объекты-сущности распространяют изменения на
свои состояния, так что пограничные объекты могут обновить отображение GUI-
интерфейса. Говорят, что “пограничный слой” (экран) поврежден, если он временно
не синхронизирован с состоянием соответствующих сущностей проблемой области.
Управляющие объекты манипулируют взаимодействиями между событиями, ини-
циированными пользователями, и воздействуют на объекты-сущности и пограничные
объекты. В частности, каждому пограничному объекту, который допускает взаимо-
действие, должен быть поставлен в соответствие связанный с ним управляющий объ-
ект. Поэтому некоторые типы архитектуры ПО объединяют две функции в одном
классе. В качестве примера можно привести библиотеку MFC (Microsoft Foundation
Classes— библиотека базовых классов Microsoft).
Подход ВСЕ— это “способ мышления”, который воплощает в себе лучшие дости-
жения практики разработки ПО. Поэтому он должен быть составной частью любого
объектно-ориентированного метода разработки приложений вне зависимости от то-
го, подкрепляется ли он базовой платформой реализации.
• Основным преимуществом подхода ВСЕ является группирование классов в виде
иерархических уровней. Это способствует лучшему пониманию модели и уменьшает
ее сложность. Это также позволяет снизить риск создания классов, которые берут на
себя слишком много функций, классов-“монстров”, контролирующих работу всей сис-
темы. Хороший объектно-ориентированный проект отличает равномерное распреде-
ление “системного интеллекта” по всем классам.
Дополнительным преимуществом подхода ВСЕ является его увязка с трехзвенной
моделью клиент/сервер, которая отделяет управление данными (объекты-сущности) от
представления (пограничные объекты) посредством промежуточного слоя логики
приложения (управляющие объекты). Сервер баз данных может даже быть реализо-
ван не на объектно-ориентированной, а на реляционной СУБД.
Следует, однако, подчеркнуть, что пакет EntityPackage описывает классы-
сущности, которые располагаются в памяти клиентской программы, а не на сервере ба-
5.3. Углубленное моделирование обобщения и наследования 215
зы данных. Затем постоянные бизнес-объекты запоминаются в виде записей реляцион-
ных таблиц. Чтобы осуществить отображение классов-сущностей в реляционную память
СУБД и для хранения другой релевантной информации о структурах баз данных, требу-
ется отдельный уровень (слой) классов, которые организованы в виде пакета, предна-
значенного для работы с базой данных — DatabasePackage (разд.6.1.3.2).
5.3. Углубленное моделирование обобщения
и наследования
Существует три основных вида отношений между классами: ассоциация, агрегация
и обобщение. Внимательный читатель мог заметить, что полезность обобщения для
моделей анализа была подвергнута сомнению. Обобщение— полезная и мощная кон-
цепция, однако, она также может стать источником множества проблем из-за сложно-
сти механизмов наследования, в частности, в крупных программных проектах.
Понятия обобщения и наследования связаны, но не идентичны. Важно понимать
разницу между ними. Ценой неточности в определении этих понятий является часто
явно демонстрируемое в литературе недопонимание их различия. Конечно, до тех
пор, пока это различие не осознано, легко впасть в бессмысленную и безоснователь-
ную дискуссию, касающуюся доводов за и против обобщения и наследования.
Обобщение— это семантическое отношение между классами. Оно устанавливает, что
интерфейс подкласса должен включать все (открытые и защищенные) свойства супер-
класса. Наследование— это “механизм, с помощью которого более специфические эле-
менты вбирают в себя структуру и поведение, определенные более общими элемента-
ми” [76].
5.3.1. Обобщение и подставимость
С точки зрения семантики моделирования обобщение вводит в модель дополнитель-
ные классы, разделяет их на общие и более специфические классы и устанавливает
отношения суперкласс-подкласс. Хотя обобщение и вводит новые классы, оно может
уменьшить общее количество отношений ассоциации и агрегации в модели.
Исходя из требуемой семантики, ассоциативная или агрегативная связь класса мо-
жет указывать на наиболее общий класс иерархии обобщения (см. диаграммы классов
на рис. 2.31 и 4.7). Поскольку подкласс может быть подставлен вместо его родитель-
ского класса, объекты подкласса связаны всеми отношениями ассоциации и агрегации
суперкласса. Это позволяет зафиксировать ту же семантику модели с помощью мень-
шего количества отношений ассоциации/агрегации. Хорошая модель подразумевает
верный выбор компромисса между глубиной обобщения и уменьшением количества
отношений ассоциации/агрегации, являющегося следствием обобщения.
При продуманном использовании обобщение способствует повышению уровня
выразительности, понятности и абстрактности системных моделей. Источником
преимуществ обобщения служит принцип подставимости (substantiability)— объект под-
класса может быть использован вместо объекта суперкласса в любом месте програм-
мы, где объект подкласса имеет доступ к объекту суперкласса. Однако, к сожалению,
существуют такие способы использования механизма наследования, которые могут
свести на нет все преимущества принципа подставимости.
216 Глава 5. Углубленный анализ
5.3.2. Наследование или инкапсуляция
Инкапсуляция требует, чтобы доступ к атрибутам объекта был возможен только че-
рез операции интерфейса объекта. Результатом применения инкапсуляции является
высокая степень независимости данных, так что изменения, затрагивающие инкапсу-
лированные структуры данных, не требуют внесения изменений в существующие про-
граммы. Но в какой мере идея инкапсуляции осуществима в приложениях?
В действительности инкапсуляция ортогональна наследованию и возможностям
запросов, и поэтому необходимо достижение определенного компромисса между ин-
капсуляцией и последними двумя свойствами. На практике, объявить все данные как
закрытые невозможно.
Наследование подрывает основы инкапсуляции, разрешая подклассам осуществлять
непосредственный доступ к защищенным атрибутам. Для вычислений, охватывающих
объекты, принадлежащие различным классам, может потребоваться, чтобы различ-
ные классы были дружественными друг другу, что приводит к еще большему наруше-
нию инкапсуляции. Иногда должны использоваться статические атрибуты, являю-
щиеся глобальными по отношению ко всем объектам класса. И, поскольку всем ясно,
что инкапсуляция касается понятия класса, а не объекта — в большинстве программ-
ных сред (за исключением языка Smalltalk) объект не может скрыть ничего от другого
объекта того же класса.
Наконец, пользователи, осуществляющие доступ к базам данных с помощью
средств языка SQL’или SQL-подобных языков незапланированных запросов, вполне спра-
ведливо ожидают, что им придется обращаться в запросах непосредственно к атрибу-
там, а не испытывать необходимость работать с методами доступа к данным, которые
делают формирование запросов более трудным и более подверженным ошибкам. Это
требование особенно справедливо в отношении приложений хранилищ данных, свя-
занных с интерактивной аналитической обработкой запросов (OLAP — OnLine Ana-
lytical Processing).
Приложения должны разрабатываться таким образом, чтобы достичь требуемого
уровня инкапсуляции и при том соблюсти компромисс в отношении наследования,
незапланированных запросов и вычислительных требований.
5.3.3. Наследование интерфейса
Когда обобщение используется с целью обеспечения подставимости, оно может
служить синонимом понятия наследование интерфейса (порождения подтипа, наследова-
' ниЯ типа). Это, -Пак сказать; “безопасный” вид наследования. Подкласс наследует типы
атрибутов и сигнатуру операций (имя операции плюс формальные аргументы). Гово-
рят,'что подкласс'поддерживает интерфейс Суперкласса. Реализация унаследованных
операций откладывается на более позднее время.
Обычно интерфейсы объявляются посредством абстрактного класса. Можно сказать, с
’ЬдНой Оговоркой,'что интерфейс является абстрактным классом. Оговорка состоит в
'ТОм, Что абстрактный' класс МоДсет обеспечить частичную реализацию для некоторых
операций, в то время как чистый интерфейс откладывает определение всех операций.
На рис. 5.21 Представлен фрагмент модели классов для приложения Телемаркетинг,
который демонстрирует наследование интерфейса. Computer — это абстрактный
Класс. Объекты этого класса не могут быть объектами-экземплярами. Операция
getConf () получает две различные реализации: одну в классе ConfiguredComputer,
а другую в Standardcomputer.
5.3. Углубленное моделирование обобщения и наследования 217
На рис. 5.22 показан альтернативный способ представления наследования интер-
фейса с использованием символа “леденца на палочке” для обозначения поддержи-
ваемого интерфейса. Это отношение “леденец на палочке”, исходящее из подкласса
(конкретизированного класса) к абстрактному классу, формально называется отноше-
нием реализации (realization relationship).
Рис. 5.21. Наследование интерфейса
Computer_____
Bcomputer name: String
^getConf()
Рис. 5.22. Использование отношения реализации для представления насле-
дования интерфейса
5.3.4. Наследование реализации
Как было отмечено в предыдущем разделе, использование обобщения может под-
разумевать подставимость с последующей ее реализацией за счет наследования интер-
фейса. Однако использование обобщения может также подразумевать (сознательно
или нет) повторное использование программного кода (code reuse) с последующей его реали-
зацией за счет наследования реализации. Это очень мощная, иногда даже опасная по си-
ле, интерпретация обобщения. Кроме того, эта интерпретация обобщения принята
“по умолчанию”.
Наследование реализации— называемое также выведением подкласса, .наследованием кода
или наследованием класса — объединяет свойства суперкласса в подклассах и позволяет
при необходимости замещать их новыми реализациями. Замещение (overriding) может
означать включение (вызов) метода суперкласса в метод подкласса и расширение его
за счет введения 'новых функциональных возможностей. Оно также может означать
полную замену метода суперкласса методом подкласса. Наследование реализации до-
пускает совместное использование описаний свойства, повторное использование про-
граммного кода и полиморфизм.
218 Глава 5. Углубленный анализ
При использовании в процессе моделирования обобщения необходимо четко от-
давать себе отчет в том, какой именно вид наследования подразумевается. Использо-
вание наследования интерфейса безопасно только в том случае, если оно касается на-
следования фрагментов контракта — сигнатуры операций. Наследование реализации
касается наследования кода — наследования фрагментов реализации [88], [34]. Если
его тщательно не контролировать и не ограничивать, наследование реализации мо-
жет принести больше вреда, чем пользы. Теперь мы приступим к обсуждению доводов
за и против наследования реализации.
5.3.4.1. Правильный способ использования наследования
реализации — наследование посредством расширения
Что касается увязки наследования с обобщением и надлежащего использования
наследования реализации, язык UML довольно определенно трактует эти вопросы
[76]. Единственным правильным способом использования наследования является на-
ращиваемое определение класса. Подкласс обладает большим количеством свойств
(атрибутов и/или методов), чем его суперкласс. Подкласс — “это нечто вроде” супер-
класса. Подобное наследование известно также как наследование посредством расширения
или расширяющее наследование (extension inheritance).
На рис. 2.17 (повторенном здесь для удобства как рис. 5.23) представлен пример
расширяющего наследования. Каждый объект Employee (Сотрудник) — это нечто вро-
де объекта Person (Личность). Это не означает, что объект Employee одновременно
является экземпляром двух классов: Person и Employee (см. обсуждение вопросов
множественного наследования в разд. 2.1.5.2.2). Объект Employee — это экземпляр
класса Employee.
Класс Person на рис. 5.23— это не абстрактный класс. Могут существовать неко-
торые объекты Person, которые представляют просто некую личность (в том смысле,
что они не являются сотрудниками, т.е. объектами класса Employee).
Расширяющее наследование требует внимательного отношения к использованию
замещения свойств. Допустимым считается только придание свойствам большей опре-
деленности (например, ограничение допустимых значений или более эффективная
реализация операции), но никак не изменение значения свойства. Если замещение
приводит к изменению значения свойства, объект подкласса не может быть больше
подставлен вместо объекта суперкласса.
5.3.4.2. Проблематичный способ использования наследования
реализации — наследование посредством ограничения
При использовании расширяющего наследования определение подкласса расши-
ряется за счет введения новых свойств. Однако наследование можно также использо-
вать в качестве ограничивающего механизма, посредством которого некоторые унас-
ледованные свойства подавляются (замещаются) в подклассе. Подобное наследование
называется наследованием посредством ограничения или ограничивающим наследованием
(restriction inheritance) [74].
На рис. 5.24 приведены два примера ограничивающего наследования. Поскольку
наследование нельзя блокировать выборочно, класс окружностей Circle должен
унаследовать свойства главной и дополнительной осей— minor_axis и
major_axis— от эллипса Ellipse и заменить их атрибутом диаметра diameter.
Аналогично, подкласс Penguin (Пингвин) должен унаследовать способность летать
(операцию fly) от класса птиц Bird и заменить ее на операцию плавания swim
5.3. Углубленное моделирование обобщения и наследования 219
(пожалуй, полет на “отрицательной” высоте можно с некоторой натяжкой трактовать
как плавание).
Ограничивающее наследование проблематично. С точки зрения обобщения под-
класс не включает все свойства суперкласса. Объект суперкласса по-прежнему может
быть заменен на объект подкласса при условии, что тот, кто использует объект, знает
о замещенных (подавленных) свойствах.
При ограничивающем наследовании свойства класса используются (с помощью
наследования) для реализации другого класса. Если замещение не носит всеобъемлю-
щего характера, ограничивающее наследование может принести определенные выго-
ды. Однако, в общем случае ограничивающее наследование вызывает проблемы при
сопровождении.
Рис. 5.23. Расширяющее
наследование
Рис. 5.24. Ограничивающее
наследование
220 Глава 5. Углубленный анализ
5.3.4.3. Неверный способ использования наследования
реализации — наследование по удобству
. Если в процессе системного моделирования оказывается, что наследование нельзя
отнести к расширяющему или ограничивающему, оно воспринимается как “плохая
новость”. Подобный тип наследования встречается в тех случаях, когда два или более
классов обладают аналогичными реализациями, но при этом отсутствует отношение
таксономии между понятиями, представленными этими классами. Один из классов
произвольно выбирается в качестве прообраза другого. Этот вид наследования назы-
вается наследование по удобству (convenience inheritance) [54], [74J.
На рис. 5.25 приведено два примера наследования по удобству. Класс дуг
LineSegment определен как подкласс класса точек Point. Ясно, что дуга— это не
точка, и поэтому в данном случае обобщение в том виде, как оно было определено ра-
нее, неприменимо. Однако наследование все же можно использовать. Конечно, для
класса Point можно определить атрибуты координат xcoordinate и
y_coordinate и операцию перемещения Move. Класс LineSegment может унаследо-
вать эти свойства и может определить дополнительную операцию изменения разме-
ров Resize. Операцию Move необходимо заместить. Аналогично, во втором примере
класс автомобилей Саг наследует свойства класса мопедов Motorbike и добавляет
некоторые новые свойства.
Рис. 5.25. Наследование по удобству
., Наследование по удобству неприемлемо. Оно семантически некорректно. И при-
водит к масштабному замещению. Принцип подставимости, как правило, не работает,
поскольку объекты не принадлежат к подобным типам (дуга (LineSegment) — не точ-
ка (Point); автомобиль (Саг) — не мотоцикл (Motorbike)).
На практике, и к большому сожалению, разработчики часто используют наследо-
вание по удобству, поскольку многие объектные среды программирования поощряют
неразборчивость при использовании наследования реализации. Многие языки осна-
щены неисчислимыми средствами “усиления программирования” с помощью насле-
дования, в то время как поддержка других свойств объектов (в особенности агрега-
ции) отсутствует.
5.3. Углубленное моделирование обобщения и наследования 221
5.3.4.4. Недостатки наследования реализации
Сказанное выше вовсе не означает, что запрещение использования наследования
по удобству служит гарантией успеха. Использование наследования реализации —
рискованное дело по многим меркам. При отсутствии надлежащего контроля и управ-
ления наследование может использоваться чрезмерно или неверно и может создать
проблемы, которые требуют первоочередного решения. Это особенно справедливо
для разработки крупномасштабных систем, которые включают сотни классов и тыся-
чи объектов, отличаются динамизмом изменения состояний объектов и эволюцион-
ным характером структур классов (как, например, в случае типичных бизнес-
приложений).
Основные факторы риска связаны со следующими перечисленными ниже концеп-
туальными трудностями [88].
Изменчивость базового класса.
Замещение и обратные вызовы.
Множественное наследование реализации.
5.З.4.4.1. Изменчивый базовый класс
Проблема изменчивости базового класса (суперкласса) касается ситуации, при кото-
рой подклассы достигли определенного уровня зрелости и надежности, в то время как
реализация их суперкласса (или суперклассов при множественном наследовании) про-
должается. Это серьезная проблема в любом случае, а в особенности в ситуации, когда
суперкласс можно получить из внешних источников, находящихся вне контроля бри-
гады разработчиков системы.
Рассмотрим ситуацию, при которой суперклассы, которым наследует ваше прило-
жение, образуют часть операционной системы, СУБД или GUI-интерфейса. Если для
разработки вашего приложения вы приобретаете объектную СУБД, в действительно-
сти вы покупаете библиотеку для реализации типичных функций СУБД, таких как со-
хранение постоянных объектов, управление транзакциями, обеспечение параллель-
ности, восстановление после сбоев и т.д. Если разрабатываемые классы являются по-
томками библиотеки классов, то последствия от внедрения новой версии библиотеки
непредсказуемы (если при разработке модели наследования для приложения не выка-
зать предусмотрительности, то это несомненно так и есть).
С проблемой изменчивости базового класса трудно справиться, не объявив откры-
тые интерфейсы неизменяемыми или, по меньшей мере, не установив контроля над
наследованием реализации из суперклассов. Изменения в реализации суперклассов
(для которых может даже отсутствовать исходный текст программ) непредсказуемым
образом воздействуют на подклассы прикладной системы. Это справедливо даже то-
гда, когда интерфейс суперкласса остается неизменным. Ситуация может еще более
усугубиться, если изменения также сказываются на интерфейсах. Вот примеры по-
добных ситуаций [88].
Изменение сигнатуры метода.
Разделение метода на два или более новых методов.
Объединение существующих методов в виде более крупного метода.
222 Глава 5. Углубленный анализ
Практический вывод из сказанного можно сформулировать следующим образом.
Чтобы справиться с проблемой изменчивости базового класса, разработчики, проек-
тирующие суперкласс, должны заранее иметь представление о том, как будут действо-
вать люди при повторном использовании суперкласса сегодня и в будущем. Конечно,
узнать это, не прибегая к помощи гадалок, нельзя. Как гласит шутка, начертанная в
виде лозунга на бампере автомобиля: “сумасшествие не наследуется, оно достается вам
от ваших детей” [29]. В разд.5.4 рассматриваются некоторые альтернативные методы
объектной разработки, которые, не будучи основаны на наследовании, все же обеспе-
чивают требуемые функциональные возможности объектов.
5.3.4.4.2. Замещение и обратные вызовы
Наследование реализации допускает выборочное замещение унаследованного
программного кода. Ниже перечислены пять методов, с помощью которых метод
подкласса может повторно использовать код его суперкласса.
1. Подкласс может наследовать интерфейс и реализацию метода без внесения ка-
ких-либо изменений в реализацию.
2. Подкласс может наследовать код и включить его (вызвать его) в свой собствен-
ный метод с той же сигнатурой.
3. Подкласс может наследовать код и затем полностью заместить его новой реали-
зацией с той же сигнатурой.
4. Подкласс может наследовать пустой код (т.е. декларация метода отсутствует), а
затем ввести реализацию для метода.
5. Подкласс может наследовать только интерфейс метода (т.е. мы имеем случай
наследования интерфейса), а затем ввести реализацию для метода.
Из этих пяти методов первые два доставляют наибольшие трудности в случае
склонности программного кода базового класса к эволюции. Пятый метод выказывает
полное безразличие к наследованию. Последние два метода представляют особые
случаи — четвертый случай тривиален, а пятый не касается наследования реализации.
Обратитесь к приложению Телемаркетинг и, а частности, к примеру 5.4 (разд. 5.1.4.1). ;
Модифицируйте отношение обобщения между классами Campaign и BonusCampaign
таким образом, чтобы включить операции, которые служат примером первых трех мето-
дов повторного использования, перечисленных выше.
На рис. 5.26 приведен особый вариант отношения обобщения между классами
Campaign и BonusCampaign, призванный продемонстрировать три метода повтор-
ного использования. Этим методам соответствуют следующие операции:
getDateClose (получить дату завершения [кампании]), printTicketDetails (отпе-
чатать подробную информацию о билете) и computeTicketsLeft (подсчитать коли-
чество оставшихся билетов).
Реализация операции getDateClose {) наследуется классом BonusCampaign
и повторно используется им без изменений (это первый метод из приведенного
выше списка).
5.3. Углубленное моделирование обобщения и наследования 223
Две оставшиеся операции замещаются в классе BonusCampaign. На модели этот
факт отражается за счет дублирования имен операций в BonusCampaign. Предпола-
гается, что операция printTicketDetails представляет второй метод, т.е. метод
BonusCampaign .printTicketDetails () вызывает унаследованный метод
Campaign.printTicketDetails (), скажем, для печати общего количества билетов,
участвующих в кампании. Затем.он выводит на печать специфическую информацию о
призовых билетах, такую как количество билетных книжек и объем книжек.
Рис. 5.26. Наследование и замещение
(Телемаркетинг)
Теперь предположим, что операция computeTicketsLeft () представляет третий
метод повторного использования. Метод BonusCampaign.computeTicketsLeft ()
является наследником (поскольку это предусмотрено) метода Campaign. compute
TicketsLeft (), азатем полностью замещает унаследованный код.
Пример 5.12 демонстрирует влияние замещения на проблему изменчивости базо-
вого класса. Он также показывает, что наследование реализации приводит к возник-
новению сетеобразных структур для путей взаимодействия между объектами, кото-
рые, как было показано ранее, отличаются неустойчивостью в больших системах
(разд.5.2). При использовании наследования реализации передача сообщений может
возникать повсеместно. Помимо простых прямых вызовов сверху-вниз (down-calls) по ие-
рархии наследования, имеют место также и обратные вызовы (вызовы снизу-вверх)
(callbacks (up-calls)) (разд.6.2.2.8).
Как замечает Шиперский [88]: “В соединении с наблюдаемым состоянием это приво-
дит к семантике замкнутых вызовов, близкой той, которая характерна для параллельных
систем. Произвольный граф вызовов, формируемый сетью взаимодействующих объектов,
разрушает классическую схему иерархии уровней и делает замкнутые вызовы нормой.”
Ради справедливости следует заметить, что обратные вызовы возможны не только
между объектами, связанными отношениями наследования, а всюду, где существуют
ссылки между объектами. Вновь приведем замечание Шиперского [88]: “При наличии
объектных ссылок ... всякий вызов метода может рассматриваться как потенциальный
вызов снизу-вверх, каждый метод может быть потенциально связан с обратным вызо-
вом”. Наследование только вносит свой вклад в общую проблему, но, надо заметить,
вклад существенный.
224 Глава 5. Углубленный анализ
5.3.4.4.3. Множественное наследование реализации
Множественное наследование было введено в разд.2.1.5.2.1, однако, до сих пор мы не
проводили различия между множественным наследованием интерфейса (множественным на-
следованием от супертипов) и множественным наследованием реализации (множественным
наследованием от суперклассов). Множественное наследование интерфейса допускает
слияние контрактов интерфейсов. Множественное наследование реализации позволяет
объединить фрагменты реализации.
Множественное наследование реализации в действительности не создает каких-либо
дополнительных проблем наследования реализации. Оно скорее усугубляет пробле-
мы, вызванные изменчивостью базового класса, замещением и обратными вызовами.
Помимо требования блокировать наследование любых дублирующихся фрагментов
(когда два или более суперкласса определяют одну и ту же операцию), оно может так-
же вызвать необходимость переименовать операции всякий раз, когда повторяющие-
ся имена совпадают (а в действительности должны обозначать разные операции).
В этом контексте стоит напомнить о присущим системам росте сложности из-за
множественного наследования — росте, вызванном отсутствием поддержки множест-
венной классификации в объектных системах (разд.2.1.5.2.2). Любые ортогональные
ветви наследования, сходящиеся в одном суперклассе, должны объединяться в дереве
наследования на более низком уровне иерархии с помощью специально созданных
“объединяющих” классов (см. пример в разд.2.1.5.2.2).
5.4. Углубленное моделирование агрегации
и делегирования
Агрегация представляет собой третий метод связывания классов в моделях анализа
(разд.2.1.4). В сравнении с двумя другими методами (традиционной ассоциацией и обоб-
щением) агрегации уделялось меньше всего внимания. Тем не менее агрегация представ-
ляет собой наиболее мощный из известных нам методов управления сложностью больших
систем с помощью распределения классов по иерархическим уровням абстракции.
Агрегация (и ее боле сильный вариант— композиция) — отношение включения. Со-
ставной класс содержит один или более компонентных классов. Компонентный класс
является элементом одного или более составных классов. Компонентные классы явля-
ются элементами их составных классов (хотя элементы ведут свое собственное сущесг
вование). Хотя агрегация получила признание как фундаментальная концепция моде-
лирования, по меньшей мере, одновременно с обобщением, в объектно-ориенти-
рованном анализе и проектировании ей уделяется лишь незначительное внимание (за
исключением областей приложений наподобие систем мультимедиа).
В средах программирования (включая большинство объектных СУБД) агрегация
реализуется так же, как традиционная ассоциация — с помощью запроса ссылок между
составными и компонентными объектами. Хотя структура времени компиляции для
агрегации аналогична структуре ассоциации, во время выполнения они ведут себя по-
разному. Агрегация обладает более строгой семантикой, и ответственность за то, что-
бы структуры времени выполнения удовлетворяли этой семантике, лежит (к сожале-
нию) на программисте.
5.4. Углубленное моделирование агрегации и делегирования 225
5.4.1. Расширение семантики агрегации
Хотя современные среды программирования игнорируют агрегацию, методы раз-
работки объектных приложений включают агрегацию среди прочих возможностей
моделирования, однако отводят ей последнее место. Кроме того (или вследствие не-
достаточной поддержки в средах программирования), методы разработки объектных
приложений не стремятся придать агрегативным конструкциям строгую семантиче-
скую интерпретацию, зачастую трактуя их просто как особую форму ассоциации.
Как рассматривалось в разд.4.2.3, можно выделить четыре возможных семантики
для агрегации [55].
1. Агрегация типа “Безраздельно обладает”.
2. Агрегация типа “Обладает”.
3. Агрегация типа “Включает”.
4. Агрегация типа “Член”.
UML признает только две семантики агрегации, а именно агрегацию (ссылочная
семантика) и композицию (семантика значений) (разд.2.1.4). Теперь будет показано,
каким образом можно использовать существующую нотацию UML для представления
четырех видов агрегации, указанных выше.
5. 4.1.1. Агрегация типа “Безраздельно обладает”
Агрегацию типа Безраздельно обладает можно представить в UML как композицию-
стереотип, обозначенную с помощью ключевого слова «ExclusiveOwns» и дополни-
тельно ограниченную с помощью ключевого слова (замороженный) [25]. Ограниче-
ние frozen применяется к компонентному классу. Оно констатирует, что объект ком-
понентного класса не может быть заново соединен ( в течение своего ЖЦ) с другим со-
ставным объектом. Компонентный объект может быть удален вовсе, но не может
переключиться на другого владельца.
На рис. 5.27 показано два примера агрегации типа Безраздельно обладает. Левая
часть рисунка представляет пример моделирования агрегации в UML с использова-
нием семантики значений (заполненный ромб), а правая часть — пример моделирова-
ния агрегации в UML с использованием ссылочной семантики (пустой ромб).
Рис. 5.27. Агрегация типа Безраздельно обладает
Объект Chapter (Глава) является частью, по меньшей мере, одного объекта
CopyrightedBook (Книга, защищенная авторским правом). Будучи включенным
226 Глава 5. Углубленный анализ
(по значению) в составной объект, он не может быть повторно соединен с другим
объектом CopyrightedBook. Соединение заморожено (за счет ограничения frozen).
Колода карт для игры в бридж (BridgeCardPack) содержит в точности пять-
десят две карты. Для моделирования принадлежности в UML используется ссы-
лочная семантика. Каждая карта для бриджа (объект BridgeCard) принадлежит в
точности одной колоде карт (BridgeCardPack) и не может быть повторно со-
единена с другой колодой карт.
5. 4.1.2. Агрегация типа “Обладает”
Аналогично агрегации типа Безраздельно обладает агрегацию типа Обладает можно
выразить в UML с помощью семантики значений композиции (заполненный ромб)
или ссылочной семантики агрегации (пустой ромб). В каждый момент времени ком-
понентный объект принадлежит по меньшей мере одному составному объекту, однако
он может быть заново соединен с другим составным объектом. При удалении составного
объекта его компонентные объекты также удаляются.
На рис. 5.28 показано два примера агрегации типа Обладает. Вода (объект Water)
может быть перелита из одного кувшина (объект Jug) в другой. Аналогично, шина
(объект Tire) может быть переставлена с одного велосипеда (Bicycle) на другой.
Благодаря зависимости по существованию, разрушение объекта Jug или Bicycle
распространяется вниз на их компонентные объекты.
Рис. 5.28. Агрегация типа Обладает
5. 4.1.3. Агрегация типа “Включает”
Для моделирования агрегации типа Включает в UML обычно используется ссы-
лочная семантика агрегации (пустой ромб). Агрегация типа Включает не содержит за-
висимости по существованию — удаление составного объекта не распространяется ав-
томатически вниз на компонентные объекты. Агрегацию типа Включает отличают та-
кие свойства, как транзитивность и асимметричность.
Пример агрегации типа Включает показан на рис. 5.29. Если тележка (объект
Trolley) включает несколько ящиков с пивом (BeerCrate), а каждый ящик с пивом
включает несколько бутылок с пивом (BeerBottle), то тележка также включает бу-
тылки с пивом (транзитивность). Если тележка включает ящики с пивом, то ящики с
пивом не могут включать тележку (асимметричность).
5.4. Углубленное моделирование агрегации и делегирования 227
Рис. 5.29. Агрегация типа Включает
5. 4.1.4. Агрегация типа “Участник”
Агрегация типа Участник допускает отношения с кратностью “многие ко многим ”. В
отношении свойств зависимости по существованию, транзитивности, асимметрии и ог-
раничения frozen не делается никаких специальных предположений. При необходимо-
сти любое из этих четырех свойств можно выразить в UML с помощью ограничения.
Благодаря кратности “многие ко многим”, агрегацию типа Участник можно моделиро-
вать в UML только с помощью ссылочной семантики агрегации (пустой ромб).
На рис. 5.30 показано четыре отношения агрегации типа Участник. JAD-совещание
(объект JADSession) (см. разд. 3.2.2.2) состоит из одного модератора и одного или
нескольких секретарей (Scribe), пользователей (User) и разработчиков
(Developer). Каждый компонентный “объект” может принимать участие, более чем в
одном JAD-совещан ии.
Рис. 5.30. Агрегация шипа Участник
5.4.2. Агрегация как альтернатива обобщению
Обобщение — это отношение суперкласс-подкласс. Агрегация больше напоминает
отношение супермножество-подмножество. Вопреки этому различию обобщение
можно представить как агрегацию.
Рассмотрим рис. 5.31. Заказы клиентов, которые не выполнены, могут ожидать не-
которых дальнейших действий. Заказ в состоянии ожидания может быть отложенным
заказом, который должен быть выполнен после пополнения запаса. Заказ в состоянии
228 Глава 5. Углубленный анализ
ожидания может быть заказом наперед, если он должен быть выполнен позднее, в
сроки, определенные клиентом.
Модель в левой части рисунка представляет собой обобщение заказов клиентов.
Класс Gorder (Заказ) может быть классом GPendingOrder (Ожидающий заказ).
Класс GPendingOrder может быть классом GBackOrder (Невыполненный заказ) или
классом GFutureOrder (Заказ наперед). Наследование гарантирует разделение атри-
бутов и операций вниз по дереву обобщения.
Аналогичную семантику можно смоделировать с помощью агрегации, показанной в
правой части рисунка 5.31. Классы ABackOrder и AFutureOrder включают атрибуты и
операции класса APendingOrder, которые, в свою очередь, включает класс AOrder.
Хотя две модели, показанные на рис. 5.31, отражают аналогичную семантику, меж-
ду ними существуют определенные различия. Одно из них вытекает из замечания, что
модель обобщения основана на понятии класса, в то время как модель агрегации фак-
тически сконцентрирована на понятии объекта.
Конкретный объект GBackOrder является также объектом класса и
GPendingOrder и Gorder. Для объекта GBackOrder существует один идентификатор
объекта (OID). С другой стороны, конкретный объект ABackOrder состоит из трех
отдельных объектов, каждый из которых обладает собственным идентификатором
объекта,— собственно объект ABackOrder, содержащийся в нем объект
APendingOrder и содержащийся в нем объект AOrder.
Обобщение использует наследование рая реализации его семантики. Агрегация ис-
пользует делегирование ддя повторного использования реализации компонентных объ-
ектов. Использование делегирования рассматривается в следующем разделе.
Рис. 5.31. Альтернатива: обобщение или агрегация
5.4.2.1. Делегирование и системы-прототипы
Вычислительная модель наследования основана на понятии класса. Однако можно
положить в основу вычислительной модели понятие объекта. Объектно-
ориентированная вычислительная модель структурирует объекты в виде агрегатив-
ных иерархий. Всякий раз, когда составной объект (внешний объект) не в состоянии
выполнить задание самостоятельно, он может вызвать методы одного из его компо-
нентных объектов (внутренних объектах) — это называется делегированием (delegation).
При подходе, основанном на делегировании, функциональные возможности систе-
мы реализуются с помощью включения (клонирования) функций существующих объек-
5.4. Углубленное моделирование агрегации и делегирования 229
тов во вновь требуемые функции. Существующие объекты трактуются как прототипы
для создания новых объектов. Идея состоит в том, чтобы сначала отыскать требуемые
функции в существующих объектах (внутренних объектах), а затем реализовать необхо-
димые функции во внешних объектах. Системы, построенные подобным способом из су-
ществующих объектов-прототипов, называются слиллемамитрототипами.
Объект может быть связан отношением делегирования с любым другим идентифици-
руемым и видимым объектом в системе [49]. Когда внешний объект получает сообщение и
не в состоянии выполнить обслуживание самостоятельно, он делегирует выполнение об-
служивания внутреннему объекту. При необходимости внутренний объект может пере-
слать сообщение любого из своих собственных внутренних объектов.
Интерфейсы внутреннего объекта могут быть видимы или невидимы для объек-
тов, отличных от внешнего объекта. Для контроля уровня видимости внутренних
объектов можно использовать четыре типа агрегации, определенные в разд.5.4.1. На-
пример, внешний объект может раскрыть интерфейс внутреннего объекта как свой
собственный в более слабой форме агрегации (например, в такой как агрегация типа
Включает или Участник). При более сильной форме агрегации внешний объект может
скрыть интерфейс своего внутреннего объекта от внешнего мира (вводя, таким обра-
зом, уровень инкапсуляции) .
5.4.2.2. Делегирование или наследование
Покажем, что с помощью делегирования можно моделировать наследование и на-
оборот. Это значит, что одни и те же функциональные возможности можно реализо-
вать как с помощью наследования, так и делегирования. Согласие в этом вопросе
впервые было достигнуто на конференции в США в городе Орландо, штат Флорида, в
1987 году и теперь известно как Орландское соглашение [81].
Мы уже касались изъянов наследования реализации. В связи с этим возникает на-
стоятельный вопрос: позволяет ли делегирование избежать недостатков, присущих
наследованию реализации. Ответ на этот вопрос не очевиден [88].
С точки зрения повторного использования делегирование сильно приближено к на-
следованию. Внешний объект повторно использует реализацию внутреннего объекта.
Разница состоит в том, что — в случае наследования — после завершения обслужива-
ния управление всегда возвращается объекту, который получает исходное сообщение
(запрос на обслуживание).
В случае делегирования после того, как управление передано от внешнего объекта
внутреннему объекту, оно остается у последнего. Любая авторекурсия должна быть
явно запланирована и спроектирована в рамках делегирования. При использовании
наследования реализации авторекурсия всегда случайна — она не запланирована и на-
ложена как программная “заплата” [88]. Одним из нежелательных последствий неза-
планированного/“заплатанного” повторного использования является проблема измен-
чивости базового класса.
Еще одним потенциальным преимуществом делегирования является то, что разде-
ление и повторное использование можно определить динамически во время выпол-
нения приложения. В системах, ориентированных на использование наследования,
разделение и повторное использование обычно определяется статически при созда-
нии объекта. При этом достигается компромисс между безопасностью и скоростью
выполнения предусмотренного разделения наследования и гибкостью непредусмотренного
разделения делегирования.
230 Глава 5. Углубленный анализ
В пользу делегирования можно привести тот аргумент, что непредусмотренное
разделение более естественно и ближе к человеческому способу мышления [49]. Объ-
екты объединяются естественным способом для формирования масштабных решений
и могут эволюционировать непредвиденным образом. В следующем разделе приво-
дится другая точка зрения на эти же вопросы.
5.4.3. Агрегация и голоны — интеллектуальное орудие
В работах [54] и [55] с целью обуздания сложности объектных моделей был пред-
ложен новый подход для описания архитектуры ПО, основанный на интерпретации
естественных систем Артура Кёстлера (Arthur Koestler) [44], [45]. Центральной кон-
цепцией является идея так называемых “голонов” (“holons"), которые интерпретируют-
ся как объекты, являющиеся одновременно и частью и целым. Более точно они рас-
сматриваются как саморегулируемые сущности, которые проявляют одновременно
взаимозависимые свойства части и независимые свойства целого.
Живые системы обладают иерархической организацией. Структурно они представ-
ляют собой агрегации полуавтономных элементов, которые являют как независимые
свойства целого, так и взаимозависимые свойства части. По Артуру Кёстлеру они
представляют собой агрегации голонов от греческого слова holos, обозначающего целое
(англ, whole) с суффиксом, измененным на-он (on), означающим частицу или часть (как
в словах протон или нейтрон) [44].
Части и целое в абсолютном смысле не существуют в живых организмах и даже в
социальных системах. Голоны образуют иерархические уровни соответствующей
сложности, например, в биологических организмах можно различать иерархию ато-
мов, молекул, органоидов, клеток, тканей, органов и систем органов. Подобные ие-
рархии голонов называются голократиями.
Каждый уровень голократии скрывает свою сложность от вышележащего уровня.
Если смотреть сверху-вниз, голон представляет собой нечто законченное и уникальное,
целое. Если смотреть снизу-вверх, голон представляет собо(й элементарную компоненту,
часть. Каждый уровень голократии содержит множество голонов, например, атомов
(водород, углерод, кислород и т.д.), клетки (нервные волокна, клетки крови и т.д.).
Если смотреть изнутри, голон предоставляет услуги другому голону. Если смотреть
снаружи, голон запрашивает услуги у других голонов. Голократии отличаются неза-
вершенностью. Не существует абсолютных голонов-“листьев” или голонов-“верп1ип”
за исключением тех, которые мы специально обозначаем таким образом для удобства
интерпретации. Благодаря этим характеристикам, сложные системы могут эволю-
ционировать из простых систем.
Отдельные голоны, таким образом, представляются четырьмя характеристиками.
1. Его внутренние правила (взаимодействия между ними могут формировать уни-
кальные шаблоны).
2. Самоутверждающаяся агрегация подчиненных голонов.
3. Тенденция к интеграции по отношению к высшим голонам.
4. Отношения с соседними голонами.
Удачные системы упорядочены в виде голократий, которые скрывают сложность в
последовательных нижних уровнях и в то же время обеспечивают больший уровень
Резюме 231
абстракции в рамках более высоких уровней ее структур. Эта концепция соответству-
ет семантике агрегации.
Агрегация предусматривает разделение — позволяет каждому классу оставаться ин-
капсулированным и концентрироваться на специфическом поведении (кооперация и
услуги) класса способом, который не связан с реализаций его родительских классов
(как это имеет место для обобщения). В то же время агрегация позволяет свободное
перемещение между стратифицированными уровнями во время выполнения.
Баланс между интеграцией и самоутверждением объектов (голонов) достигается за
счет требования, согласно которому объекты должны “признавать интерфейсы друг
друга” [28]. Инкапсуляция не нарушается, поскольку объекты взаимодействуют только
посредством своих интерфейсов. Эволюция системы облегчается, поскольку взаимо-
действие объектов не запрограммировано жестко в реализации с помощью механиз-
мов, аналогичных наследованию.
Со структурной точки зрения агрегация дает возможность моделировать большие
сообщества объектов с помощью группирования их в виде различных множеств и уста-
новления между ними отношения часть-целое. С функциональной точки зрения агрега-
ция позволяет просматривать иерархию объектов (голонов) сверху-вниз и снизу-вверх.
Однако агрегация не позволяет моделировать необходимые возможности взаимо-
действия между голонами одного уровня так, чтобы они могли просматривать струк-
туру изнутри и извне. Этот структурный и функциональный разрыв можно преодо-
леть с помощью отношений обобщения и ассоциации.
В рамках рекомендуемого подхода агрегация обеспечивает “вертикальное” реше-
ние и обобщение “горизонтального” решения для разработки объектных приложе-
ний. Агрегация становится преобладающей концепцией моделирования, которая оп-
ределяет общую структуру системы. Эта структура может быть формализована за счет
использования множества проектных шаблонов [28], в особенности поддержки под-
хода на основе голонов и применения четырех видов агрегации. Мы надеемся, что
рассмотренный выше подход послужит читателям интеллектуальным орудием в их
собственных изысканиях.
Резюме
В этой главе было завершено рассмотрение анализа требований. Была тщательно
исследована поддержка объектной технологии для разработки крупномасштабных
систем. Глава представляется технически сложной, но обеспечивает проникновение в
сущность объектной технологии, которое не так просто найти в книгах по анализу и
проектированию систем. Это глубокое проникновение во многом помогает раскрыть
слабые стороны и недостатки объектной технологии.
Основным методом расширения языка UML является использование стереотипов.
Они позволяют моделировать свойства, выходящие за пределы предопределенных в
UML. За счет изобретательности в этой главе удалось широко использовать стереотипы.
Стереотипы не следует путать с ограничениями, примечаниями и дескрипторами UML.
Открытая и закрытая видимость, рассмотренная в предыдущей главе, обеспечивает
только базовую поддержку важного понятия инкапсуляции. Защищенная видимость по-
зволяет управлять инкапсуляцией в рамках структур наследования. Видимость уровня
класса (в противоположность видимости отдельных атрибутов и операций) представ-
ляет собой еще одну важную концепцию, касающуюся наследования. Понятие друже-
232 Глава 5. Углубленный анализ
ственности позволяет “прорваться” сквозь инкапсуляцию для обработки специфиче-
ских ситуаций.
Язык UML включает некоторые дополнительные концепции моделирования, спо-
собные повысить выразительность моделей классов. К ним относятся производные ат-
рибуты, производные ассоциации и квалифицированные ассоциации. Одним из наиболее
интригующих моментов в моделировании классов является выбор между ассоциатив-
ным классом и материализованным классом.
Современные программные системы отличаются большой сложностью. Поэтому
важно, что решения по моделированию упрощают разработку систем и позволяют
уменьшить присущую им сложность там, где это возможно. Пожалуй, наиболее важ-
ным механизмом, позволяющим обуздать сложность ПО, является представление ар-
хитектуры системы в виде многоуровневой иерархии. Надлежащее структурирование
классов в виде пакетов, организованных в соответствии с подходом ВСЕ, является важ-
ной архитектурной задачей.
Концепция обобщения и наследования представляет собой в моделировании “палку о
двух концах”. С одной стороны, она способствует повторному использованию ПО и
повышает выразительность, понятность и уровень абстракции моделей системы. С
другой стороны, при неверном использовании всех перечисленных преимуществ она
потенциально склонна к саморазрушению.
Концепция агрегации и делегирования представляет собой важную альтернативу
обобщению и наследованию в моделировании. Делегирование и системы-прототипы об-
ладают дополнительными преимуществами поддержки иерархических архитектур-
ных структур. Абстрактное понятие галона дает интересный взгляд на способ по-
строения сложных систем.
1 Вопросы
В1. Что называется в UML “профилем"? Приведите пример.
В2. Иногда класс позволяет порождать только неизменяемые объекты, т.е. объекты, которые
не могут изменяться после реализации. Каким обрвзом подобное требование можно
представить в UML-модели?
ВЗ. Объясните различие между ограничением и примечанием.
В4. Обозначают ли термины “инкапсуляция” и “видимость” одно и то же понятие? Объясните
вашу точку зрения.
В5. Видимость унаследованных свойств в производном классе зависит от уровня видимости,
который предоставлен базовому классу в определении этого производного класса. Какова
будет видимость, если базовый- класс объявлен как закрытый? Каковы последствия этого
факта для остальной модели? Приведите пример.
Вб. Понятие “дружественности" применимо к классу или операции. Объясните, в чем различие
этих случаев. Приведите пример (отличный от изложенного в этой книге), когдв требуется
использование свойства дружественности.
В7. В чем заключаются преимущества использования производной информации для модели-
рования?
В8. Когда материализованный класс должен заменять ассоциативный класс? Приведите при-
мер (отличный от приведенного в этой книге).
В9. Какова сложность сети из девяти классов (измеряемая как количество возможных соеди-
нений между этими классами)? Изобразите иерархию для этих девяти классов, состоящую
из четырех уровней. Какого понижения сложности можно достичь за счет этой четырех-
уровневой иерархии?
Упражнения 233
В10. Предположим, что модель классов для банковского приложения содержит класс
interestcalculation (Подсчет процентов). Какому пакету ВСЕ должен принадлежать
этот класс? Объясните свою точку зрения.
В11. В чем состоит принцип подставимости? Дайте пояснения.
В12. Объясните различия между наследованием интерфейса и наследованим реализации.
В13. В чем состоит проблема изменчивости базового класса? Каковы основные причины из-
менчивости базовых классов?
В14. Объясните различия между агрегациями типа Безраздельно владеет и Владеет. Какие
преимущества при моделировании дает разделение агрегации на два этих вида?
В15. Сравните наследование и делегирование. В чем их схожесть? В чем различие между ними?
5| Упражнения
У1. Обратитесь к рис. 2.13 (разд.2.1.3.2). Предположим, что преподаватель, который руково-
дит курсом, должен также вести этот курс.
Модифицируйте диаграмму на рис. 2.13 твким образом, чтобы учесть приведенный выше факт.
У2. Обратитесь к рис. 2.17 (разд.2.1.3.2) и 2.18 (разд.2.1.5.1). Объедините оба рисунка в виде
одной модели классов.
Разработайте схему видимости для модели классов. Дайте к ней пояснения.
Каким уровнем видимости должны обладать унаследованные атрибуты класса Employee и
класса Manager? Объясните ваше решение.
УЗ. Запись на университетские курсы — обратитесь к примеру 4.9 (разд.4.2.3.3).
Возможно ли введение производной информации в модель, показанную на рис. 4.6? Если
это так, модифицируйте диаграмму.
У4. Обратитесь к рис. 2.15 (разд.2.1.3.4). Предположим, что система должна отслеживать ус-
певаемость студентов по изучению нескольких курсов одной и той же дисциплины. Это
связано с ограничением, которое гласит, что студент может провалить один и тот же курс
не более трех раз (запись на этот же курс в четвертый раз не разрешается).
Расширьте диаграмму на рис. 2.15 таким образом, чтобы учесть в модели это ограниче-
ние. Используйте при этом материализованный класс. Введите в модель любые предпо-
ложения и поясните их.
У5. Измерение затрат на рекламу— обратитесь к постановке задачи, приведенной в конце
главы 3.
Изобразите диаграмму пакетов для АЕМ-системы. Объясните введенные вами предположения.
Ув. Магазин видеопродукции — обратитесь к примеру 4.10 (разд.4.2.4.3).
Перерисуйте диаграмму на рис. 4.7 с использованием отношений реализации.
У7. Магазин видеопродукции — обратитесь к примеру 4.10 (разд.4.2.4.3).
Перерисуйте диаграмму на рис. 4.7, используя агрегацию вместо обобщения. Приведите
доводы за и против новой модели.
Основания проектирования
систем
Данная глава является прямым продолжением идей и тем, рассмотренных в пре-
дыдущей главе. Различие состоит в том, что теперь предмет рассматривается с точки
зрения проектирования. Вопросы, которые имели меньшее значение для анализа, та-
кие как технические подробности кооперативных действий объектов, теперь излага-
ются более глубоко.
Системное проектирование заключает в себе два основных вопроса: архитектурное
проектирование и детализированное проектирование. Архитектурное проектирование
охватывает многоуровневую организацию классов и пакетов, распределение процессов по
вычислительным средствам, повторное использование и управление компонентами. Де-
тализированное проектирование обращено к моделям кооперации, необходимым для
реализации функциональных возможностей системы, зафиксированных в прецедентах.
Следуя принятому во 2-й главе книге принципу изложения материала, объяснение
концепций сопровождается примерами из области системного проектирования. По-
яснения собраны вместе в виде наставления по проектированию для приложения
Internet-магазин, которое служит продолжением наставления по анализу главы 2.
6.1. Архитектура программного обеспечения
Проект представляет собой низкоуровневую модель архитектуры системы и ее внут-
ренних функций. Проектирование осуществляется в терминах программно-аппаратной
платформы, на которой предстоит реализовать систему. При итеративной и наращи-
ваемой разработке модели анализа непрерывно “обрастают” техническими подробно-
стями. Как только Технические подробности включают соображения, касающиеся про-
граммного и аппаратного обеспечения, модель анализа становится проектной моделью.
Между анализом и проектированием нельзя провести резкой границы. Можно уг-
лубляться в технические вопросы, не касаясь специфических программно-аппаратных
решений. В этом смысле большую часть вопросов, обсуждавшихся в главе 5, можно от-
нести скорее к анализу, чем к проектированию.
6.1. Архитектура программного обеспечения 235
Описание системы в терминах ее модулей называется архитектурным проектирова-
нием (architectural design). Архитектурный проект включает выбор стратегии решений в
отношении клиентской и серверной компонент системы.
Описание внутренних функций каждого модуля (прецедента) называется
детализированным проектированием (detailed design). Детализированный проект направ-
лен на разработку завершенных алгоритмов и структур данных для каждого модуля.
Эти алгоритмы и структуры данных приспосабливаются ко всем (усиливающим и на-
вязываемым) ограничениям базовой платформы реализации.
6.1.1. Распределенная архитектура
Архитектурное проектирование связано с выбором стратегии решений и модуляризацией
системы. Стратегия решения призвана разрешить проблемы, связанные с построением
клиентской и серверной частей системы, а ПО промежуточного слоя (middleware) необ-
ходимо для “склеивания” клиента и сервера. Решение по основным строительным блокам
(модулям) только отчасти зависит от выбранной стратегии решения.
Клиент и сервер — логические понятия [6]. Клиент (client) — это вычислительный
процесс, который осуществляет запросы к процессу сервера. Сервер (server) — это вы-
числительный процесс, который обслуживает запросы сервера. Обычно процессы
клиента и сервера выполняются на разных компьютерах, но вполне возможно реали-
зовать систему клиент/сервер на одной машине.
В типичном сценарии клиентский процесс отвечает за управление отображением
информации на экране пользователя и за обработку событий, инициированных поль-
зователями. Процесс сервера— это любой компьютерный узел с базой данных, из кото-
рой данные могут быть запрошены клиентским процессом.
Архитектуру клиент/сервер можно расширить для представления произвольной
распределенной системы. Любой компьютерный узел с базой данных может играть
роль клиента в одних деловых операциях, а сервер — в других операциях. Соединение
подобных узлов с помощью сети связи дает начало архитектуре системы распределенной
обработки, как показано на рис. 6.1.
Рис. 6.1. Архитектура системы распределенной обработки
236 Глава 6. Основания проектирования систем
В системе распределенной обработки клиент может осуществлять доступ к любому
количеству серверов. Однако клиенту может быть разрешен доступ одновременно
только к одному серверу. Это значит, что он может быть не в состоянии объединить
данные от двух или более серверов баз данных в одном запросе. Если это возможно,
то архитектура поддерживает систему распределенных баз данных.
6.1.2. Трехзвенная архитектура
В разд. 5.2.4 был рассмотрен подход ВСЕ (boundary-control-entity— граница-
управление-сущность). Также утверждалось, что подход ВСЕ хорошо увязан с трех-
звенной архитектурой, в которой между клиентом (граница) и сервером (сущность)
вводится отдельный промежуточный слой логики приложения (управление).
Аналогично клиентскому и серверному процессу прикладной процесс представляет со-
бой логическое понятие, которое может поддерживаться или не поддерживаться спе-
циально выделенным для этой цели аппаратным обеспечением. Логика приложения
может с равным успехом выполняться на клиентском или серверном узле, т.е. может
быть встроена в клиентский или серверный процесс и реализована в виде библиотеки
DLL (Dynamic Link Library — динамически компонуемая библиотека), API-интерфейса
(Application Programming Interface — интерфейс прикладного программирования), RPC-
вызовов (Remote Procedure Calls — удаленный вызов процедуры) и т.д. [57].
Если логика приложения скомпилирована с клиентом, говорят об архитектуре тол-
стого клиента (thick dient architecture) (“клиент на стероидах”). Если она скомпилирована
с сервером, говорят об архитектуре тонкого клиента (thin client architecture) (“клиент
“кожа да кости”). Возможны также промежуточные архитектуры, в которых логика
приложения частично скомпилирована с клиентом, а частично — с сервером.
Логику приложения можно также развернуть на отдельных вычислительных узлах,
как показано на рис. 6.2.
Пользовательский уровень
Рис. 6.2. Трехзвенная архитектура
6.1. Архитектура программного обеспечения 237
Это трехзвенная архитектура в самом чистом виде. К ее лучшим сторонам отно-
сятся высокая гибкость, расширяемость, независимость пользователя, готовность и
низкая стоимость обновления. Однако подобная архитектура может отличаться высо-
кой начальной стоимостью, а кроме того может испытывать некоторые проблемы с
производительностью [90].
6.1.3. Программирование баз данных
Независимо от того, где расположена логика приложения, программа (клиент)
взаимодействует с базой данных (сервером), чтобы получить информацию для ее
отображения и предоставления в распоряжение пользователя для дальнейших мани-
пуляций. Однако современные базы данных также можно программировать. Говорят,
что эти современные базы данных активны.
Программы баз данных называются хранимыми процедурами (stored procedure). Хра-
нимые процедуры хранятся в самой базе данных (они являются постоянными или пер-
систентными}. Их можно вызвать из клиентской программы (или из другой хранимой
процедуры) с помощью обычного оператора вызова процедуры/функции.
Существуют хранимые процедуры специального вида — триггеры, которые нельзя
вызвать явно. Триггер срабатывает автоматически при попытке изменить содержи-
мое базы данных. Триггеры используются для реализации бизнес-правил масштаба
предприятия, которые должны быть проведены в жизнь способом, независимым от
клиентских программ (или хранимых процедур). Триггеры усиливают целостность и
непротиворечивость баз данных. Они не позволяют отдельным приложениям нару-
шать бизнес-правила, заложенные в базу данных.
6.1.З.1. Взаимодействие “приложение-база данных”
Нам необходимо решить, какая часть системы будет запрограммирована в клиен-
те, а какая — в базе данных. При этом рассматриваются следующие программируемые
части системы.
Пользовательский интерфейс.
Презентационная логика.
Прикладные функции.
Интегральная логика.
Функции доступа к данным.
Часть программы, которая называется пользовательским интерфейсом, отвечает за ото-
бражение информации на конкретный GUI-интерфейс, такой как GUI-интерфейс Micro-
soft Windows, GUI-интерфейс Unix Motif, GUI-интерфейс Macintosh. Презентационная логи-
ка (или логика представления) отвечает за обработку объектов GUI-интерфейса (форм,
меню, кнопок действий и т.д.), как того требуют функции приложения.
Функции приложения содержат основную логику программы. Они фиксируют дей-
ствия приложения и представляют собой связующее звено, соединяющее вместе кли-
ента и базу данных. С точки зрения подхода ВСЕ (разд. 5.2.4) функции приложения
реализуются классами управляющего пакета.
Интегральная логика отвечает за бизнес-правила масштаба предприятия. Это пра-
вила, которые применяются ко всем прикладным программам, т.е. все программы
238 Глава 6. Основания проектирования систем
должны функционировать в соответствии с ними. Функции доступа к данным владеют
вопросами доступа к постоянным объектам данных на диске.
На рис. 6.3 показан типичный сценарий. Пользовательский интерфейс и презен-
тационная логика принадлежат клиенту. Функции доступа к данным и интегральная
логика (триггеры) находятся в ведении базы данных. Прикладные функции зачастую
программируются (в виде SQL-запросов) как часть клиента в начале этапа разработки,
а затем переносятся в базу данных (в виде хранимых процедур) для окончательного
развертывания программного продукта.
Интерфейс пользователя Презента- ционная логика Функция приложения (разработка)
ПО промежуточного
слоя —
протокол обмена
(например,
собственный
интерфейс
или ODBC)
Клиент
Функция приложения Интегральная логика Доступ к данным
Интерфейс пользователя Презента- ционная логика Функция приложения (разработка)
База данных
Рис. 6.3. Взаимодействие “приложение-база данных”
6.1.3.2. Подход BCED
Подход BCED (Boundary-Control-Entity-Database— граница-управление-сущностъ-база
данных) является расширением подхода ВСЕ (разд. 5.2.4). Он позволяет эффективно
отделить EntityPackage (Пакет сущностей) от классов, ответственных за извлече-
ние данных из базы данных. Эти классы помещаются в пакете DatabasePackage
(Пакет базы данных) (рис. 6.4). (Пакет DatabasePackage в действительности явля-
ется пакетом интерфейса с базой данных — Database Inter face Package, однако, мы
предпочитаем короткие обозначения. Назвать пакет подобным образом — в любом
случае не очень хорошая идея из-за многозначности понятия интерфейса.)
Пакет EntityPackage по-прежнему обеспечивает “исполняемую модель бизнес-
процессов” [26]. Он хранит и помещает в буфер данные, полученные из базы данных
и других источников; эффективно запрашивает две службы пакета
DatabasePackage, а именно, службу загрузки объекта из базы данных
loadMe (anObject) и службу сохранения объекта в базе данных saveMe (anObject)
[26]. Реализация этих служб возможна в рамках классов пакета DatabasePackage, а
именно, в виде классов DatabaseReader (Чтение базы данных) и DatabaseUpdater
(Обновление базы данных) или классов с похожими именами.
Пакет DatabasePackage обеспечивает уровень взаимного обмена между' прило-
жением и базой данных. Логика приложения (Controlpackage) теперь отделена от
изменений источника данных. Любые изменения структур баз данных и протоколов
получения данных из базы данных влияют на классы пакета DatabasePackage. Хра-
6.1. Архитектура программного обеспечения 239
пение и буферизация данных (пакет Entitypackage) для функций приложения ос-
таются неизменными, поскольку об этом заботится пакет Controlpackage.
Рис. 6.4. Уровни BCED
В действительности, классы пакета Databasepackage выполняют набор и других
услуг. Эти дополнительные услуги могут состоять в открытии и закрытии соединения
с базой данных, выдаче базе данных указания о подтверждении или откате транзак-
ции, определении параметров времени выполнения для конфигурации базы данных,
работе с авторизацией пользователей, извлечении и хранении метаданных об объек-
тах базы данных (таких, как таблицы, столбцы, представления, хранимые процедуры,
индексы и т.д.).
Разделение обязанностей, вводимое подходом BCED, можно “донести” до систем-
ных проектировщиков и программистов с помощью простого метода задания пре-
фиксов имен. Поскольку каждый класс может принадлежать только к одному пакету,
его можно поименовать с помощью однобуквенного префикса (В, С, Е или D). На-
пример, класс, помеченный как B_TreeBrowseView, принадлежит пакету
Boundarypackage, а класс D_DatabaseUpdater — пакету DatabasePackage.
6.1.3.3. Системное ПО
Стратегия решения для объектно-ориентированного клиента обычно развивается во-
круг программной среды со “строительными инструментами” в виде GUI-интерфейса.
При этом решение, возможно, также учитывает используемый способ подключения к
базе данных, при котором могут использоваться два основных подхода.
Собственный интерфейс базы данных, предоставляемый многими графическими
языками четвертого поколения — 4GL (например, PowerBuilder, Developer 2000,
Delphi).
Драйверы ODBC или JDBC для базы данных (например, в составе сред Visual C++,
PowerJ++).
Стратегия решения для сервера определяет технологию баз данных. Поскольку
“данные остаются навсегда, а приложения появляются и исчезают” (слова Боба Эп-
штейна (Bob Epstein) из Sybase, цитируются по памяти), стратегия решения для серве-
ра, вероятно, оказывает значительное влияние на клиентскую стратегию. Часто вы-
бирается та среда разработки клиента, которая предоставляется поставщиком СУБД.
К стратегическим решениям по серверу относятся следующие варианты СУБД.
240 Глава 6. Основания проектирования систем
Реляционные базы данных (например, Sybase, Oracle, Informix).
Объектно-реляционные базы данных (например, Oracle8, Informix/Illustra, UniSQL).
Объектные базы данных (например, ObjectStore, Versant, Objectivity/DB).
В настоящее время перечисленные три технологии баз данных не конкурируют,
они превосходят друг друга по разным вопросам и обращены к различным приклад-
ным областям. В результате, решения по модели базы данных должны основываться
на текущих и ожидаемых требованиях приложения.
6.1.4. Стратегия повторного использования
UML определяет повторное использование {reuse) как “использование ранее сущест-
вовавших артефактов” [76]. Мы мимоходом уже обсуждали объектно-
ориентированные методы для повторного использования ПО, такие как наследова-
ние и делегирование. В данном разделе обратимся к стратегиям повторного использова-
ния ПО. Оказывается, что стратегия также влияет на степень детализации, с которой
осуществляется повторное использование. Могут применяться следующие степени де-
тализации повторного использования.
Класс.
Компонента.
Идея решения.
В связи со степенью детализации существуют три соответствующие стратегии по-
вторного использования [13], [28], в основе которых лежат следующие программные
сущности.
1. Инструментальные средства (библиотеки классов).
2. Каркасы.
3. Шаблоны анализа и проектирования.
6.1.4.1. Повторное использование инструментальных средств
Стратегия повторного использования инструментальных средств придает особое
значение многократному использованию программного кода на уровне классов. При этой
стратегии повторного использования программист “заполняет бреши” в программе за
счет осуществления вызовов конкретных классов из некоторых библиотек классов. Ос-
новное тело (ядро) программы не подлежит повторному использованию — его пишет
программист.
Существует два типа (уровня) инструментальных средств [60].
1. Базовые инструментальные средства.
2. Архитектурные инструментальные средства.
Базовые классы {foundation classes) широко представлены объектными программными
средами. Они включают классы для реализации элементарных типов данных (такие
как String), структурных типов данных (таких как Date) и коллекций (таких как Set,
List или Index).
Архитектурные классы {architecture classes) обычно представлены как части системно-
го ПО, такого как операционные системы, СУБД или ПО GUI-интерфейсов. Напри-
6.1. Архитектура программного обеспечения 241
мер, когда мы приобретаем объектную СУБД, то фактически получаем архитектурные
инструментальные средства, реализующие ожидаемые функциональные возможности
системы, такие как поддержка хранения постоянных объектов, выполнение транзак-
ций и обеспечение параллельности.
6.1.4.2. Повторное использование каркасов
Стратегия повторного использования каркасов (framework) придает особое значе-
ние многократному использованию на уровне компонент (компоненты рассматриваются в
разд. 6.1.5). В противоположность повторному использованию инструментальных
средств каркас предоставляет в распоряжение разработчиков скелет программы. За-
тем программист “наращивает” этот скелет (настраивает его) за счет написания про-
граммного кода, вызовы которого встроены в каркас. Помимо конкретных классов
(для самого каркаса) каркас предоставляет в распоряжение программиста массу абст-
рактных классов, которые он должен реализовать (настроить).
Каркас — это настраиваемое прикладное ПО. Лучшими примерами каркасов слу-
жат ERP-системы (Enterprise Resource Planning Systems — системы планирования ре-
сурсов предприятий), такие как SAP, PeopleSoft, Ваап или J.D. Edwards. Однако по-
вторное использование этих систем не основано на чистых объектно-
ориентированных методах.
Объектно-ориентированные каркасы для разработки ИС предлагаются в рамках
распределенных компонентных технологий, таких как CORBA, DCOM и EJB (см.
разд. 1.1.1). Они известны как “бизнес-объекты” (“business objects”) — “поставляемые” про-
граммные продукты, призванные удовлетворить специфические деловые или при-
кладные потребности. Например, бизнес-объект может быть каркасом системы бух-
галтерского учета с настраиваемыми классами, такими как Invoice (Счет-фактура)
или Customer (Клиент).
Хотя каркасы и привлекательны с точки зрения повторного использования, они
обладают рядом недостатков. Пожалуй, самым значительным из них является то, что
исходное решение на основе “наименьшего общего знаменателя”, которое они пред-
лагают, является условно оптимальным, а то и вовсе устарелым. В результате каркасы
не дают конкурентного преимущества своим приверженцам и могут оказаться весьма
обременительными в стремлении внедрить более современные решения.
6.1.4.3. Повторное использование шаблонов
Стратегия повторного использования шаблонов (pattern) придает особое значение
многократному использованию подходов, при котором в распоряжение разработчиков пре-
доставляются идеи и примеры кооперативного взаимодействия объектов, которые хорошо
зарекомендовали себя в практике разработки и которые ведут к понятным и масштаби-
руемым решениям (кооперативное взаимодействие рассматривается в разд. 6.2). Шаб-
лоны могут применяться на этапе анализа или проектирования ЖЦ разработки ПО
(отсюда — шаблоны анализа (analysispatterns) и шаблоны проектирования (designpatterns)).
Шаблон — это документально оформленное решение, которое доказало свою рабо-
тоспособность в ряде ситуаций. Данные ситуации четко обозначены и могут использо-
ваться в качестве “статьи индекса” для поиска приемлемого решения в ходе разработки.
Чтобы дать возможность разработчику принять обоснованное решение, необходимо
привести перечень всех известных недостатков и побочных эффектов шаблона.
Повторное применение шаблонов во многом носит концептуальный характер, хотя
многие проектные шаблоны содержат примеры программного кода для повторного ис-
242 Глава 6. Основания проектирования систем
пользования программистами. Рамки проектного шаблона (см., например, [28]) опреде-
ляются кооперацией (разд. 6.2) — обычно они охватывают область более широкую, чем
класс, но более узкую, чем компонента. Рамки шаблона анализа (см., например, [26]) за-
висят от уровня абстракции моделирования, к которой применяется шаблон.
6.1.5. Компоненты
Компонента (component) — это физическая часть системы, фрагмент реализации,
программа [8], [48], [76], [88]. Компоненты зачатую воспринимаются как двоичные
исполняемые (ЕХЕ-файлы) части системы. Но компонента может быть также частью
системы, которая не является непосредственно исполняемым модулем (например,
файлом исходного текста программы, файлом данных, динамически компонуемой
библиотекой (Dynamic Link Library — DLL) или хранимой процедурой базы данных).
В настоящее время UML определяет пять стандартных стереотипов для компо-
нент [8].
1. Исполняемая (т.е. непосредственно исполняемый модуль).
2. Библиотека (т.е. модуль статической или динамической объектной библиотеки).
3. Таблица (т.е. таблица базы данных).
4. Файл (т.е. файл исходного текста или данных).
5. Документ (т.е. документ, предназначенный для восприятия человеком).
Ниже приводится перечень характеристик компонент [76], [88].
Компонента представляет собой независимо развертываемый программный блок
(компонента никогда не развертывается частично).
Компонента может служить строительным блоком для стороннего разработчика
(т.е. компонента в достаточной мере документирована и самодостаточна, чтобы
сторонний разработчик мог “встроить” ее в другие компоненты).
Компонента не обладает тупиковым состоянием (т.е. компоненту невозможно
отличить от ее собственных копий; в рамках любого данного приложения
присутствует самое большее одна копия конкретной компоненты).
Компонента— заменяемая часть системы, т.е. ее можно заменить другой
компонентой, которая согласуется с тем же интерфейсом.
Компонента выполняет четкую функцию и с логической и физической точки
зрения образует единое целое.
Компонента может быть вложена в другие компоненты.
6.1.5.1. Обозначение компонент
Графически компонента представляется как прямоугольник с двумя небольшими
•прямоугольниками-вставками с левой стороны. Уникальное имя компоненты помеща-
ется внутри большого прямоугольника. Между двумя любыми компонентами может
быть задано отношение зависимости.
На рис. 6.5 показана компонента InvoicingEXE, которая относится к стереотипу
Исполняемых компонент.
6.1. Архитектура программного обеспечения 243
«executable»
Invoicing EXE
Рис. 6.5. Обозначение компоненты
6.1.5.2. Диаграмма компонент
Диаграмма компонент показывает компоненты и их взаимосвязь друг с другом.
Компоненты могут быть связаны отношениями зависимости. Зависимая компонента за-
прашивает обслуживание у компоненты, на которую указывает отношение зависимо-
сти. Компоненты также могут быть связаны отношениями композиции, т.е. одна ком-
понента может содержать другую.
На рис. 6.6 показаны три компоненты. Компонента InvoicingEXE зависит от двух
других. Характер этих зависимостей не определен, поскольку интерфейсы компонент
не показаны.
Язык UML допускает моделирование интерфейсов компонент с помощью символа
“леденца на палочке” (разд. 5.3.3). Если зависимость между компонентами устанавли-
вается в порядке договоренности через интерфейсы, то другая компонента, которая
реализует тот же набор интерфейсов, может заменить одну из компонент, участвую-
щих в отношении.
«executable»
InvoicingEXE
«stored procedure»
MaintainlnvoiceUSP
«executable»
InvoiceDLL
Puc. 6.6. Диаграмма компонент
6.1.5.3. Компоненты в сравнении с пакетами
Пакет (package) — логическая часть системы (разд. 5.2.3). На логическом уровне ка-
ждый класс принадлежит одному пакету. На физическом уровне каждый класс реали-
зуется, по меньшей мере, одной компонентой, а компонента, возможно, реализует
только один класс. Абстрактные классы, определяющие интерфейсы, зачастую реали-
зуются более, чем одной компонентой.
Пакеты обычно представляют собой более крупные архитектурные элементы, чем
компоненты. Они имеют тенденцию группирования классов по горизонтали— за счет
статической близости классов, принадлежащих одной проблемной области. Компо-
ненты— это вертикальные группы классов с близким поведением. Они могут принад-
лежать разным проблемным областям, однако, вносят вклад в один фрагмент деловой
деятельности, возможно, представленный прецедентом.
244 Глава 6. Основания проектирования систем
Описанное выше свойство ортогональности пакетов и компонент затрудняет ус-
тановление зависимостей между ними. Зачастую ситуация складывается так, что ло-
гический пакет зависит от нескольких физических компонент.
Обратитесь к описанию пакетов, представленных в примере 5.10 (разд. 5.2.3.2). Рас- !
смотрите пакет Timetable. Предположим, что пакет реализуется как программа на
языке C++, которая включает логику распределения университетских аудиторий по <
группам. Программа получает доступ к базе данных по аудиториям и группам. Для пре- !
доставления программе этой услуги реализуются две хранимых процедуры.
Изобразите диаграмму компонент, которая показывает зависимости между пакетами и ,
необходимыми компонентами.
На рис. 6.7 показана модель компонент. Она включает три компоненты:
RoomAllocEXE, RoomUSP и ClassUSP. Пакет Timetable зависит от этих компонент.
Рис. 6.7. Пакеты в сравнении с компонентами
6.1.5.4. Компоненты в сравнении с классами и интерфейсами
Подобно классам компоненты реализуют интерфейсы. Разница между ними двоя-
кая. Во-первых, компонента — физическая абстракция, развертываемая на некотором
компьютерном узле. Класс представляет логическую сущность, которая для того, что-
бы действовать в качестве физической абстракции, должна быть реализована с помо-
щью компоненты.
Во-вторых, компонента показывает только некоторые интерфейсы содержащихся в
ней классов. Многие другие интерфейсы инкапсулированы компонентой — они исполь-
зуются только внутри кооперирующимися классами и не видимы другим компонентам.
Интерфейс, который конкретизируется компонентой, может быть реализован в
отдельном классе. Подобный класс называется доминантным классом (dominant class)
[76]. Поскольку доминантный класс представляет интерфейс компоненты, любой
объект внутри компоненты достижим из доминантного класса через связи компози-
ции. “Доминантный класс конкретизирует интерфейс компоненты” [76].
6.1. Архитектура программного обеспечения 245
1МН |.’дх1--11.п;гСгЬтЬзг уугг- • ' ''
К®’ 31к»»-ч>?ж Ж^^^^М®®ИМнИВИЕИИ5.,- •« «l. >. -. ..- jmhk., л™.—...... »j
Обратитесь к трем компонентам, представленным в примере 6.1 (разд. 6.1.1.3.3). '
Предположим, что компонента RoomAllocEXE инициирует процесс распределения ау-
диторий по курсам за счет обеспечения для компоненты ciassUSP идентификации i
классов. С этой целью реализует интерфейс под названием Allocate.
Компонента ciassUSP выполняет остальную работу, запрашивая подробную информа- *
цию об аудитории у компоненты RoomUSP. Для предоставления этой услуги Roomusp ;
реализует интерфейс под названием Reserve.
На рис. 6.8 показана диаграмма компонент, соответствующая сформулированным
выше требованиям.
Рис. 6.8. Отображение интерфейсов на диаграмме
компонент
6.1.6. Развертывание
В языке UML трехзвенная архитектура (наподобие той, что показана на рис. 6.2)
или любая другая архитектура для системы выражается в виде диаграммы развертыва-
ния (deployment diagram). Фактически диаграмма, представленная на рис. 6.2, является
допустимой диаграммой развертывания UML, на которой вычислительные ресурсы
представлены в виде специальных пиктограмм.
Вычислительные ресурсы (физические объекты времени выполнения) называют-
ся узлами (node). Узел обладает, как минимум, памятью и некоторыми вычислительны-
ми возможностями (например, клиентский Х-терминал на рис. 6.2). Узел может также
быть сервером баз данных наподобие активного (программируемого) сервера.
6.1.6.1. Обозначение узлов
В UML узел графически представляется в виде куба. Куб может быть обозначен как
стереотип. Подобный куб-стереотип может выглядеть как пиктограмма. Каждому узлу
присваивается уникальное имя (текстовая строка).
246 Глава 6. Основания проектирования систем
На рис. 6.9 показан узел CorporateDatabaseServer. Стереотип «Sybase» гово-
рит о том, что узел размещен на платформе СУБД Sybase.
«Sybase»
Корпоративный
сервер
баз данных
Рис. 6.9. Обозначение узла
6.1.6.2. Диаграмма развертывания
Диаграмма развертывания показывает узлы и взаимосвязи между ними. Узлы могут
быть связаны отношениями соединения (connection relationships). Отношение соединения
можно поименовать, чтобы указать используемый сетевой протокол (если это подхо-
дит) или описания характера соединения каким-либо другим способом. В общем слу-
чае отношение соединения представляет собой ассоциацию, и его можно моделиро-
вать с использованием типичных свойств ассоциации, таких как порядок, кратность,
роли и т.д. (разд. 2.1.3).
На рис. 6.10 показаны два узла на диаграмме развертывания. Отношение соедине-
ния download_nightly говорит о том, что узел сервера хранилища данных
DataWarehouseServer (функционирующий под управлением ПО IQ от Sybase) каж-
дую ночь загружает данные с узла транзакционной базы данных
CorporateDatabaseServer.
Рис. 6.10. Диаграмма развертывания
6.1.6.3. Узлы в сравнении с компонентами
Узлы представляют местоположение выполнения компонент. Компоненты функ-
ционируют на узлах. Компоненты развертываются на узлах. Узлы вместе с их компо-
нентами иногда называются элементами размещения (distribution unit) [8].
На рис. 6.11 показан узел корпоративной базы данных CorporateDatabaseServer.
НаузЛе выполняются две хранимые процедуры, которые представлены как компоненты
CustomerUSP иInvoiceUSP.
На рис. 6.12 показан альтернативный способ моделирования “включения” компо-
нент в узел. Эту нотацию можно расширить таким образом, чтобы вся диаграмма ком-
понент помещалась на диаграмме развертывания [25].
6.2. Кооперация 247
Корпоративный
сервер
баз данных
CustomerUSP
InvoiceUSP
Рис. 6.11. Узел и его компоненты
6.2. Кооперация
Архитектурное проектирование оказывает влияние на детализированное проек-
тирование в том смысле, что оно определяет целевую программно-аппаратную плат-
форму, с которой должен быть согласован детализированный проект. Помимо этого,
детализированное проектирование есть прямое продолжение анализа. Задача заклю-
чается в том, чтобы превратить модели анализа в документы детализированного про-
екта, на основе которых программисты могут реализовать систему.
В ходе анализа мы идем на упрощение моделей, абстрагируясь от деталей, которые
служат помехой в представлении определенной точки зрения на систему. При проекти-
ровании мы стремимся действовать с точностью до наоборот. Берем одновременно од-
ну из сторон представления архитектуры и добавляем в модель технические детали или
создаем качественно новую проектную модель на более низком уровне абстракции.
248 Глава 6. Основания проектирования систем
Мы мимоходом довольно свободно использовали термин кооперация (collaboration),
говоря о множествах объектов, которые кооперируются для выполнения задания (разд.
2.1.1.2 и 2.1.2.2.1). Язык UML использует термин кооперация в тех же целях и связывает
с ним специфические методы моделирования. В частности, понятие кооперации ис-
пользуется в UML для задания реализации прецедентов или операций [8], [76].
6.2.1. Обозначение кооперации
Неудивительно, что нотация для кооперации похожа на нотацию для прецедентов.
Кооперация обозначается в виде эллипса со штриховыми границами.
На рис. 6.13 показаны две кооперации Browse Student List (Показать список сту-
дентов) и Add Student to Course Of fering (Занести студента в список [слушателей]
курса). Две кооперации реализуют (через отношение реализации (realization relationships)) пре-
цедент Enter Program of Study (Ввод программы обучения).
Заметим, что CASE-средства могут заменить явное моделирование отношения реа-
лизации на рис. 6.13 гиперссылками между прецедентом и моделью кооперации [8].
Другими словами, одна или более диаграмм UML, внутренне связанных с помощью
CASE-средств, с их прецедентами могут представлять модель кооперации. Проекти-
ровщик может перемещаться между прецедентом и моделями кооперации, не прибе-
гая к отношениям реализации.
«realize^.
Browse Student List
<<realize>>
Enter Program of Study
Add Student to Course Offering
JPuc. 6.13. Обозначение кооперации
6.2.2. Диаграмма кооперации
Диаграмма кооперации представляет собой один из видов модели взаимодействия
UML (разд. 2.2.5). Второй вид — диаграммы последовательностей (разд. 2.2.5.3). Мы
отдаем предпочтение диаграммам последовательностей при анализе и диаграммам
кооперации при проектировании (по поводу сравнения этих двух типов диаграмм
взаимодействия см. разд. 6.2.3).
Диаграмма кооперации на рис. 6.14 соответствует диаграмме последовательностей
на рис. 2.33 (разд. 2.2.5.1). Номера последовательностей фиксируют временные по-
следовательности сообщений. Номера последовательностей необязательны. Для
сложных алгоритмов бывает трудно приписать сообщениям и осмысленную времен-
ную последовательность, поэтому для выражения временных последовательностей
могут потребоваться дополнительные модели (такие как диаграммы видов деятельно-
сти или псевдокод).
6.2. Кооперация 249
Заметим, что имена объектов на диаграмме кооперации в действительности пред-
ставляют роли, которые играют объекты в кооперации. Соответствующая нотация
UML выглядит так.
rolename:classname
aCust:
Customer
aConfltem:
Configurationitem
displaycomputer (item_recset)
Puc. 6.14. Диаграмма кооперации “Display Current Configuration”
(Internet-магазин)
Если быть более точными, то роль— это не объект. В языке UML роль— это
“классификатор”, представляющий любой объект, который может появиться в раз-
личных экземплярах кооперации. Кроме того, один и тот же объект может играть
разные роли в последовательных кооперациях. В общем случае ролевое имя можно
опустить, но перед именем класса необходимо поместить двоеточие, чтобы отличить
его от обычного класса [76].
6.2.2.1. Обозначение сообщений
Структура сообщения соответствует сигнатуре целевого метода (разд. 2.1.2.2). Для
успешной отправки сообщений объект-отправитель должен предоставить следующую
информацию [60].
/
Значение уникального идентификатора OID (дескриптор) для целевого объекта.
Обычно оно хранится в одном из атрибутов отправителя (с точки зрения
программирования — в переменных).
Имя операции (метода) в целевом объекте.
Дополнительно, фактические входные и выходные (возвращаемый результат)
аргументы для подстановки вместо соответствующих формальных аргументов метода.
На рис. 6.15 показана альтернативная нотация UML для определения сообщения.
Верхняя нотация, приведенная на рисунке, непосредственно отображается в сигна-
туру метода (для краткости ключевые слова можно опустить). Средняя нотация ис-
пользует возвращаемое значение и оператор присваивания вместо выходного аргу-
мента. Нижняя нотация заменяет входные и выходные аргументы направленными
маркерами данных.
250 Глава 6. Основания проектирования систем
loanPlease (in amount_req, out amount_g ranted)
loanPlease
Puc. 6.15. Альтернативное обозначение сообщений
6.2.2-2. Структура сообщений
В программе отправителя сообщение на рис. 6.15 должно включать переменную,
содержащую значение OID объекта-получателя. Переменная должна соответствовать
имени объекта-получателя на диаграмме, например,
aBankl.loanPlease(in amount_req, out amount_granted)
Обратите внимание на порядок — первым идет объект, второй операция [60]. По-
рядок подчеркивает объектно-ориентированный способ мышления, при котором
упор делается на кооперацию объектов, а не на процедурных вызовах. Он также ука-
зывает на возможный полиморфный характер сообщений, при котором одна и та же
операция предоставления ссуды (loanPlease) может иметь разные реализации в
разных классах (на объекты которых указывает значение OID переменной aBankl).
Аргументы сообщения на рис. 6.15 представляют собой маркеры данных. Это вполне
приемлемо для популярных объектно-ориентированных сред, однако, неприемлемо с
точки зрения чистого объектно-ориентированного подхода. В чистой реализации аргу-
менты сообщения должны быть OID-переменными (дескрипторами объектов) [60]. Все, с
чем мы имеем дело в чистых объектно-ориентированных системах, — это объекты!
Предположим на время, что аргументы сообщения loanPlease являются объектами
класса Money. Следовательно, значения переменных amount_req (требуемое количесг
во) и amount_granted (предоставляемое значение) должны быть OID-значениями, т.е.
указателями на ячейки памяти, хранящие количество денежных средств для этих двух
аргументов. Если это трудно для понимания, тогда вспомним, что класс для аргумента
может быть любым классом, определенным пользователем, таким как Employee или
BankAccount, а не просто элементарным типом, таким как Money или Integer. Теперь
легче понять, почему аргумент сообщения представляет собой OID-дескриптор объекта.
6.2.2.3. Типы сообщений
Сообщение можно отправить объекту-классу (разд. 2.1.6) или объекту-экземпляру.
Обычно сообщения, отправляемые объекту-классу, представляют собой конструкторы
(constructors) (предназначенные для создания новых объектов-экземпляров) и деструкторы
(destructors) (предназначенные для уничтожения существующих объектов-экземпляров).
Остальные типы сообщений (направляемые как объектам-классам, так и объектам-
6.2* Кооперация 251
экземплярам) можно разделить на следующие три группы (альтернативные имена в скоб-
ках заимствованы из [60]).
Сообщение чтения (вопросительное, адресованное настоящему).
Сообщение обновления (информативное, адресованное прошлому).
Кооперативное сообщение (повелительное, обращенное к будущему).
Сообщение чтения (read message) предписывает объекту-получателю предоставить не-
которую информацию, возможно, значения его закрытых атрибутов. Оно
“адресовано настоящему”, поскольку запрашивает текущую информацию. Вот пример
подобного сообщения.
aBankl.openingHours(in weekday, out hours)
Сообщение обновления (update message) предписывает объекту-получателю обновить
себя на основе информации, предоставляемой сообщением. Оно “адресовано про-
шлому”, поскольку обновляет объект с использованием информации, которая уже из-
вестна отправителю. Ниже приведен пример подобного сообщения.
aCustomer1.newCreditRating
(in credit_rating, effective_date)
Кооперативное сообщение (collaborative message) предписывает объекту-получателю ока-
зать помощь в выполнении запрашиваемого действия, которое является вкладом в
кооперацию. Оно “обращено к будущему”, поскольку запрашивает со стороны отпра-
вителя объект о проведении действия как части более крупной задачи, которая долж-
на быть завершена в ближайшем будущем. Примером кооперативного сообщения
служит сообщение loanPlease. Для завершения запроса объект aBankl может за-
просить другие объекты о дальнейшем сотрудничестве.
aBankl.loanPlease(in amount_req, out amount_granted)
6.2.2*4. Сравнение замещения и перегрузки
При проектировании моделей взаимодействия следует учитывать, что имя метода
может быть замещено или перегружено. Эти два термина обозначают не одно и то же.
Замещение метода (overriding) было рассмотрено в разд. 5.3.4.4.2. Замещение состав-
ляет базис полиморфизма. Оно означает, что существует несколько методов с одним и
тем же именем в различных классах. Различные реализации одного метода должны
выполняться в зависимости от того, какому классу принадлежит целевой объект.
Перегрузка метода (overloading) также означает, что существует несколько методов с
одним и тем же именем, но в одном классе. Например, помимо ранее определенного
метода loanPlease можно ввести еще один метод loanPlease в класс Bank. Этот
метод должен включать дополнительный аргумент, задающий минимальный размер
займа, который может получить клиент, как показано ниже
aBankl.loanPlease(in amount_req, minimum_amount, _out amount_granted)
Теперь метод loanPlease перегружен. Выполнение того или иного перегружен-
ного метода зависит от сигнатуры сообщения. Отсюда следует, что установление сиг-
натуры сообщений — весьма важное мероприятие на этапе проектирования.
6.2.2.5. Итеративные сообщения и шаблоны
Итеративное сообщение (iteration message) — это сообщение, отправка которого повто-
ряется для нескольких объектов класса. Для обозначения итерации в языке UML ис-
пользуется маркер итерации — звездочка перед меткой сообщения (разд. 2.2.5.1).
252 Глава 6. Основания проектирования систем
Множество объектов, на которые распространяется итеративное сообщение, на-
зывается коллекцией (collection). Коллекция может быть набором, списком
(неупорядоченным набором) или массивом объектов. На диаграмме кооперации кол-
лекция изображается как комплект (“штабель") объектов (рис. 6.14 в разд. 6.2.2).
В смысле объектно-ориентированного подхода коллекция (набор, список и т.д.) сама
является классом. Естественно, многие среды объектно-ориентированного программи-
рования по умолчанию включают соответствующие классы с именами Set, List,
FixedArray, VarryingArray, Btreelndex и т.д. Эти классы-коллекции можно затем
использовать для включения в них объектов, определяемых пользователем классов. Ти-
пичным примером использования коллекции классов может служить реализация связей
отношении ассоциации или агрегации с кратностью “многие” (разд. 2.1.3.2).
Рассмотрим рис. 6.14 и итеративное сообщение *getConf (out item_rec) от объ-
екта класса aComp к объекту aConfltem. Сообщение распространяется на коллекцию
объектов Configurationitem. Однако из диаграммы кооперации не ясно, каким обра-
зом реализована коллекция. Эту информацию можно вывести из диаграммы класса.
На рис. 6.16 приведена диаграмма классов, отображающая отношение агрегации между
классами Computer и Configurationitem. Заметим, что ролевые имена предполагается
в конечном счете реализовать как атрибуты классов. На рис. 6.17 приведена диаграмма
классов уровня реализации, на которой ролевые имена преобразованы в имена атрибутов.
Как видно из рис. 6.17 , типом атрибута has_conf_item, описывающего выбран-
ный элемент конфигурации компьютера, является список классов для этих элементов
List<ConfigurationItem>. Класс Configurationitem является параметром клас-
са-коллекции List. В общем случае класс List может заменить свой формальный па-
раметр другими классами. Мы говорим, что тип has_conf_item является шаблоном
(template — параметризованным типом, (parameterized type).
Рис. 6.16. Отношение агрегации с указанием ролей
_____________Computer____________,
computer_name '.String
standard_price: Currency
has conf item: Ust<Configurationltem>
Configurationitem
item_type: String
item_descr: String
is part of comp: Computer
Puc. 6.17. Отношение агрегации, уже реализованное с использованием атрибутов
Определение шаблона играет важную роль в понимании области действия итера-
тивного сообщения. Сообщение *getConf(out item_rec) распространяется на
объекты класса Configurationitem, входящие в список List. Список образует те-
кущее значение атрибута has_conf_item. Если быть более точным, список содержит
OID-значения (дескрипторы) всех объектов Configurationitem, включенных в
конкретный объект-компьютер Computer.
6.2* Кооперация 253
6.2.2.6. Автосообщения
Объект может отправить сообщение самому себе. Автосообщение (self message) озна-
чает локальный вызов — один метод вызывает другой метод одного и того же объекта.
Название автосообщение заимствовано из языка Smalltalk. В языках C++ и Java авто-
сообщению соответствует термин this применительно к объекту. Соответствующий
объект представляет собой константу (не переменную), которая хранит идентифика-
тор (OID) объекта [60].
Автосообщение может встретиться в последовательности кооперативных сообще-
ний (разд. 6.2.2.3), которые воздействуют на тот же класс до передачи управления
другому классу. Оно может также встретиться, если управление возвращается отпра-
вителю и следующее сообщение вызывает метод отправителя (отправитель и получа-
тель — один и тот же объект).
На рис. 6.18 приведен пример двух автосообщений (currentLeave и
longServiceLeave), которые активизируются в результате запроса на вычисление зна-
чения суммы, подлежащей выплате работнику за отпускной период — leaveEnti tlement.
Автообъект может быть передан в некоторых редких случаях, как аргумент в со-
общении, т.е.
messagename(self)
При передаче синхронных сообщений (synchronous message) (во время которой отпра-
витель должен дождаться возврата управления от целевого объекта прежде, чем за-
вершить выполнение) пересылка OID-отправителя, как правило, не требуется. Воз-
врат управления выполнением происходит автоматически, по крайней мере в боль-
шинстве объектно-ориентированных сред программирования.
longServiceLeave!)
currentLeave!)
leaveEntitlementO ] |
” anEmployee:
Employee
Рис. 6.18. Автосообщения
6.2.2.7. Асинхронные сообщения
При передаче асинхронных сообщений (asynchronous message) объект-отправитель не
должен дожидаться, пока целевой объект закончит свою работу, а продолжать выпол-
нение другого потока управления. Передача асинхронных сообщений предполагает
существование множественных потоков управления (параллелизм (concurrency))
в программе.
Для обозначения асинхронных сообщений в UML используются “односторон-
ние” стрелки. Объект те (я) на рис. 6.19 порождает два потока управления, отправ-
ляя два асинхронных сообщения объектам myCoffeeMaker (моя кофеварка) и
myRadio (мое радио).
Передача асинхронных сообщений характерна для инженерных приложений и
приложений реального времени. Типичные бизнес-приложения, выполняющие дело-
вые операции, по большей части базируются на синхронных сообщениях.
254 Глава 6. Основания проектирования систем
Рис. 6.19. Передача асинхронных сообщений
6.2.2.8. Обратные вызовы
Обратные вызовы упоминались ранее в этой книге в контексте наследования
(разд. 5.3.4.4.2). Обратный вызов (callback} — это обращение “снизу-вверх” (если смот-
реть по связи отношения) к отправителю сообщения. Типичным примером использо-
вания обратного вызова служит передача асинхронного сообщения, при котором от-
правитель (абонент (subscriber)) заявляет целевому объекту (получателю (listener)), что
ему необходимо получить информацию о завершении действия, выполняемого полу-
чателем. Целевой объект (тот, на который указывает связь отношения) должен от-
править асинхронное'сообщение назад отправителю.
На рис. 6.20 приведена расширенная диаграмма кооперации, показанная на
рис. 6.19, включающая обратный вызов от объекта myCoffeeMaker к объекту me. Как-
никак я (те) жду кофе, и мне совсем не хочется прерываться, чтобы посмотреть, го-
тов ли он — об этом мне просигналит сама кофеварка (myCof feeMaker).
Обратные вызовы — удобный механизм, однако, их очень трудно программиро-
вать. Чтобы обратный вызов работал надлежащим образом, получатель должен иметь
возможность каким-либо образом наблюдать за состоянием и изменением состояния
абонента прежде, чем отправить обратный вызов. Отправлять мне сообщение о том,
что кофе готов (cof feeReady), когда я уже в пути, не очень умная затея!
mateCoffee
Рис. 6.20. Обратный вызов при передаче асин-
хронных сообщений
6.2. Кооперация 255
6.2.3. Диаграммы последовательностей и диаграммы
кооперации
Диаграммы кооперации и диаграммы последовательностей эквивалентны в том
смысле, что их можно автоматически преобразовать одну в другую. В то же время эти
два типа диаграмм выделяют различные аспекты взаимодействия объектов (и иногда
эти различные аспекты в процессе преобразования могут быть утеряны).
Диаграммы последовательностей придают особое значение временной последова-
тельности сообщений между объектами. Они неудобны и не дают необходимой точ-
ности при представлении альтернативных путей сообщений — то, в чем отлично за-
рекомендовали себя диаграммы видов деятельности. Кроме того, они громоздки при
представлении кооперативных действий многих объектов (хотя тщательное упорядо-
чение жизненных линий объектов зачастую может улучшить удобство восприятия
диаграммы в целом).
Диаграмма кооперации может явно отображать статические отношения между
объектами, по которым может протекать поток сообщений. В результате, диаграммы
кооперации обеспечивают большую точность при визуализации таких вещей, как по-
лиморфное сообщение. Схема диаграмм кооперации позволяет отображать большее
количество объектов на той же графической площади. Сообщения могут быть полно-
стью определены и аннотированы.
Мы предпочитаем использовать диаграммы последовательностей для моделей
анализа и диаграммы кооперации для проектных моделей. Оба типа диаграмм можно
дополнить диаграммами видов деятельности. При изображении диаграмм видов дея-
тельности можно использовать уровень абстракции, соответствующий уровню абст-
ракции связанных с ними диаграмм последовательностей или кооперации.
6.2.4. Реализация прецедентов
Кооперация значит для проекта то же самое, что прецеденты для анализа. Если
прецеденты направляют анализ, то кооперация объектов направляет проектную дея-
тельность. Прецеденты реализуются с помощью кооперативных действий. Из-за раз-
личия в уровне абстракции каждый прецедент реализуется несколькими схемами
кооперации.
Кооперативные взаимодействия имеют две стороны: структурную и поведенче-
скую. Структурная сторона представляет статический аспект кооперации. Он пред-
ставляется подмножеством диаграмм классов, соответствующих рамкам кооперации.
Диаграмма классов детализируется (в сравнении со своей версией, полученной в ре-
зультате анализа) за счет подробностей реализации. В частности, осуществляется
идентификация сигнатур операций классов.
Поведенческая сторона представляет динамику, которая показывает, каким образом
осуществляется кооперативное взаимодействие статических элементов. Поведенче-
ский аспект моделируется именно в виде взаимодействий (разд. 2.2.5). Помимо диа-
грамм последовательностей (разд. 2.2.5.3), диаграммы кооперации часто используют-
ся для спецификации поведения объектов в ходе кооперативных действий. На прак-
тике структурный и поведенческий аспекты кооперации по возможности следует
разрабатывать параллельно.
256 Глава 6. Основания проектирования систем
6.2.4.1. Структурный аспект кооперации
Для решения задачи необходимо рассмотреть все дополнительные классы и до-
полнительные атрибуты и операции, необходимые для поддержки кооперации. Нам
требуется детализировать диаграмму классов, выработанную в ходе анализа. При этом
следует руководствоваться диаграммой последовательностей для прецедента, разра-
ботанной в ходе анализа (рис. 4.14, разд. 4.3.3.3).
Как видно из рис. 6.21, к диаграмме классов добавлено всего несколько классов.
Пограничный класс ProgramEntryWindow получен на основе диаграммы последо-
вательностей, показанной на рис. 4.14. Класс PrereqCourse требуется для установ-
ления отношения “многие ко многим” проверки обязательных условий. Класс
Grade (Оценка) добавлен для полноты, однако, в рассматриваемом прецеденте
больше использоваться не будет. Прошлые оценки студентов хранятся в классе
AcademicRecord. Класс Grade содержит отметки и оценки, которые студент полу-
чает при прохождении текущего курса.
Рис. 6.21. Структурный аспект кооперации (Запись на университетские курсы)
Атрибуты ранее определенных классов не изменились. Новые классы содержат
атрибуты, которые должны быть самоочевидными. Основное добавление в детализи
рованную диаграмму классов состоит в определении операций. Операции пепосред
ственно выводятся из диаграммы кооперации, представляющей поведенческий ас
пект кооперации (см. след. разд.).
6.2. Кооперация 257
Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Мы рассматри- J
ваем прецедент “Enter Program of Study" (“Ввод программы обучения”). Прецедент (
управляет записью студентов на предлагаемые учебные курсы.
Для целей этого примера мы предполагаем, что прецедент проверяет (прежде, чем сту-
дент будет записан), внес ли студент плату и удовлетворяет ли студент предваритель- '
ным условиям набора на курсы.
Наша задача состоит в том, чтобы расширить диаграмму классов на рис. 4.16 (пример '
4.9) таким образом, чтобы смоделировать структурный аспект кооперации, необходи-
мый для описанного сценария. <
6.2.4.2. Поведенческий аспект кооперации
На рис. 6.22 представлено решение для примера. По сравнению с диаграммой
последовательностей (рис. 4.14) в диаграмму кооперации введено два объекта
anAcademicRecord и aPrereqCourse. Эти объекты необходимы для осуществле-
ния проверки оплаты студентом курса и выполнения обязательных условий прежде,
чем студент может быть зарегистрирован на предлагаемом курсе (объект
Courseoffering).
: Data Entry
Person
[c_check=‘ no’] destroy
[s_check-no’]destroy
feesPaid(out paid)
Puc. 6.22. Поведенческий аспект кооперации (Запись на университетские курсы)
258 Глава 6. Основания проектирования систем
j Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Наша задача со-
| стоит в создании диаграммы кооперации, представляющей поведенческий аспект коо-
< перативного взаимодействия, как определено в примере 4.9. Диаграмма кооперации
I должна быть детализацией диаграммы последовательностей на рис. 4.14 (пример 4.17). ,
6.2.5. Реализация операций
Кооперацию можно также использовать для моделирования реализации более слож-
ных операций [8]. С этой целью можно использовать как структурные, так и поведенче-
ские аспекты.
Модели кооперации стоит применять только для сложных операций, требующих коо-
перативного взаимодействия нескольких объектов. Более простые операции— ограни-
ченные одним-двумя классами — лучше моделировать с помощью диаграмм видов деятель-
ности, в особенности, если эти операции сильны алгоритмически. Этот же принцип при-
меним в отношении более простых операций, представляющих собой компоненты более
сложных операций, которые моделируются с использованием кооперации.
^П^имер6.5.^пись на
; Обратитесь к примерам 4.18 (разд. 4.3.4.3), 6.3 (разд. 6.2.4.1) и 6.4 (разд. 6.2.4.2). Рас-
i смотрите сообщение addStudent (stdOID) на рис 6.22 (пример 6.4).
j Наша задача состоит в разработке диаграммы видов деятельности для реализации опе-
: рации Courseoffering.addStudent. Операция должна добавлять студента в список
> студентов, проходящих данный курс обучения (атрибут courseoffering, std). Атрибут
вводится как шаблон list<Student> (рис. 4.15, пример4.18).
' Прежде, чем студент добавляется к списку слушателей курса, система осуществляет
> проверку, чтобы определить, по-прежнему ли открыт прием на курс. Это необходимо,
даже если аналогичная проверка была выполнена непосредственно перед инициирова-
i нием события addstudent (stdOID) (рис. 6.22). В системах баз данных с высоким
; уровнем распараллеливания операций статус предлагаемого курса (прием открыт или
, закрыт) мог за это время измениться.
i После добавления студента в список слушателей курса -. Courseoffering наш алгоритм
\ должен зафиксировать противоположную связь в объекте :student. Чтобы установить
обратный указатель из объекта : Student на объект :CourseOf fering, первый должен
t быть обновлен.
Решение для примера показано на рис. 6.23. Рамки диаграммы видов деятельности
ограничены классом Courseoffering за исключением необходимости взаимодейст-
вия с классом Student для поддержания ссылочной целостности между связями.
Наконец, наиболее очевидные операции можно моделировать с использованием
псевдокода или непосредственно реализовать программно. Программа, которая реали-
зует подобную операцию, по-прежнему может быть включена в UML-модель в качест-
ве примечания или присоединенного документа.
Событие (сообщение) addStudent активизирует деятельность (метод) addStudent.
Внутреннее сообщение areYouOpen активизирует метод areYouOpen. Вид деятельности
areYouOpen сравнивает квоту с количеством уже записавшихся студентов, чтобы прийти
к решению. Проверка осуществляется с помощью внутреннего гипимиительного действия.
Если решение отрицательно, объект Courseoffering переходит в состояние Closeс!
([Прием] закрыт). В противном случае он будет находиться в состоянии Open. Выполне-
ние диаграммы деятельности должно завершиться при достижении состояния Closed.
6.3. Наставление по проектному моделированию 259
При нахождении диаграммы (и объекта Courseoffering) в состоянии Open, деятель-
ность addStudent продолжается. Действие add stdOID to Courseoffering.std
приводит к новому состоянию Student Added (Студент добавлен [в список курса]). При
нахождении в этом состоянии другое действие add crsoffOID to Student.crsoff
вызывает деятельность Student. setCrsOf f.
Последний вид деятельности идентифицирует новый метод, который должен
быть включен в класс Student (рис. 6.21). Он также идентифицирует необходимость
в атрибуте crsoff типа list<Course> для класса Student.
Рис. 6.23. Диаграмма видов деятельности для моделирования реализации
операции (Запись на университетские курсы)
6.3. Наставление по проектному
моделированию
В главе второй мы представили наставление с руководством по решению для при-
ложения Internet-магазин. Целью этого наставления было помочь читателю освоить
основные понятия анализа на основе разбора примеров. В данной главе мы расширим
это же наставление, чтобы объединить вместе базовые понятия проектирования.
Наставление имеет двоякое назначение. Во-первых, мы подкрепим новые концепции
(введенные в главах 5 и 6), используя их применительно к одной проблемной области.
Мы обратимся как к архитектурным вопросам (пакеты, компоненты, узлы), так и к
вопросам детализированного проектирования (кооперация). Во-вторых, детализиру-
260 Глава 6. Основания проектирования систем
ем модели анализа, разработанные в разд. 2.2. А именно, добавим проектные подроб-
ности и расширим существующие модели, чтобы эффективно превратить их в про-
ектные документы, хотя и по-прежнему на относительно высоком уровне абстракции.
Рамки наставления ограничены понятиями, введенными до сих пор в книге. Дета-
лизированное проектирование пользовательского интерфейса (глава 7), баз данных
(глава 8) и программной логики (глава 9) не рассматриваются.
6.3.1. Проектирование пакетов
В разд. 5.2.3 мы отметили, что пакеты могут объединять в группы классы или другие
элементы моделирования, чаще всего — прецеденты. При использовании в ходе анализа
пакеты обычно применяются для обозначения основных групп прецедентов. При проек-
тировании пакеты используются наиболее характерным способом — для группирования
классов. Следовательно, можно выделить две основные категории пакетов.
Пакеты прецедентов.
Пакеты классов.
Использование моделей пакетов оправдано только при структуризации больших систем.
Небольшие системы можно понять и управлять ими, не прибегая к помощи пакетов. Для
подобных систем обычно достаточно уровня модульности, который обеспечивают преце-
денты. Иногда пакеты играют роль своеобразных “архитектурных объемов", призванных
дать возможность приспособиться к ожидаемому росту масштабов системы или зафикси-
ровать тот факт, что первоначальное множество прецедентов и классов по мере продол-
жения разработки и продвижения детализированного проектирования будет расти.
Пакеты классов, в частности, эволюционируют в ходе проектирования по мере то-
го, как к модели классов добавляются новые пограничные и управляющие классы, а
также классы баз данных (напомним читателю, что диаграмма классов, построенная в
результате анализа, идентифицирует и связывает между собой классы-сущности— к
другим типам классов при проектировании фактически не обращаются). Соответст-
венно, модель пакета класса играет ведущую роль при проектировании. Модель паке-
та прецедентов практически не используется за пределами этапов проектирования,
поскольку модель пакета классов довольно эффективно заменяет ее.
6.3.1.1. Пакеты прецедентов
’ Обратитесь к наставлению по анализу для приложения Internet-магазин (разд. 2.2). Рас-
< смотрите диаграмму прецедентов на рис. 2.24 (разд. 2.2.2.3). Более пристальный
[взгляд на спецификацию для приложения Internet-магазин приводит нас к заключению,
что модель прецедентов неполна.
| В процессе изучения и документирования уже выявленных прецедентов мы определен-
1 но должны обнаружить дополнительные прецеденты. Новые прецеденты могут быть
расширением существующих прецедентов или входить в их состав (разд. 4.3.1.2), либо
5 они могут означать прецеденты, которые были упущены из виду при первоначальном
> анализе требований.
# В любом случае мы предполагаем, что новые прецеденты значительно усложнят систе-
j му, и поэтому нам кажется целесообразным структурировать существующие прецеден-
j ты в виде пакетов. Пакеты станут играть роль “функциональных объемов" для размеще-
। ния в них существующих и новых прецедентов.
i В данном примере мы конструируем диаграмму пакетов прецедентов, которые должны
! вобрать в себя существующие прецеденты и обеспечить адаптацию к их росту в будущем.
6.3. Наставление по проектному моделированию 261
Наше решение для примера представлено на рис. 6.24. Из рисунка видно, что мы
выделили пять пакетов и назначили им прецеденты (рис. 2.24). На рисунке также по-
казаны отношения зависимости.
Наверное не удивительно, что пакеты на рис. 6.24 выстроились в соответствии с
последовательностью выполнения бизнес-процессов для приложения Inlemet-магазгт.
Они отражают порядок, в котором клиенты, приобретающие компьютер, используют
Web-страницы и формы, отображаемые броузером.
Рис. 6.24. Пакеты прецедентов (Intemet-магазин)
6.З.1.2. Пакеты классов
Лучший способ “расправиться” с примером — “сымитировать систему” и представить,
что необходимо сделать, чтобы принять заказ клиента на сконфигурированный компью-
тер. Первый очевидный вывод состоит в том, что система справляется с двумя отдельны-
ми функциями: конфигурирование компьютера и ввод заказа. Эти две функции требуют
отдельных GUI-окон. В наставлении по анализу мы идентифицировали только два погра-
ничных класса, однако, можно не сомневаться, что каждая функция может потребовать сво-
262 Глава 6. Основания проектирования систем
его набора GUI-объектов. Следовательно, можно создать два пакета: ConfigurationGUI
(GUI-интерфейс для конфигурирования) и OrderGUI (GUI-интерфейс для заказа).
ff
f Обратитесь к наставлению по анализу для приложения Internet-магазин (разд. 2.2).
J Вполне естественно, что большинство классов, определенных нами в разд. 2.2, пред-
> ставляют постоянные объекты базы данных (“бизнес-объекты”). Более полная модель
1 для системы может потребовать идентификации классов прикладной программы. Это
? можно выполнить во время проектирования кооперативных взаимодействий позже в
I этом наставлении.
| Даже если мы еще не определили классы прикладной программы, можно сделать пред-
} положения относительно пакетов, которые должны группировать классы в связанные
J модули в соответствии с подходом BCED (разд. 6.1.3.2). Наша задача в этом примере
г заключается в том, чтобы продумать возможный состав и структуру пакетов для прило-
j жения “Internet-магазин" и основные зависимости между ними.
На “деловой стороне” спектра классов их номенклатура идентифицирована в рам-
ках диаграммы классов (рис. 2.31). Эти постоянные, объекты базы данных можно ес тест-
венным образом сгруппировать в виде трех пакетов сущностей'. Customers,
Computers и Orders (последний может также включать классы Invoice и Payment).
Теперь все еще недостает пакетов, которые могли бы связать воедино погранич-
ные классы и классы-сущности, т.е. управляющих пакетов. Пам требуются пакеты, со-
держащие управляющие классы, отвечающие за выполнение логики приложения, а так-
же пакет для рационального конфигурирования компьютеров и подсчета цены кон-
фигурации. Назовем такой пакет Conf igureProcess. Потребуется и пакет,
отвечающий за ввод и учет заказов — пакет Orderplacement.
Три пакета для сущностей (Customers, Computers, и Orders) представляют
структуры для постоянных классов базы данных, находящиеся в памяти машины во
время выполнения программы. Они обеспечивают временное представление в других
обстоятельствах постоянных классов, хранимых в базе данных. В каждой точке вы-
полнения программы объекты класса-сущности содержат только фрагмент содержи-
мого базы данных, обеспечивают объектно-ориентированный образ структур данных,
которые обычно хранятся в структурах баз данных, отличных от объектно-
ориентированных, а именно, как реляционные таблицы. Следовательно, существует
потребность в классах, устанавливающих интерфейс от классов-сущностей к базе дан-
ных — требуется предусмотреть один или несколько пакетов баз данных.
Основной пакет баз данных можно назвать пакетом CRUD — Create-Rcad-Update-
Delete (создать-читать-обновить-удалить (разд. 4.3.4.1)). Пакет CRUD выступает по-
средником между классами сущностей и таблицами базы данных всякий раз, когда
приложению требуется доступ или модификация содержимого базы данных.
Пакет CRUD зависит от двух других пакетов баз данных под названием
Connection (Соединение) и Schema (Схема). Классы пакета Connection отвечают
за установление соединения, авторизацию и транзакции. Пакет Schema содержит
текущую информацию об объектах схемы базы данных — таблицах, столбцах, хра-
нимых процедурах и т.д. Приложение может порождать объекты пакета Schema
при запуске, так что оно в состоянии проверить, что объекты базы данных сущест-
вуют в базе, прежде чем осуществить попытку фактического доступа к базе данных
6.3. Наставление по проектному моделированию 263
(например, перед вызовом хранимой процедуры приложение может проверить,
используя находящиеся в памяти объекты схемы, что хранимая процедура по-
прежнему существует).
На рис. 6.25 представлены описанные выше пакеты. На нем также показаны ос-
новные зависимости. Зависимости носят первоначальный и небесспорный харак-
тер. В отсутствие знания всех классов и связей взаимодействия между ними между
пакетами можно установить только гипотетические зависимости. Основной прин-
цип состоит в том, что пограничные пакеты зависят от управляющих пакетов, а те,
в свою очередь, — от пакетов сущностей. Наконец, пакеты сущностей зависят от па-
кетов баз данных.
Рис. 6.25. Пакеты классов (Internet-магазин)
264 Глава 6. Основания проектирования систем
Заметим, что зависимости между пакетами нетранзитивны [25]. Например, на
рис. 6.25 изменения в рамках пакета Customers могут влечь за собой изменения в
ConfigureProcess и OrderPlacement, но не в ConfigurationGUI и OrderGUI.
Нетранзитивность, конечно, необходима для достижения меньшей сложности в ие-
рархических или квазииерархических структурах (разд. 5.2.2).
Еще одним фактором сложности являются циклы в структурах зависимости. В
принципе, циклов следует избегать [48]. На практике иногда циклов очень трудно из-
бежать, в особенности между пакетами на одном и том же уровне иерархии [25].
6.3.2. Проектирование компонент
Компоненты— это физические части системы. Следовательно, проектирование
компонент нельзя отделить от платформы реализации. Приложение Internet-магазин —
это Web-приложение с сервером баз данных. Другие аспекты платформы реализации
нами на определялись.
Проектирование компонент требует знания платформы реализации. Поскольку
мы не намерены в этой книге выступать в защиту каких-либо конкретных решений
или поставщиков ПО, все предположения относительно платформы реализации бу-
дут строиться на достаточно общем уровне.
6.3.2.1. Реализация Web-приложений
“Web-приложение — это Web-система, позволяющая ее пользователям работать в
соответствии с заложенной в нее бизнес-логикой с помощью Web-броузера [15]. Про-
грамма, поддерживающая бизнес-логику, может находиться на сервере и/или на кли-
енте. Следовательно, Web-приложение— не что иное, как разновидность системы
клиент/сервер (разд. 6.1.1) с Web-узлом.”
Броузер Internet-клиента отображает Web-страницы на экране компьютера. Web-
сервер доставляет Web-страницы броузеру. Web-страницы могут быть статическими
(неизменяемыми) или динамическими. Web-страница может представлять форму, за-
полняемую пользователем. Чтобы пользователь мог одновременно просматривать
несколько Web-страниц, “драгоценное пространство” экрана разделяется приложе-
нием на фреймы.
Чтобы управлять логикой приложения и отслеживать состояние приложения,
Web-приложение может включать сервер приложений (разд. 6.1.2). В приложении, по-
добном Internet-магазину, мониторинг состояния представляет собой важный вид дея-
тельности, связанный с отслеживанием действий интерактивных пользователей, на-
пример, конфигураций компьютеров, которые они запрашивают. Клиент может ре-
шить приобрести определенную конфигурацию в любой момент в ходе
интерактивного сеанса, и система должна связать заказ на покупку с конфигурацией.
Обычный метод отслеживания состояния состоит в хранении в броузере так назы-
ваемых cookie— коротких символьных строк, представляющих состояние интерактив-
ного пользователя. Поскольку количество интерактивных пользователей, за которы-
ми необходимо следить с помощью Web-сервера или сервера приложений, произ-
вольно велико, на перерыв в работе пользователей в течение одного сеанса может быть
наложено ограничение. Если пользователь не активизировался в течение 15 минут
(обычное время перерыва), сервер отсоединяется от клиента. Сами cookie могут уда-
ляться или не удаляться с клиентской машины.
6.3. Наставление по проектному моделированию 265
Чтобы придать страницам, отображаемым на клиентской машине, динамичность,
используются сценарии или апплеты. Сценарий (или скрипт (script)) (например, напи-
санный на языке JavaScript) представляет собой программу, выполняемую броузером
в режиме интерпретации. Апплет (applet) — это скомпилированная компонента, кото-
рая выполняется в контексте броузера, однако, имеет лишь ограниченный доступ к
другим ресурсам клиентской машины (из соображений безопасности).
Web-страница может также включать сценарии, выполняемые сервером. Подобная
страница называется серверной страницей (server page). Серверная страница имеет дос-
туп ко всем ресурсам сервера баз данных. Серверные страницы управляют клиент-
скими сеансами, размещают cookies в среде броузера и строят клиентские страницы
(т.е. строят страничные документы из серверных бизнес-объектов и отправляют их
назад клиенту).
Чтобы обеспечить доступ сценариев, содержащихся в серверных страницах, к ба-
зам данных, используются стандартные библиотеки доступа к данным. К типичным тех-
нологиям, позволяющим реализовать эту возможность, относятся ODBC (Open Data-
base Connectivity — открытый интерфейс доступа к базам данных), JDBC (Java Database
Connectivity— интерфейс доступа к базам данных Java-приложений), RDO (Remote
Data Objects — интерфейс доступа к удаленным объектам), ADO (ActiveX Data Object —
набор высокоуровневых интерфейсов, позволяющих разработчикам обращаться к
данным на любом языке программирования на основе ActiveX). В ситуации, когда ор-
ганизация ориентируется на стандарты определенной СУБД, более непосредствен-
ный доступ к базам данных могут обеспечить вызовы низкоуровневых функций биб-
лиотек баз данных (DBLib — Database Library).
Технологией, дающей возможность функционировать Web-cepeepy, являются содер-
жащие сценарии страницы, написанные на языке HTML (HyperText Markup
Language — язык гипертекстовой разметки документов), — активные серверные стра-
ницы (Active Server Pages (ASP )) или серверные страницы Java (Java Server Pages
(JSP)). Для создания Web-страниц можно использовать технологию написания клиент-
ских сценариев (JavaScript или VBScript), документов XML (extensible Markup Lan-
guage), Java-апплетов, управляющих элементов JavaBean или ActiveX
Для получения Web-страниц с Web-сервера клиенты используют протокол HTTP
(Hypertext Transfer Protocol — протокол передачи гипертекстовых файлов). Стра-
ница может содержать сценарий или скомпилированные и непосредственно вы-
полняемые модули DLL (Dynamic Link Library — динамически компонуемая библио-
тека), например, ISAPI (Internet Server Application Programming Interface — интер-
фейс прикладного программирования Internet-сервера), NSAPI (Netscape Server
Application Programming Interface— интерфейс прикладного программирования
сервера Netscape), CGI (Common Gateway Interface — Общий шлюзовый интерфейс)
или Java-сервлеты [15].
Cookie играют роль примитивного механизма поддержки соединения между клиен-
том и сервером в системе; которая иначе называется Internet-системой без установления
соединения. Более сложный механизм соединения клиента с сервером превращает In-
ternet в распределенную объектную систему. В распределенной объектной системе объек-
ты идентифицируются с помощью уникальных OID (разд. 2.1.1.3) и взаимодействуют
за счет получения OID друг друга. Главными механизмами при этом выступают техно-
266 Глава 6. Основания проектирования систем
логии CORBA, DCOM и EJB (разд. 1.1.1). При использовании данных технологий объ-
екты могут взаимодействовать без использования протокола HTTP или Web-сервера в
качестве посредника [15].
6.3.2.2. Диаграмма компонент
Обратитесь к приведенному выше разделу 6.3.2.1 и предложите диаграмму компонент для
приложения Internet-магазин (разд. 2.2). Исходите из предположения, что компонента — i
это цельный функциональный модуль с четким интерфейсом, так что она вполне может вы-
ступать в качестве заменяемой части системы. Поскольку платформа реализации для при- .
ложения Internet-магазин не определена, идентификация более мелких компонент (таких
как библиотеки, хранимые процедуры и т.д.) на этом этапе невозможна.
Один из способов взяться за этот шаг наставления — рассмотреть типичную после-
довательность доступа к Web-страницам, интерактивного со стороны пользователя,
желающего приобрести компьютер. Соответствующие руководящие указания можно
получить из анализа прецедентов (разд. 2.2.1) и пакетов прецедентов (разд. 6.3.1.1).
Первая Web-страница, которую может посетить интерактивный пользователь, — это
Web-страница поставщика, на которой перечислены группы изделий (такие как серве-
ры, настольные системы, портативные компьютеры), выделены последние предложе-
ния и скидки, и приводятся ссылки на Web-страницы, на которых представлены переч-
ни изделий и дано краткое описание каждого изделия. Краткое описание включает цену
для стандартной конфигурации изделия. Эта часть системы посвящена рекламе товаров
интерактивным покупателям. Это единый функциональный блок, который может обра-
зовать компоненту под названием ProductList (Перечень изделий).
На следующем шаге клиент может справиться относительно технических специфи-
каций для выбранного изделия. Сюда входит визуальное отображение изделия под раз-
ными углами зрения. Это функционально законченная Web-страница, которая является
неплохим претендентом на следующую компоненту под названием ProductDisplay
(Отображение изделия).
Если предположить, что описанные выше Web-страницы привлекли внимание
клиента к продукту, он может сформулировать запрос в отношении различных
конфигураций изделия, удовлетворяющих его специфические нужды и требования
по расходам. Подобный запрос можно удовлетворить с помощью динамических
Web-страниц, позволяющих в интерактивном режиме построить конфигурацию и
отобразить готовое изделие вместе с рассчитанной ценой конфигурации. Это сле-
дующий неплохой претендент на компоненту. Назовем ее Configuration
(Конфигурация).
Клиенту, решившему купить изделие, предоставляется форма заказа на покупку. В
нее должны быть, в частности, введены такие детализированные данные, как имя
клиента, адрес, по которому следует доставить изделие и оплатить счет-фактуру. Так-
же выбирается способ оплаты, и соответствующие подробности пересылаются с ис-
пользованием некоторого безопасного протокола передачи данных. Это четвертая
компонента—Purchase (Покупка).
Последняя компонента, которую мы выделяем в нашем наставлении, должна обра-
батывать выполнение и отслеживание заказа. С точки зрения клиента она должна
6.3. Наставление по проектному моделированию 267
обеспечивать возможность просмотра состояния заказа с помощью Web-страницы
(после ввода номера клиента и номера заказа). Эту компоненту можно назвать
OrderTracking (Отслеживание заказа).
Рассмотренные выше пять компонент показаны на рис. 6.26. Интересно отметить
сходство этой диаграммы с пакетами прецедентов на рис. 6.24, что неудивительно,
поскольку пакеты прецедентов и компоненты представляют собой функциональные
модули с четкими границами. Пакеты прецедентов —логические функциональные
блоки — не оказывают влияния на способ окончательного построения системы, а если
система проста, то нет даже нужды в их конструировании. Компоненты — это реаль-
ные независимо развертываемые физически блоки — требуют тщательного проекти-
рования и реализации даже для небольших систем.
ProductList
ProductDisplay
т
Purchase
Т
OrderTracking
Рис. 6.26. Диаграмма компонент (Internet-магазин)
Configuration
6.3.3. Проект развертывания
Характер Internet-систем без установления прямого соединения (разд. 6.3.2.1) дела-
ет развертывание (deployment) Web-приложений значительно более сложной задачей,
чем развертывание приложений баз данных в архитектуре клиент/сервер. Чтобы
приступить к развертыванию, требуется установить Web-сервер в качестве пункта
маршрутизации между всеми7броузерами клиентов и базой данных.
Если проблема управления сеансами не может быть удовлетворительно решена с
помощью технологии cookie, необходимо привлекать на помощь технологию распреде-
ленных объектов. Развертывание распределенных объектов может потребовать разме-
щения отдельных архитектурных элементов— сервера приложений— между Web-
сервером и сервером баз данных.
268 Глава 6. Основания проектирования систем
Проект развертывания должен обращаться к вопросам безопасности. Безопасная
передача данных и протоколы шифрования — еще один аспект требований со сторо-
ны проекта развертывания. Кроме того, необходимо тщательное планирование с уче-
том сетевой загрузки, Internet-соединений, резервных копий и т.д.
6.3.3.1. Развертывание Web-приложений
Архитектура развертывания, способная поддерживать более сложные Web-
приложения, включает четыре звена вычислительных узлов.
1. Клиентский Web-броузер.
2. Web-сервер.
3. Сервер приложений.
4. Сервер баз данных.
Броузер клиентского узла можно использовать для отображения статических или
динамических Web-страниц. Страницы, включающие сценарии и апплеты, можно за-
гружать и выполнять в рамках броузера. Клиентский броузер можно оснастить до-
полнительными функциональными возможностями, такими как элементы управления
ActiveX или JavaBeans. Выполнение программы приложения на клиентской машине,
но вне броузера, может удовлетворить другие требования к GUI-интерфейсу.
Web-cepeep обрабатывает запросы на страницы, поступающие от броузера, и дина-
мически генерирует страницы и программный код для выполнения и отображения на
клиенте. Web-сервер также обеспечивает настройку и параметризацию сеансов рабо-
ты пользователя.
Сервер приложений необходим в том случае, когда в реализации используются рас-
пределенные объекты. Он управляет бизнес-логикой. Бизнес-компоненты публикуют
свои интерфейсы для других узлов через интерфейсы компонент, такие как CORBA,
DCOM или EJB.
Бизнес-компоненты инкапсулируют постоянные объекты, хранимые в базе дан-
ных, чаще всего в реляционной базе. Они взаимодействуют с сервером баз дан-
ных через протоколы связи с базами данных, например, такими как JDBC или
ODBC. Узел базы данных обеспечивает масштабируемое хранилище данных и
многопользовательский доступ к нему.
6.3.3.2. Развертывание диаграмм
Обратитесь к приведенному выше разделу 6.3.3.1 и предложите диаграмму разверти- •
вания для приложения Internet-магазин. В частности, рассмотрите вопрос о том, необ- <
ходимо ли использование для приложения Internet-магазин сервера приложений.
Как показано на рис. 6.27, приложение Internet-магазин можно развернуть без от-
дельного сервера приложений. Программы, содержащиеся в Web-страницах, могут
выполняться Web-сервером. Потенциальным преимуществом сервера приложений
является то, что хранимые на нем компоненты приложения могут повторно исполь-
зоваться другими Web-приложениями для вызова той же бизнес-логики. Однако
Internet-магазин— автономная система и вряд ли можно указать другие Web-
приложения, которые могли бы извлечь пользу из ее бизнес-логики.
6.3. Наставление по проектному моделированию 269
Рис. 6.27. Диаграмма развертывания (Internet-магазин)
6.3.4. Проектирование кооперативных
взаимодействий
В начале этой главы объяснялось, что системное проектирование разделяется на
архитектурное проектирование и детализированное проектирование. Проектирова-
ние пакетов, компонент и узлов относится к архитектурному проектированию. Детали-
зированное проектирование сосредоточивается на кооперации (разд. 6.2).
Кооперативные взаимодействия определяют реализацию прецедентов и реализацию
более сложных операций (простые операции не следует моделировать как коопера-
тивные). Проектирование кооперативных взаимодействий неизменно приводит к
уточнению (модификации и расширению) существующих диаграмм классов и выра-
ботке новых диаграмм кооперации (либо к детализации существующих диаграмм по-
следовательностей). Другие типы диаграмм, в частности диаграммы состояний, также
могут потребовать разработки или уточнения.
6.3.4.1. Детализация прецедентов
Важным побочным результатом (или даже предпосылкой) проектирования коопе-
рации является уточнение прецедентов. Прецеденты, зафиксированные в виде докумен-
та при проведении анализа требований, как правило, не достаточно детализированы
для проектирования кооперации. Спецификации прецедентов необходимо уточнить
в проектной документации. Прецеденты, представленные более подробными специ-
фикациями, должны включать требования системного уровня, оставаясь, в то же вре-
мя, на точке зрения субъектов.
Если на этапе анализа на управлении требованиями (разд. 3.4) концентриро-
вались не слишком большие усилия, то теперь наступает последняя возможность
достичь большей формализации и строгости в их определении. Требования сле-
дует подвергнуть тщательной классификации и пронумеровать их. Чтобы обеспе-
чить надлежащее управление изменениями и прослеживаемостью требований, их
следует поместить в репозиторий CASE-системы. (Значение управления требова-
ниями выходит далеко за рамки анализа требований на ранних фазах проектиро-
вания. Эти вопросы рассматриваются в главе 10.)
270 Глава 6. Основания проектирования систем
6.3.4.1.1. Нумерация и структурирование требований
Требования следует пронумеровать (разд. 3.4.1), структурировать (разд. 3.4.2). На-
званные виды деятельности лучше всего осуществлять с помощью CASE-средств. По-
пытки отслеживать изменения требований вручную обречены на провал. В то же
время CASE-средства значительно облегчают процесс перенумерации и реструктури-
зации требований.
На рис. 6.28 показана часть документа-спецификации прецедентов с пронумеро-
ванными требованиями. Требования пронумерованы с использованием десятичной
системы Девея (Dewey), при этом каждое требование обозначено префиксом UC (Use
Case— прецедент). Префикс полезен в том случае, когда документ описания преце-
дентов содержит более одного типа требований. Заметим, что требования заключены
в квадратные скобки, подчеркнуты и отображаются в зеленом цвете (в вопросе цвета
вы уж нам поверьте).
Рис. 6.28. Фрагмент документа описания прецедентов, поддерживаемого с помощью
CASE-системы
6.3. Наставление по проектному моделированию 271
False
False
False
False
False
False
False
False
False
False
False
False
. False a
False a
False’
False!
.Fxspj
Name
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Basic Flo
Puc. 6.29. Управление требованиями с помощью CASE-системы
6.3.4.1.2. Проектная документация по прецедентам
I Обратитесь к документу по анализу прецедентов для приложения Internet-магазин, при-
| веденному в табл. 2.2 разд. 2.2.2.4. Этот документ описывает прецедент "Order Config-
| ured Computer" (“Заказ сконфигурированного компьютера"). Данный документ недоста-
i точно подробный для разработки проекта кооперации объектов.
; Наша цель на этом шаге наставления заключается в уточнении документа описания
| прецедентов таким образом, чтобы он представлял собой спецификацию прецедентов
| проектного уровня. Детализированный документ должен быть организован аналогично •
> тому, как показано на рис. 6.28. Фактически, рис. 6.28 и 6.29 представляют собой часть ,
/ решения для данного шага наставления.
Соответствующий текст документа описания прецедента приведен ниже. Заметим,
что этот документ можно отпечатать в формате, отличном от приведенного здесь.
Например, можно подавить отображение и печать номеров прецедентов.
(Поскольку приводимый ниже документ-спецификация носит иллюстративный
характер и связь описанных в ней действий клиента и функций системы с табл. 2.2
разд. 2.2.2.4 легко пролеживается, для удобства читателей она полностью переведена
на русский язык. Прим, ред.)
272 Глава 6. Основания проектирования систем
Спецификация прецедента: “Заказ сконфигуриро-
ванного компьютера”
1. [UC15 Заказ сконфигурированного компьютера]
1.1 Краткое описание
Клиент заполняет и отправляет форму заказа на покупку. Система
проверяет детальную информацию и подтверждает или отвергает заказ.
2. Поток событий
2.1 Основной поток
2.1.1 rUCIS.1 Система отображает Форму ввода заказа в окне Ввод заказа
броузера клиента. Фоома состоит из следующих цуи Ы У.В.-1
ГЦС15-1,1 фурма имеет ЗДГВД0В0К.Заказцьайте гхши-утеь.1
ГЦС15.1.2 Под заголсаком отображается пчясн^юи.ая информация.]
рриьштим ife&Kr ионсщзющай инфссцадци:
"Заполните- пожалуйста- поля Фромм- ,Приглашения для го«а
требуемых ответов доказана краевым псожирным шрифтом. Для
отправки формы нажмите копку если же вы решили нь
продолжать заполнение, Еы можете отказаться ст своего заказа
без арякого штрафа, е течение 24-х часов с момента опюаехи
заказа. Вы можете отказаться от отправленного заказа, прибегнув
к помеши Web, электронной почты. Факса или телефона."1
Описаний того, каким образом клиент может отказаться от заказа.
сорнпжится в документа“Спецификации псеинпента: Обновление
статуса заказа”,
[UC15.1.3 Реквизиты поставки].
[UC15.1,3.1 к требуемым реквизитам доставки относятся; имя,
страна- город, улица, курьерские направления.]
[UC15.1.3.2 К дополнительным реквизитам доставки отнссято:
шгррод. ццат^гфцсашакод.1
ШС_15.1._4 Интактная, иатфоомзиия. отличная ст той, 'отсрзе
предоставляется как реквизиты APCTSfi^J
эдььтрйнная цочтаггелефсн._факс, почта, курььрекадпочта.]
ruclfi.1.4.2 в качестве обязатадьнрйжснтактной-ин.Фсру аиии
сдиууст указать один иасньдуюших реквизитов; электронная
почта, телефон, Факс.]
UC15.1.4.3 В качестве шл;щ1нитйТ ЬНйЙ контактной
6.3. Наставление по проектному моделированию 273
информации можно указать два из трех контактных реквизита.
нааечисланпые как обяздтш^ьнын. и почтовый адрьс /цели PH
отдичаатся от указанного в реквизитах доставки).!
(UC15 15 Адррс/етстаают счат-фаггусы. если он отличаете* ут
реквизитов доставки.)
ГЦС15.1.6 Способ оплаты.!
IUC15.1.2,1 Клиент мажет выбрать в качества метода зешь! чь1-.
или кредитную каоточку.1
TUC15.1.S.2 При епдате р помощью чека система пр&цйстапянвт
подробную информацию- кому должен быть оплачен чек и
покдкому адресу ага следует доставить. Она также информирует
клиента- что на клиринг чека паслаполучения может
ШС15Л.5.3 При оплате с помощью кредитной карточки система
отображает реквизиты- которые диджеи заполнить клиент, к этим
реквизитам относится-, кирнчень допустимых кредитных каоточек-
номнр кредитной карточки, сдак действии-кредитной карточки.)
гиС15-1,7 Има-торгового представителя, если она известно клиенту
по прошлым сделкам.1
[ЦС15.1.8 Два командные кнопки: йтщдааить и оащндД
2.1.1 £U С .15 Q ц с т ем а „ паедд агаетьдне и т У._и а а аIи лрдробности,
касающиеся заказа- поместии указатель мыши на. пари о в
редактируемое пода (реквизит имени).) ГЦС15.3 Система позволяет
вводить информацию и произвольном порядка, 1
IUC15.4 Если клиент на отправляет и на аннулирует Форму в течение
15 минут, выполняется доьтеьнативный поток "Клиент не активен’’).)
2.1.3 [UC15.5 Если клиент нажимает кнопку Отправить, и вся необходимая
информация предоставлена, форма заказа отправляется на Web-
сервар. УУрД-ceuaeo связывается с сервером баз данных ддалого,
чтобы поместить заказ в базу данных.) [UC15.Q Сервер баз данных
Присваивает заказу пд покупку уникальный номер заказа и учетный
номер клиента.1
IUC15.7 Если сйрйнО баз данных не ь состоянии создать и запомнить
заказ- ампидняетсн ад\та»натиьный патак “Исключительная ситуации
Для БД".! ]
[UG15.8 Если клиент отццаадяат заказ с недцдиуй информацией.
выполняется альтернативный поток ‘‘Непалт.'ан-илфаомация’’,)
2.1.4 [UC15.9 Если клиент а качестве предпочтительного_____средства
коммуникации прадлстянпянт адрес., электронной лочты. система
отправляет клиенту заказ и номера клиента вместе со всеми
274 Глава 6. Основания проектирования систем
деталями, касающимися заказа, и подтверждением принятия заказа.
Прецедент _ завершается.] IUC15.10 В противном случае, детали,
касающиеся заказа, о тир а циню тс я клиенту по почте и прецедент
тзкжб завершается!
2.1.5 HJC15.11 Если клиент нажимает кнопку выполняется
альтернативный поток “Отмена”.!
2.2 Альтернативные потоки
2.2.1 Клиент неактивен
FUC15.4.1 Если клиент не проявляет акт^юсти в течение белес чем 15 минут.
система закрывает соединение с броузером. Гршндйнт завершается. 1
2.2.2 Исключительная ситуация для БД
1PQ15X1 Еспй база данных ьрзбуждает исключитадьную ситуацию, система
интерпретирует ее и иифррмирунт кдиедта о характера сшибки. Если клиент
пазорвал соединение система отправляет сообщение лб £шибкд пп
электронной почте клиннту и пролдвну- Прецедент завершается.!
Если с клиентом нет возможности связаться посредством Internet или
электронной почты, продавец должен связаться с клиентом с помощью
других средств.
2.2.3 Неполная информация
ГЦС15.Е.1 Если клиент не заполнил все необходимые реквизиты, система
предлагает клиенту прадоставить пропущенную информацию, Cuicjk
пропущенных реквизитов отображается, Преоедант пподрлжавтся, 1
2.2.4 Отмена
fUC15.11,l Если клиент нажал кнопку (гмв'за, залодцоииые-яо1>. Фармы
счищаются. Г ptцедент продолжаете»:. 1
3. Предусловия
3.1 Клиент указывает броузеру Internet на Web-страницу системы. Страница
отображает детальную информацию о конфигурации компьютера вместе с
ее ценой. Клиент нажимает кнопку Покупка. /
3.2 Клиент нажимает кнопку Покупка в пределах 15 минут с (момента запроса
на построение и отображение на странице броузера последней
конфигурации компьютера.
4. Постусловия
4.1 Если отправка заказа клиента прошла успешно, заказ на покупку
записывается в базу данных. В противном случае состояние системы не
изменяется.
6.3. Наставление по проектному моделированию 275
6.3.4.2. Структура кооперативного взаимодействия
Диаграмма классов, разработанная в ходе анализа, определяет постоянные классы
базы данных. Классы прикладной программы фактически нельзя определить до начала
проектирования. Следовательно, диаграмму классов, определяющую структуру не-
которой кооперации, необходимо разрабатывать практически “с нуля”. Классы,
участвующие в кооперации, разрабатываются для того, чтобы осуществить привяз-
ку к выбранной для приложения технологии, обеспечивающей его функциониро-
вание (разд. 6.3.2.1).
Web-страница может содержать сценарии, выполняемые на сервере или интерпре-
тируемые на клиентской машине броузером, или же сценарии обоих типов. Проекти-
рование кооперативного взаимодействия для Web-страницы — непростая проблема.
Технология, обеспечивающая функционирование, может не поддерживать надлежа-
щим образом объектно-ориентированного взгляда на мир. В некоторых случаях рабо-
та всего приложения может определяться одной Web-страницей, наполненной объек-
тами и апплетами.
Что касается более сложных Web-приложений, для них должна существовать воз-
можность разделения страниц на клиентские, серверные. С точки зрения подхода
BCED (разделы 6.1.3.2 и 6.3.1.2), клиентские страницы, представленные в формате
HTML, соответствуют пограничным классам. Серверные страницы могут, с одной
стороны, обладать ассоциативными связями с клиентскими страницами, а, с другой
стороны, с остальными ресурсами Web-сервера. Серверные страницы соответствуют
управляющим классам в иерархии BCED [15].
_ - , ........................ . .......................
у/ Наставление по проектированию: шагб (Internet-магазин)
• Обратитесь к проектному документу по прецеденту “Order Configured Computer'’, пред- .
i. ставленному в разделе 6.3.4.1.2. Основываясь на потоке событий, представленном в
j этом документе, нам требуется создать проект кооперации, отражающий ее структур- 1
J ный аспект, который реализует прецедент “Заказ сконфигурированного компьютера".
' Даже для такого простого прецедента детализированное проектирование кооперации
« выходит за рамки наставления. Поэтому мы сделаем некоторые упрощения. Нет необ-
\ ходимости обрабатывать все детали, касающиеся формы и схемы формы заказа (см.
t главу 7). Аналогично, с противоположной стороны, нет необходимости принимать ре-
' шение в отношении интерфейса между приложением и базой данных (т.е. мы не каса- -
I емся вопросов получения и запоминания информации в базе данных) (см. главу 8).
: В данном случае мы применяем подход BCED (разд. 6.3.1.2). Всем предложенным классам
I должны быть присвоены префиксы Ь, с, е, или d для обозначения их принадлежности соот- 8
j ветствующему уровню пакета BCED. Классы также должны быть отнесены к одному из сле-
I дующих стереотипов: «client раде» (клиентская страница), «form» (форма), «server j
I раде» (серверная страница), «entity» (сущность), «db interface» (интерфейс с БД). <
Следует определить все отношения ассоциации и агрегации между классами. Также сле-
I дует показать отношения материализации, чтобы обозначить поток сообщений материа- .
I лизованным объектам (отношение материализации изображается в языке UML с помощью
] пунктирных линий со стрелками, направленными от отправителя сообщения к классу, ко- j
> торый запрашивает материализацию нового объекта). Если объект материализован в ре-
i зультате инициированного пользователем события (например, пользователь нажимает
i командную кнопку), событие можно изобразить на линии материализации.
276 Глава 6. Основания проектирования систем
Рис. 6.30. Структурная сторона кооперации для прецедента “Order Configured
Computer” (Internet-магазин)
На рис. 6.30 приведена диаграмма классов, представляющая структурную сторону
кооперации для прецедента “Order Configured Computer”. Поскольку этот прецедент
составляет только часть приложения, а также с целью моделирования предусловий и
постусловий прецедента на рисунке показаны два класса вместе с их связями, принад-
лежащие другому прецеденту “Build Computer Configuration” (“Составление конфигура-
ции компьютера"). Это классы b_ConfigurationClientPac)e (Клиентская страница
конфигурации) и e_Conf iguration (Конфигурация).
Заметим, что событие покупки [on Purchase], инициируемое пользователем
при работе со страницей b ConfigurationClientPage, устанавливает окружение
прецедента. Класс b OrderClientPage отвечает за обработку содержимого клиент-
ской формы заказа b_OrderClientFonn. Форма представляет собой набор полей для
ввода информации с экрана, которая принимает входные данные от пользователя.
После того, как форма заполнена, она отправляется для обработки серверной стра-
нице (c_OrderServerPage).
6.3. Наставление по проектному моделированию 277
Четыре объекта, относящиеся к стереотипу «entity» (e Order, e_Conf iguration,
e Payment и e_Customer) хранят текущую информацию,относящуюся к заказу, незави-
симо от Web-страниц. Следует, однако, напомнить, что это всего лишь объекты памяти—
долговременное хранение заказа в базе данных выходит за рамки данного наставления.
С кооперацией связан объект d__Transaction (Транзакция), материализуемый
классом c_OrderServerPage после отправки заказа. Хотя класс d_Transaction и не
показан явно на диаграмме, он может взаимодействовать с базой данных с целью удо-
стовериться в том, что передача заказа в базу данных осуществлена надлежащим обра-
зом. Этот класс также представляет механизм приложения для управления состояни-
ем клиента — он вызывает размещение и удаление cookies с клиентской машины.
6.3.4.3. Поведенческая сторона кооперации
На рис. 6.31 приведена диаграмма классов, представляющая поведенческую сторо-
ну кооперации для прецедента “Order Configured Computer”. Диаграмма выражает
функциональные требования к прецеденту. Кооперативные действия начинаются в
тот момент, когда удовлетворяется первое предусловие прецедента и клиент нажима-
ет кнопку подтверждения покупки — Purchase. На диаграмме это событие моделиру-
ется как сообщение [ on Purchase] newOrderClientPage.
emailCustomer
Рис. 6.31. Поведенческая сторона кооперации для прецедента “Order Configured
Computer” (Internet-магазин)
278 Глава 6. Основания проектирования систем
Обратитесь к проектному документу по прецеденту “Order Configured Computer”, пред-
ставленному в разделе 6.3.4.1.2, и предыдущему шагу наставления (разд. 6.3.4.2). Ос- J
новываясь на потоке событий, представленном в этом проектном документе по преце-
денту, и готовности классов,показанных на рис. 6.30, нам требуется создать проект
кооперации, отражающий ее поведенческий аспект, который реализует прецедент
“Order Configured Computer".
Объект класса b_OrderClientPage обслуживает сообщение [on Purchase]
newOrderClientPage. Эта представленная в формате HTML страница содержит три
«form-объекта класса b_OrderClientForm (рис. 6.30). Атрибуты этого класса пред-
ставляют поля для ввода формы, включая две командные кнопки: Cancel (Отмена) и
Submit (Отправить).
После того, как клиентская страница отображает форму на экране броузера
(UC15.1), клиент может ввести информацию, касающуюся заказа (UC15.2 и UC15.3).
Команда Cancel (UC15.11.1), обслуживается объектом класса b_OrderClientPage (с
использованием метода, обновляющего содержимое страницы— refresh). В том
случае, когда клиент не заполнил все необходимые поля (UC15.8.1), команда Submit
также обслуживается объектом b_OrderClientPage (с использованием метода
incompleteOrder).
Когда клиент нажимает кнопку Submit и вся необходимая информация предос-
тавлена (UC15.5), управление передается классу c_OrderServerPage. Он создает
Объекты-сущности e_Order, e_Customer, e_Payment и e_Configuration. Первые
три объекта-сущности хранят реквизиты формы заказа, введенные клиентом.
Объект-сущность e_Configuration был материализован прежде другим преце-
дентом (“Build Computer Configuration”). Теперь он связывается с объектом e_Order
после того, как объект c_OrderServerPage получает его OID из атрибута связи, хра-
нимого в объекте b_OrderClientPage (между классами b_OrderClientPage и
b_Conf igurationClientPage определено отношение ассоциации).
После того, как объект e_Order материализован, начинается бизнес-транзакция.
С этой целью создается новый объект d_Transaction. Он управляет состоянием
клиента, включая интервалы, управляемые с помощью cookie. Если транзакция за-
вершается успешно, e_Order требует от e_Customer подтвердить получение заказа
клиентом с помощью электронной почты (UC15.9).
Если время хранения cookie истекает (UC15.4) или база Данных возвращает ошибку
(UC15.7.1), метод, реализующий откат— rollbackTransaction, требует от e_Order
удалить самого себя, а объект d_Transaction переходит в распоряжение операцион-
ной системы. Чтобы продолжить попытку заказа компьютера, клиенту может потребо-
ваться повторно ввести информацию в форму заказа. Модель взаимодействия между
обт^ектом О Transaction и сервером баз данных на диаграмме отсутствует.
Резюме
Этой главой было открыто рассмотрение проблем системного проектирования — в
ней представлены основания системного проектирования. Обсуждаемые здесь во-
просы были прямым продолжением предыдущей главы, посвященной углубленному
Вопросы 279
анализу требований. Были прояснены два основных (и различных) аспекта проекти-
рования — архитектурное проектирование и детализированное проектирование.
Типичные приложения ИС строятся на принципах архитектуры клиент/сервер.
Специфические решения на базе этой архитектуры включают распределенные системы
обработки и распределенные системы баз данных. Трехзвенные системы расширяют базовую
клиент/серверную архитектуру за счет выделения логики приложения в отдельный
логический и/или физический уровень.
Архитектурные решения оказывают влияние на проектирование интерфейсов
между приложением и базой данных. Иерархия пакетов, построенная на основе под-
хода ВСЕ (введенного в главе 5), была расширена за счет пакетов интерфейса с база-
ми данных и образования иерархии пакетов BCED.
Повторное использование представляет собой один из важнейших проектных
факторов, который влияет как на архитектурные решения, так и на вопросы детали-
зированного проектирования. Решение проблемы повторного использования сво-
дится к выбору между повторным использованием инструментальных средств, каркасов
и шаблонов. Эти варианты выбора не являются взаимно исключающими — напротив,
рекомендуется применять комплексную стратегию. Повторное использование за счет
использования внешних источников следует увязывать с внутренним проектировани-
ем пакетов, компонент, классов и интерфейсов. В конечном итоге вычислительные
ресурсы представляются в виде диаграммы развертывания.
Детализированное проектирование концентрируется на Kootiepa-ции. Кооперация
определяет реализацию прецедентов или операций. Кооперация дает модель переда-
чи сообщений между объектами. При этом необходимо учитывать такие факторы, как
замещение, перегрузка, итерация, шаблоны, автосообщения, асинхронные сообще-
ния и обратные вызовы. Структурные аспекты кооперации моделируются в виде диа-
грамм классов, а поведенческие аспекты — в виде диаграмм кооперации.
Глава завершается наставлением с решениями для упражнений по проектному мо-
делированию— продолжением наставления по анализу, представленному в главе 2
(при этом используется приложение Internet-магазин). Наставление служит иллюстра-
цией использования методов проектирования языка UML — проектирования пакетов,
компонент, развертывания и кооперации.
В1.
Вопросы
Объясните, в чем состоит различие между распределенной системой обработки и распре-
деленной системой баз данных.
В2. Что такое трехзвенная архитектура? В чем ее преимущества и недостатки?
ВЗ. Что мы понимаем под активной базой данных?
В4. Каково назнвчение пакета баз данных в подходе BCED?
BS. Что общего и каковы различия между повторным использованием инструментальных
средств и каркасов?
Вв. Каким образом компоненты и пакеты соотносятся между собой?
В7. Что такое доминантный класс?
В8. Что такое отношение соединения?
В9. Что такое отношение реализации, используемое в кооперации? Приведите пример
(отличный, от приведенного в книге).
280 Глава 6. Основания проектирования систем
В10. Какими альтернативными способами можно представить аргументы сообщения на диа-
граммах кооперации?
В11. Какие типы сообщений можно отнести к осноаным (помимо конструкторов и деструкторов)?
В12. В чем заключается различие между замещением и перегрузкой?
В13. Каким образом итеративные сообщения связаны с коллекциями?
В14. Отправитель сообщения может послать или не посылать свой OID целевому объекту.
Справедливо ли данное утверждение применительно к асинхронным сообщениям? Пояс-
ните свой ответ.
В15. Какие диаграммы языка UML используются для проектирования структурного аспекта коо-
перации? Объясните, насколько они подходят для выполнения этой задачи.
В1в. Какие диаграммы языка UML используются для проектирования поведенческого аспекта
кооперации? Сравните, насколько они подходят для выполнения этой задачи.
В17. Сравните, насколько пакеты прецедентов и пакеты классов применимы на этапах анализа
и проектирования жизненного цикла разработки систем.
Упражнения
I Рассмотрите следующие дополнительные требования для приложения Магазин видео-
проката (эти требования изложены в конце главы 4 и для удобства повторены здесь).
1. За кассеты и диски, возвращенные позже срока, взимается дополнительная плата
за период, превышающий срок проката. Каждый видеоноситель обладает уникаль- .
ным идентификационным номером.
2. Фильмы заказываются у поставщика, который в общем случае может поставить кассеты и
диски в течение одной недели. Обычно один заказ делается на несколько фильмов.
3. Забронировать можно те фильмы, которые заказаны у поставщика и/или все копии
которых находятся в прокате. Можно также забронировать те фильмы, которых нет в
запасе и которые не заказаны у поставщика; при этом с клиента требуется задаток
за один период проката.
4. Клиент может также сделать несколько предварительных заказов, однако, для каж-
дого забронированного фильма готовится отдельный запрос на бронирование. Бро- .
пирование может быть отменено из-за отсутствия реакции со стороны клиента, бо-
лее точно, в течение одной недели с момента, когда клиенту было сообщено о воз- '
можности взять фильм напрокат. Если за фильм был уплачен задаток, он '
записывается на счет клиента.
5. База данных хранит обычную информацию о поставщиках и клиентах, т.е. адреса,
телефонные номера и т.д. В каждом заказе поставщику указываются заказываемые -
фильмы, их количество, форматы кассеты/диска, а также дата ожидаемой доставки,
отпускная цена, возможные скидки и т.д.
в. Когда кассета возвращается клиентом или поступает от поставщика, вначале удов- ,
летворяются предварительные заказы. Работники магазина устанавливают контакт с ’
клиентами, сделавшими предварительный заказ. Для правильной обработки брони-
рования фильмов информация, связанная с бронированием, обновляется дважды: j
после установления контакта с клиентом, когда ему сообщается, что
“забронированный фильм пришел”, и после сдачи фильма клиенту напрокат. Эти
шаги гарантируют правильное проведение операции бронирования.
7. Клиент может взять несколько кассет или дисков, однако, каждому взятому видео- *
носителю ставится в соответствие отдельная запись. Для каждого выдаваемого на- •
прокат фильма фиксируются дата и время выдачи, установленный и фактический
Упражнения 281
срок возврата. Позже запись о прокате обновляется, чтобы отразить факт возврата
видеофильма и факт окончательного платежа (или возврата денег). Кроме того, за-
пись хранит информацию о продавце, отвечающем за прокат фильма. Детальная
информация о клиенте и по прокату хранится в течение года, чтобы можно было лег-
ко определить уровень доверия к клиенту. Старая информация по прокату сохраня- L
ется в течение года в целях проведения аудита.
8. Все операции выполняются с использованием наличности, электронного перевода
денег или кредитных карточек. От клиентов требуется внести плату за прокат при
выдаче кассет/дисков.
9. Если кассета/диск возвращены позже установленного срока (или не могут быть воз-
вращены по каким-либо причинам), плата снимается либо со счета клиента, либо
принимается непосредственно от клиента.
10. Если кассета/диск задержаны более, чем на два дня, клиенту отправляется уведом-
ление о задержке. После отправки двух уведомлений о задержке одной и той же кас-
сеты/диска клиент предупреждается о том, что он является “нарушителем", и при
следующем его обращении в магазин руководство рассматривает вопрос о снятии с •
него статуса “нарушителя”.
У 1. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений
для приложения Магазин видеопроката в конце главы 4.
Спроектируйте структурную диаграмму кооперации для реализации прецедента
“Резервирование видео” (“Reserve Video").
У 2. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений
для приложения Магазин видеопроката в конце главы 4.
Спроектируйте поведенческую диаграмму кооперации для реализации прецедента
"Резервирование видео”.
У З. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений
для приложения Магазин видеопроката в конце главы 4.^ -
Спроектируйте структурную диаграмму кооперации длй реализации прецедента "Возврат
видео” ("Return Video”).
У 4. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений
для приложения Магазин видеопроката в конце главы 4.
Спроектируйте поведенческую диаграмму кооперации для реализации прецедента
“Возврат видео”.
У 5. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упрвжнений
для приложения Магазин видеопроката в конце главы 4.
Спроектируйте структурную диаграмму кооперации для реализации прецедента “Заказ
видео” (“Order Video”).
У 8. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям
и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений
для приложения Магазин видеопроката в конце главы 4.
Спроектируйте поведенческую диаграмму кооперации для реализации прецедента "Заказ
видео”.
282 Глава 6. Основания проектирования систем
У7. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений для приложения Магазин видеопроката в конце главы 4. Спроектируйте структурную диаграмму кооперации для реализации прецедента “Сопровождение клиентов" (“Maintain Customer").
У8. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям и к примеру 4.14 (разд. 4.3.1.3). За помощью обратитесь также к решениям упражнений для приложения Магазин видеопроката в конце главы 4. Спроектируйте поведенческую диаграмму кооперации для реализации прецедента “Сопровождение клиентов".
У9. Магазин видеопроката — обратитесь к примеру 4.16 (разд. 4.3.2.3). Рассмотрите вид деятель- ности Update Stock (Обновление запаса), показанный на рис. 4.13. За помощью обратитесь также к решениям упражнений для приложения Магазин видеопроката в конце главы 4. Изобразите диаграмму видов деятельности для реализации операции update stock.
Проектирование
пользовательского интерфейса
Дни, когда экран компьютера напоминал “великого немого” и светился скучным зе-
леным цветом, а клавиатура служила единственным устройством ввода информации,
ушли в прошлое. Сегодня экраны отличаются большей “смышленостью” и практически
неограниченным цветовым разнообразием, а пользователь для управления выполнени-
ем программы вооружен мышью (не говоря уже о речевом и тактильном вводе). Конеч-
но, программы по-прежнему создаются в расчете на то, чтобы не допустить неверных
или запрещенных действий, однако сдвиг в управлении от алгоритма к пользователю
заметно повлиял на способы проектирования и реализации GUI-систем.
Разработка пользовательского интерфейса начинается с ранних набросков диало-
говых GUI-окон на этапе анализа требований. Эти наброски используются в процессе
сбора требований, при разборе возможных сценариев.работы системы с заказчиками,
для создания прототипов и для включения документов описания прецедентов. В про-
цессе проектирования осуществляется дальнейшая разработка окон GUI-интерфейса
для приложения в соответствии с основными возможностями презентационного ПО
GUI-интерфейса, а также особенностями и ограничениями выбранной программной
среды. Эти вопросы являются предметом рассмотрения данной главы.
7.1. Проектирование интерфейса как
междисциплинарная деятельность
Проектирование графического интерфейса пользователя (GUI — Graphical User
Interface) представляет собой междисциплинарную деятельность. Оно требует усилий
многофункциональной бригады — один человек, как правило, не обладает знаниями,
необходимыми для реализации многоаспектного подхода к проектированию GUI-
интерфейса. Надлежащее проектирование GUI-интерфейса требует объединения на-
выков художника-графика, специалиста по анализу требований, системного проекти-
ровщика, программиста, эксперта по технологии, специалиста в области социальной
психологии, а также, возможно, некоторых других специалистов, в зависимости от
характера системы.
284 Глава 7. Проектирование пользовательского интерфейса
Типичный процесс проектирования GUI-интерфейса для приложений ИС начина-
ется с прецедентов. Аналитик, занимающийся описанием потока событий для прецеден-
та, обладает некоторым зрительным образом GUI-интерфейса для поддержки челове-
ко-машинного взаимодействия. Сложные человеко-машинные взаимодействия нельзя
верно передать, пользуясь лишь “языком прозы”. Иногда процесс сбора и согласования
требований заказчика делает необходимым выработку эскизов GUI-интерфейса.
Проектировщик, участвующий в определении кооперативных взаимодействий для
реализации прецедентов, должен иметь ясное зрительное представление о том, как
выглядят экранные отображения, выраженные с помощью GUI-интерфейса. Если до
него этого уже не сделал аналитик, проектировщик становится первым человеком,
который вырабатывает графические представления пользовательского интерфейса.
Эти графические представления, предлагаемые проектировщиком, должны соответ-
ствовать технологии, на которой базируется GUI-интерфейс — средствам организа-
ции окон и элементам управления окнами, Internet-броузерам и т.д. Чтобы успешно
воспользоваться технологическими возможностями, может потребоваться прибег-
нуть к консультации эксперта в области технологии.
Прежде, чем проект кооперативных действий классов попадет к программистам
для реализации, необходимо сконструировать прототип GUI-экранов, “дружествен-
ный” пользователю. Для решения этой, задачи привлекаются художники-графики и спе-
циалисты по социальной психологии. Совместно они могут предложить привлекатель-
ный и удобный GUI-интерфейс.
Задача программиста заключается не в том, чтобы слепо реализовать экраны, но
также предложить изменения, обусловленные средой программирования. В некото-
рых случаях изменения могут привести к улучшению GUI-интерфейса, в других случа-
ях изменения отрицательно сказываются на проекте из-за ограничений, связанных с
программированием или продуктивностью.
Из приведенного выше краткого обсуждения ясно, что проектирование GUI-
интерфейса — очень обширная задача. На тему разработки GUI-интерфейса написано
много книг, уделяющих основное внимание различным аспектам этой деятельности
[16], [27], [26], [59], [73], [92]. В данной главе мы сконцентрируемся на том, что
должен знать системный проектировщик, чтобы в сотрудничестве с другими специали-
стами разработать у дачньт интерфейс.
7.2. Интерфейс: от прототипа к реализации
Основной момент в проектировании GUI-интерфейса заключается в том, что кон-
троль находится на стороне пользователя (при условии, что система, а не пользователь,
контролирует системную целостность, защиту и безопасность). Современные объект-
но-ориентированные программы управляются событиями. Объекты реагируют на со-
бытия (сообщения). Внутренние взаимодействия между объектами запускаются
внешними событиями, инициируемыми пользователем.
“Впечатление и ощущение” от GUI-интерфейса служит “двигателем торговли” при
продаже программного продукта заказчику. Прототипы GUI-интерфейса могут слу-
жить двоякой цели оценки “ощущения” от GUI-экранов и передачи его функций. Ис-
тинное “впечатление” становится доступным на этапе реализации.
Прототип GUI-интерфейса для класса Organization представлен на рис. 7.1, его
основной целью является визуализация данных и контроль объектов, расположенных
7.2. Интерфейс; от прототипа к реализации 285
в окне. Обратная связь с пользователями, получаемая в виде их откликов, а также
идеи бригады разработчиков GUI-интерфейса изменяют “впечатление” от окна, а,
возможно, и “ощущение” от него.
Е
Обратитесь к постановке задачи для приложения Управление контактами с клиентами
(разд. 2.3.3), в также к решенным примерам в главе 4. В частности, рассмотрите проект
класса Organization в примере 4.8 (разд. 4.2.2.3).
Цель этого примера — продемснстрирсввть то, каким изменениям может подвергнуть-
ся GUI-зкран для класса Organl zatlon от первоначального прототипа до конечной реа-
лизации. Мы предполагаем, что в качестве бвзсесй технологии создания GUI-
интерфейса выступает технология Microsoft Windows.
На рис. 7.2 показана возможная реализация окна Organization как диалогового.
Как можно видеть из рисунка, программист предпочел реализовать окно в виде вкла-
док; кроме того, в окно был внесен ряд других изменений, касающихся “впечатления
и ощущения” от него, таким образом, чтобы привести их в соответствие с принципа-
ми проектирования GUI-интерфейса для MicrosoftWindows.
Рис. 7.1. Прототип окна для класса Organization (Управление контактами
с клиентами)
286 Глава 7. Проектирование пользовательского интерфейса
Рис. 7.2. Реализованное окно для класса Organization (Управление
контактами с клиентами)
7.3. Руководящие принципы проектирования
интерфейса, ориентированного на
пользователя
Центральным звеном при проектировании GUI-интерфейса выступает пользова-
тель. Это замечание послужило основанием для ряда приводимых ниже рекомендаций
разработчикам ПО. Руководящие принципы опубликованы производителями GUI-
интерфейсов [92]. Они также служат предметом обсуждения многих книг [27], [73].
Руководящие принципы служат разработчикам основанием для построения GUI-
интерфейса. При принятии любых проектных решений в отношении GUI-интерфейса
они должны использоваться разработчиками на подсознательном уровне. Некоторые
из этих руководящих принципов выглядят как хорошо известные старые истины, дру-
гие основаны на современной GUI-технологии.
7.3.1. Контроль — на стороне пользователя
“Контроль - на стороне пользователя" — вот главнейший принцип построения GUI-
интерфейса. Лучше было бы назвать этот принцип пользовательским восприятием кон-
троля. Некоторые называют его принципом отсутствия какой-либо “материнской опе-
ки — программа не должна действовать как ваша заботливая мать, делая многие вещи
7.3. Руководящие принципы проектирования интерфейса... 287
за вас [89]. Основной смысл этого принципа заключается в том, что пользователь
инициирует действия, и если в результате этого контроль переходит к программе, то
пользователь получает необходимую обратную связь (в виде курсора в форме песочных
часов, индикатора ожидания или аналогичным способом).
Рис. 7.3 демонстрирует типичный поток управления в человеко-машинном взаи-
модействии. Событие, инициированное пользователем (выбор пункта меню, щелчок
мышью, перемещение указателя мыши по экрану и т.д.), может привести к открытию
окна GUI-интерфейса или вызову программы— как правило, программы на языках
типа 4GL или SQL в рамках приложения ИС. Программа временно перехватывает
контроль у пользователя.
Процесс выполнения программы имеет возможность вернуть управление назад
тому же или другому окну. В другом случае он может вызвать другой модуль на языках
типа 4GL или SQL или вызвать внешнюю процедуру. В некоторых случаях программа
может кое-что делать для пользователя. Это возможно, к примеру, если программе
требуется выполнить вычисления, которые обычно связаны с явным пользователь-
ским событием, или если программа перемещает указатель на другое поле экрана, а
для события перемещения с исходного поля предусмотрен обработчик события вы-
хода, связанный с ним.
7.3.2. Согласованность
Согласованность несомненно является вторым основным принципом разработки ка-
чественного интерфейса. Фактически согласованность означает соблюдение стандар-
тов и следование некоторым общепринятым правилам работы с GUI-интерфейсом. Со-
гласованность может рассматриваться, по меньшей мере, в двух аспектах.
Соответствие стандартам поставщика GUI-интерфейса.
Соответствие стандартам в области именования, программирования и другим,
разработанным внутри организации стандартам, которые связаны с GUI-
интерфейсом.
Оба аспекта одинаково важны, и второй (на который оказывают влияние разра-
ботчики) не должен противоречить первому. Если приложение разрабатывается
для Windows, то следует обеспечить “впечатление и ощущение”, свойственные ра-
боте в системе Windows. Для системы Macintosh замена знаменитого “яблочного”
меню вложенным меню (типа “кенгуру”), как это раз попытался сделать автор, во-
обще никудышная идея!
Разработчик GUI-интерфейса не должен слишком увлекаться творчеством и предла-
гать необычные новшества. Это может плохо сказаться на уверенности и умении поль-
зователей. Пользователям следует представлять знакомую среду, поведение которой
предсказуемо. Как\заметил Трайсман (Treisman) [89], можно представить, какова была
бы реакция автомобилистов, если бы производитель автомобилей выпустил на рынок
новую машину, у которой поменяли местами педали скорости и тормоза!
Не следует также недооценивать соответствие внутренним стандартам в об-
ласти именования, программирования, аббревиатур и т.п. Сюда относятся име-
нование и программирование меню, командных кнопок, полей экранов, также
стандарты по расположению объектов на экране и последовательному использо-
ванию элементов GUI-интерфейса в рамках всех приложений, разрабатываемых
собственными силами.
288 Глава 7. Проектирование пользовательского инте
GUI-интерфейс
Событие Процедура 4GL-SQL
Обработка
правила
или выхода
Процедура 4GL-SOL Внешняя программа
Рис. 7.3. Поток управления GUI-программы
7.3.3. Индивидуализация и настройка
Индивидуализация и настройка— два взаимосвязанных принципа разработки GUI-
интерфейса. Индивидуализация GUI-интерфейса — это просто его настройка под пер-
сональные нужды, в то время как настройка — так, как мы понимаем ее здесь — админи-
стративная задача приспособления ПО к требованиям различных групп пользователей.
Примером индивидуализации является изменение пользователем порядка и раз-
меров колонки в программе просмотра строк (так называемые сетки — grid) с после-
дующим сохранением этих изменений как его личных предпочтений. При обращении
к этой же программе в будущем данные предпочтения учитываются.
Примером настройки является различие в функционировании программы по от-
ношению к опытным пользователям и пользователям-новичкам. Например, пользова-
телю-новичку программа может предложить явную помощь и дополнительные преду-
преждающие сообщения, указывающие на потенциальную опасность некоторых со-
бытий, инициируемых пользователем.
Во многих случаях различия между индивидуализацией и настройкой весьма раз-
мыты и малозаметны. Изменение пунктов меню, создание новых меню и т.п. попада-
ют в обе категории. Если они предназначены для индивидуального использования —
это индивидуализация. Если они осуществляются системным администратором в ин-
тересах всего коллектива пользователей — это настройка.
7.3. Руководящие принципы проектирования интерфейса... 289
7.3.4. Терпимость к ошибкам
Хорошо спроектированный интерфейс должен позволять пользователям экспе-
риментировать и совершать ошибки, проявляя терпимость к ошибкам. Подобная тер-
пимость стимулирует исследовательскую активность пользователя, поскольку позво-
ляет ему выполнять ошибочные последовательности действий с возможностью в лю-
бой момент совершить при необходимости “откат” в начало. Терпимость к ошибкам
подразумевает многоуровневую систему отмены операций.
Об этом принципе легко говорить, однако, он трудно поддается реализации. Реа-
лизация терпимости к ошибкам в интерфейсе отличается особой сложностью для
многопользовательских приложений баз данных. Пользователь, который снял (и по-
тратил) деньги с банковского счета, не имеет возможности отменить эту операцию!
Единственное, что он в состоянии сделать— исправить ошибку (если, конечно, это
было ошибкой!), положив деньги назад на счет, осуществив другую операцию. Дол-
жен или не должен терпимый к ошибкам интерфейс предупреждать пользователя о
последствиях снятия денег со счета — вопрос спорный (и относится он к принципу
индивидуализации интерфейса).
7.3.5. Обратная связь
Принцип обратной связи дополняет первый принцип — контроль должен нахо-
диться на стороне пользователя. Контролировать ситуацию — значит знать, что
происходит, когда контроль временно передается программе. Разработчик дол-
жен встроить в систему визуальные или/аудиоподсказки для каждого события,
инициируемого пользователем.
В большинстве случаев указатель в форме песочных часов или индикатор ожи-
дания представляет достаточный уровень обратной связи, чтобы понять, что
программа что-то делает. Для тех компонент приложения, которые иногда могут
стать источником проблем с производительностью, может потребоваться более
ясная обратная связь (например, в виде отображения поясняющего сообщения).
В любом случае, разработчик никогда не должен предполагать, что приложение
выполняется настолько быстро, что обратная связь не потребуется. Любые от-
клонения в рабочей нагрузке приложения докажут, что разработчик, к сожале-
нию, ошибался.
7.3.6. Эстетичность и удобство
Эстетичность интерфейса влияет на зрительное восприятие системы. Удобство ка-
сается легкости, простоты, эффективности, надежности и продуктивности в исполь-
зовании [интерфейса. Безусловно, оба принципа касаются удовлетворенности пользо-
вателя. Именно в этом вопросе разработчик GUI-интерфейса нуждается в помощи ху-
дожника-графика и эксперта по социальной психологии.
Существует много разнообразных “золотых правил”, касающихся создания эсте-
тичного и удобного интерфейса [27], [16]. При этом следует учитывать такие вопро-
сы, как фиксация и движение человеческого глаза, использование цветов, чувство
уравновешенности и симметрии, выравнивание и отступ между элементами, чувство
пропорции, группирование связанных элементов и т.д.
Принцип эстетичности и удобства превращает разработчика GUI-интерфейса в
художника. В этом смысле неплохо помнить о том, что “простота — эталон красоты”. В
290 Глава 7. Проектирование пользовательского интерфейса
действительности простоту часто рассматривают как еще один принцип создания
GUI-интерфейса, прочно связанного с принципами эстетичности и удобства. В слож-
ных приложениях простота лучше всего достигается с помощью подхода “разделяй и
властвуй” за счет последовательного раскрытия информации таким образом, что она
отображается только тогда, когда в ней возникает необходимость, возможно, в раз-
личных окнах.
7.4. Оконный интерфейс
Проектирование GUI-интерфейса характеризуется двумя основными аспектами —
проектированием окон и проектированием элементов ввода и редактирования ин-
формации в окна. Оба аспекта зависят от базовой среды GUI. Последующее рассмот-
рение концентрируется на среде Microsoft Windows [92].
Типичное Windows-приложение состоит из единственного главного окна приложе-
ния (primary window)-. Главное окно поддерживается набором всплывающих окон (pop up
window), вторичных окон (secondary window). Вторичные окна поддерживают действия
пользователя с главным окном. Многие действия, поддерживаемые вторичными ок-
нами, представляют собой набор основных операций над базой данных — так назы-
ваемый набором CRUD-операций. (GRUD— популярная аббревиатура, которая обо-
значает четыре основных операции над данными: Create, Read, Update, Delete
(“Создать”, “Читать”, “Обновить” “Удалить”).
7.4.1. Главное окно
Главное окно имеет границу (рамку). Рамка содержит строку заголовка для окна,
строку меню, панели инструментов, строку состояния, а также отображаемое и моди-
фицируемое содержимое окна. Горизонтальные и вертикальные полосы прокрутки
используются для прокрутки, при необходимости, содержимого окна.
Отображаемое и модифицируемое содержимое может быть организовано в виде по-
докон (панелей). Панели позволяют осуществлять просмотр и манипулирование раз-
личными, но связанными между собой информационными элементами содержания. На
рис. 7.4 показано главное окно, которое отображается после успешного входа в систем}'
и открытия приложения. Панель в левой части окна содержит схему приложения в сти-
ле программы the Windows Explorer (кнопка закрытия в правом верхнем углу панели го-
ворит пользователю о том, что при желании панель можно убрать из окна). Коммента-
рии соответствуют хорошо известной терминологии Windows.
Типичными обличительными чертами главного окна являются наличие строки
меню и панели инструментов. Панель инструментов содержит командные кнопки для
наиболее часто используемых пунктов меню. Пиктограммы панели инструментов дуб-
лируют эти пункты меню. Они предназначены для быстрого доступа к наиболее часто
используемым командам.
7.4. Оконный интерфейс 291
Пиктограмма
строки
заголовка
Текст заголовка
Панель
Строка
состояния
Строка мен
Панель
инструментов
Вертикальная
полоса
прокрутки
Горизонтальная
полоса
прокрутки
Кнопки минимизации, максимизации
и закрытия окна
EN3iXReference
Й Si Dictionary
' BlAd
Bl Ad Link
[И Ad Link Merge...
Bl Advertiser
Bl Advertiser Gro
Ф Ouelrty Control
B) Agency
-1Й Agency Groups
t- Bl Brand...
Bl Category
|.Bl Category Produ
‘ Bl Contact
|। И1 Link Restriction
Bl Organisation
; j- Bl Outlet
'-Bl Product
i ffi Cj Raw Ad
EL-J Reports
и Qi System
Рис. 7.4. Главное окно приложения
Обратитесь к постановке задачи для приложения Управление контактами с клиентами
(разд. 2.3.3), а также к решенным примерам в главе 4. Одно из требований пользовате-
ля заключается в том, чтобы приложение Управление контактами с клиентами было по-
строено на функциональной модели диалогового окна Calendar программы Microsoft
Outlook (рис. 7.5).
Главное окно должно отображать виды деятельности, запланированные на день для ра-
ботника, использующего систему. Элемент управления Calender может отображать дея-
тёльность, относящуюся как к прошлому, так и к будущему. Мероприятия, запланиро-
ванные на определенное время дня (спланированные по времени), должны отображать-
ся в левой панели окна Microsoft Outlook. Однако, пользователи выдвигают также
требование об отображении и обработке не спланированных по времени, просроченных
(“ожидаемых” в прошлом) и завершенныхмероприятий.
Наша задача в этом примере заключается в проектировании главного окна для прило-
жения Управление контактами с клиентами, удовлетворяющем приведенным выше тре-
бованиям.
Ж
292 Глава 7. Проектирование пользовательского интерфейса
Рис. 7.5. Окно Calendar программы Microsoft Outlook
На рис. 7.6 показано главное окно приложения Управление контактами с клиентами.
В целях экономии места элемент управления Calendar спроектирован как “съемное”
плавающее окно. При желании его можно закрыть. Для каждого мероприятия в левой
панели отображается краткое описание мероприятия и либо название организации,
либо имя контактного лица. Кроме того, для некоторых мероприятий может отобра-
жаться дополнительная информация, например, телефонный номер организации
или контактного лица, номер факса или адрес. Используемая в этой книге черно-
белая печать не дает возможности в полной мере оценить использование цветов в ле-
вой панели главного окна. В частности, цвета используются для обозначения приори-
тетов, назначенных мероприятиям (высокий — красный, обычный — черный и низ-
кий — синий).
Правая панель служит трем целям. Она отображает три типа мероприятий. Завер-
шенные мероприятия переносятся из левой панели и размещаются в верхней части
правой панели. Текст описания этих мероприятий отображается в синем цвете и за-
черкивается. Основная причина, по которой завершенные мероприятия вообще не
удаляются с экрана, состоит в том, что иногда требуется придать завершенным меро-
приятиям статус “незавершенных” (положим, что мы преждевременно решили, что
работа выполнена, однако позже выяснили, что она еще не вполне закончена).
Просроченные мероприятия перечислены в правой панели. Они отображаются
красным шрифтом. Наконец, мероприятия, которые не спланированы по времени, ото-
бражаются черным цветом и перечисляются в нижней части правой панели. Левая
колонка панели спроектирована в расчете на людей, которые не различают цветов.
Соответствующие пиктограммы обозначают три типа мероприятий, которые могут
присутствовать в правой панели.
ТА. Оконный интерфейс 293
Рис. 7.6. Главное окно приложения “Управление контактами с клиентами”
7.4.1.1. Окно просмотра строк
Часто главное окно приложения ИС используется в качестве окна просмотра строк
для отображения записей базы данных, содержащих, к примеру, данные о сотрудни-
ках. Подобное окно иногда называют броузером строк (row browser) по аналогии с Web-
броузером. Пользователь имеет возможность “прокручивать" строки вверх и вниз с
помощью вертикальной полосы прокрутки или клавиш клавиатуры (<Page Up>, <Page
Down>, <Home>, <End>, а также стрелок “вверх” и “вниз").
На рис. 7.7 показан пример окна просмотра строк. Документ, помеченный как Ad
Link, внутри главного окна является дочерним окном (child window) (это понятие объяс-
няется позже). Дочернее окно обладает собственным набором кнопок управления окном
(window button) (для минимизации, восстановления, закрытия), расположенных в пра-
вом углу строки меню. Ширину колонок сетки броузера можно изменять, также как и
порядок их расположения. Округлые вмятинки рядом с именами колонок указывают на
то, что колонки можно сортировать — щелчок мышью на колонке вызывает сортиров-
ку записей в порядке возрастания или убывания значений в этой колонке.
В любой данный момент времени в окне просмотра строк активна только одна
строка (запись). Двойной щелчок мышью на этой строке обычно приводит к отобра-
жению “окна редактирования" (edit window), которое содержит детали, относящиеся к
этой записи. Окно редактирования позволяет модифицировать содержимое записи.
Панели могут использоваться для разделения окна по вертикали или по горизонта-
ли, либо в обоих направлениях. Рис. 7.8 иллюстрирует разделение окна по горизонта-
ли. Как ясно из заголовка окна, три панели используются для отображения товаров по
рекламодателям и рекламным агентствам. Средняя панель содержит перечень рекла-
модателей, связанных с текущим выбранным (выделенным) рекламным агентством,
показанным в верхней панели. Нижняя панель, в свою очередь, отображает товары,
рекламируемые выбранным рекламодателем.
294 Глава 7. Проектирование пользовательского интерфейса
44301 Capri Body Fashion Lingerie St Capri Body Fashions Direct AcK-ertiser ATMC
44302 Capri Body Fashion Lingerie St Capri Body Fashions Direct Advertiser ATMC
44303 Capri Body Fashion Lingerie St Capri Body Fashions Direct Advertiser ATMC
703135 Classic Sounds Hi Fi Str Classic Sounds Hi Fi Direct Advertiser ATMC
791837 Classic Sounds Hi Fi Str Classic Sounds Hi Fi Direct Advertiser ATMC
767987 Classic Sounds Hi Fi Str Classic Sounds Hi Fi DirectAdvertiser ATMC
936551 Classic Sounds Hi Fi Str Classic Sounds Hi Fi Direct Advertiser ATMC
1008655 Classic Sounds Hi Fi Str Classic Sounds Hi Ft Direct Advertiser ATMC
612797 Centrepoint T oyota Dealers Centrepoint Toyota Dealers Direct Advertiser ATMC
612814 Centrepoint Toyota Dealers Centre point Toyota Dealers Direct Advertiser ATMC
1076412 NWS9 Promotions/Competiti... NWS9(SA) Young & Rubicam Adelaide (... ATMC
1461650 NWS9 Promotions/Competiti... NWS9(SA) Media Edge\Yng & Rubicam . ATMC
960401 Gateway T asmaniaTourism Gateway Tasm ania Ltd Andrews ThomasbMallinson (... ATMC
955070 Gateway Tasmania Tourism Gateway T asmania Ltd Andrews Thomas&Mellinson (... ATMC
1177271 Meander HorseDrawn Coach... Meander Coaches Direct Advertiser ATME
964005 Gateway Tasmania Tourism Gateway T asmonia Ltd Andrews Thomas&Mallinson (... АТМЁ
1403901 Atomfeet Student Film Festival AustTeachers Of Media Direct Advertiser ATME
617464 Examiner Newspaper Examiner Newspaper Launce... Direct Advertiser ATME
628623 Examiner Newspaper Examiner Newspaper Launce.. ZZ TV Agency (TV Use Only) ATME
617484 Examiner Newspaper Examiner Newspaper Launce .. Direct Advertiser ATME
1—|1Г11ИГТГ~~
Рис. 7.7. Окно просмотра строк
Wade-Ferrell Larkins (NSW)
Walker Wimble Media (NSW) acaedidetion confirmed june 96 Doug
Webster Marketing Svcs (NSW) (02) 62281800. Gill 15/12/98. j
WhybinTBWA 8 Partners (NS... Previously known as Box Emery & Partners media buying lor this agency is thru BO,
Puc. 7.8. Многопанелъное окно просмотра строк
1А. Оконный интерфейс 295
u-Й AdE х2000 Dola Collerhun «nd Quality Control - [Agency Groups]
[Al'j: iVIl/i >>ub-Gr.jUjj|
C&N Advertising Pty Ltd (VIC)
Francis Agency The (VIC)
Leeds Media & Comm Svcs (...
Magnum Opus Advertising (VI...
Nicholson Guthrie Advtg (VIC)
Sanford Vide & Assoc (VIC)
SSB Advertising (VIC)
Us Advertising (VIC)
Wilson Everard Advtg (VIC)
557 AIS Media (VIC)
612
677
816
724
628
588
499
568
665
Agency Groups
В Gi Carat Consortium
; Й-€Э Carat Australia Media Group
. ’- Carat Australia Sub-Group(NSW)
- £3 Equmedia Consortium
' a AIS Group
i Ф-Q AIS Media (NSW) Sub-Group
* i $• О AJS Media (OLD) Sub-Group
* i Ф-Q AJS Media (SA) Sub-Grou^.
i to
j ф-О AIS Media (WA) Sub-Group
j Ф-CJ Total Media (VIC) Sub-Group
I Hl QJ Bowtell Clarke Yole Group (WA)
i ф-Qj Charterhouse Adv Sub-Group
I ф О DMB&B Group
i ф О Euro RSCG Partnership Group
i &-Q MediaCompete Group
Puc. 7.9. Окно с панелями просмотра дерева и строк
7.4.1.2. Окно просмотра деревьев
Еще один популярный способ использования главного окна — окно просмотра деревь-
ев, которое иногда называют броузером деревьев (tree browser). Программа просмотра де-
ревьев отображает связанные записи в виде схемы с отступами. Схема содержит эле-
менты управления, которые позволяют сворачивать и разворачивать дерево. Хорошо
известный пример броузера деревьев — отображение каталогов файлов компьютера с
помощью программы Windows Explorer.
В отличие от броузера строк броузер деревьев должен допускать модификацию на
месте, т.е. должен допускать модификацию содержимого окна без активизации окна
редактирования. Модификации в окне просмотра деревьев осуществляются с помо-
щью операции “перетащить и поместить” (“drag and drop”).
На рис. 7.9 показано окно просмотра деревьев, распложенное в левой панели
главного окна. Правая панель представляет собой окно просмотра строк. Выбор за-
писи для группы агентств приводит к отображению агентств, входящих в эту группу в
окне просмотра строк.
7.4.1.3. Web-страница
Web-страницу также можно трактовать как особый вид главного окна, если она исполь-
зуется в качестве точки входа в Web-приложение. В отличие от традиционных приложе-
ний ИС строка меню и панель инструментов Web-страницы не используются для задач
приложения. Они используются для навигации по Web — это общий вид деятельности для
всех Web-броузеров. Для Web-приложений события, инициируемые пользователями,
обычно программируются с помощью командных кнопок и активных гиперссылок.
296 Глава 7. Проектирование пользовательского интерфейса
Рис. 7.10. Окно Web-страницы
На рис. 7.10 показана Web-страница, представляющая собой точку входа для Web-
узла Макуарского университета. Строка меню и панель инструментов не применимы к
этой Web-странице. Гиперссылки используются для поиска в библиотечной базе дан-
ных, а также для того, чтобы “брать” книги или другие библиотечные материалы.
7.4.2. Вторичное окно
За исключением некоторых простейших приложений ИС вторичное окно
дополняет свое главное окно. Оно расширяет функциональные возможности главно-
го окна, в частности, в отношении операций, которые модифицируют базу данных
(т.е. за счет операций вставки, удаления или обновления).
Вторичное окно обычно является модальным по отношению к его главному окну.
Прежде, чем приступить к работе с любым другим окном приложения, пользователь
должен ответить и закрыть вторичное окно. Немодальные вторичные окна допустимы,
однако, их использование не рекомендуется.
Окно входа в систему — простой пример вторичного окна. Пример экрана входа в
систему, показанный на рис. 7.11, иллюстрирует основные видимые отличия между
главным и вторичным окном. У вторичного окна отсутствуют какие-либо “строки”:
строка меню, панель инструментов, полосы прокрутки или строка состояния. Собы-
тия инициируются пользователем посредством командных кнопок (кнопок запуска
действий), таких как кнопки OK, Cancel (Отмена), Help (Помощь).
Вторичные окна выступают в иде различных экранных форм и масок. Ниже пере-
числены основные типы вторичных окон.
Диалоговое окно.
ЧА. Оконный интерфейс 297
Папка с вкладками.
Выпадающий список
Окно сообщений.
I nrjon to Sybrtso
Командные кнопки
Рис. 7.11. Простое вторичное окно — окно входа в систему
7 А.2.Л. Диалоговое окно
Диалоговое окно (dialog box) является почти синонимом понятия вторичного окна,
заключает в себе наиболее часто требуемые свойства вторичных окон. Оно поддер-
живает диалог между пользователем и приложением. Диалог предполагает ввод поль-
зователем некоторой информации, которая обрабатывается приложением.
На рис. 7.12 приведен пример диалогового окна. Это окно обновления. Оно отобра-
жает рекламную продукцию, соответствующую текущему товару, выбранному в подокне
просмотра строк главного окна. Пользователь может модифицировать любые значения
редактируемых полей, ограниченных рамками с белым заполнением внутри.
Обратитесь к постановке задачи для приложения Управление контактами с клиентами j
(разд. 2.3.3), а также к решенным примерам в главе 4. Обратитесь также к примерам 7.1 ;
и 7.2 в этой главе. |
Главное окно приложения (рис. 7.4) не позволяет выполнять определенные манипуля- j
ции с мероприятиями. Например, ввод нового мероприятия или обновление сущест- ।
вующего мероприятия должны осуществляться через вторичное, в данном случае диа- |
лотовое, окно. ।
После двойного щелчка мышью на строке мероприятия должно появиться диалоговое *
окно, отображающее полный список деталей, относящихся к этому мероприятию. Диа- :
лотовое окно отображает не только информацию по мероприятию, но также данные о f
его сопутствующих задачах, равно как и информацию об организации и контактном ли- |
це, к которому относится мероприятие. I
Затем относящиеся к мероприятию детали могут быть отображены и, возможно, моди- j
фицированы, включая тип мероприятия (поле Action (Действие) диалогового окна Details
(Подробности), более длинное описание (поле Notes этого же окна), дату и время соз- ;
дания мероприятия, работника, создавшего мероприятие, а также работника, которому !
запланировано выполнение мероприятие и срок его выполнения (группа полей Due), и ;
работника и время фактического завершения мероприятия (группа полей Completed). I
Наша задача заключается в том, чтобы спроектировать диалоговое окно для манипули-
рования мероприятиями, удовлетворяющее приведенным выше требованиям. ;
298 Глава 7. Проектирование пользовательского интерфейса
Не редактируемое значение поля
Рис. 7.12. Диалоговое окно
На рис. 7.13 представлен вариант решения нашего примера. Обратите внимание,
что поля Organization (Организация), Contact (Контактное лицо) не являются редак-
тируемыми, поскольку “адресат” мероприятия не подлежит изменению. Аналогично
значения группы полей, следующих за приглашением Created (Создано), также нельзя
редактировать.
Значения полей, примыкающих к приглашению Completed (Завершено), не редак-
тируемы в том смысле, что пользователь не может ввести их. Однако, нажатие кнопки
Complete (Завершить) автоматически вставляет в эти поля значения даты, времени и
имени пользователя. После завершения мероприятия пользователь по-прежнему
имеет возможность вернуться к нему как к “несостоявшемуся”, поскольку в таком слу-
чае кнопка Complete превращается в кнопку Uncomplete (Не завершать).
Пользователь имеет возможность сохранить изменения в базе данных и вернуться
в главное окно, щелкнув на кнопке ОК. Вместо этого пользователь может отменить
(кнопка Cancel) внесение изменений и остаться в диалоговом окне. Наконец, пользо-
ватель может нажать кнопку New Event (Новое мероприятие), что приведет к сохра-
нению изменений (после подтверждения их пользователем), очистке всех полей и
даст пользователю возможность создать качественно новое мероприятие (не возвра-
щаясь в главное окно).
ТА. Оконный интерфейс 299
7.4.2.2. Папка со вкладками
В тех случаях, когда объем информации, которую необходимо отобразить во вто-
ричном окне, превышает “полезную площадь”, а предмет рассмотрения можно логиче-
ски разделить на несколько информационных групп, бывает полезным использование
папки со вкладками (tab folder). В каждый данный момент времени видим только один из
листов вкладок, расположенный на вершине этой “стопки” листов. (В системе Microsoft
Windows папка со вкладками, называется листом свойств, снабженным вкладками (tabbed
property sheet), а каждая из вкладок называется страницей свойств (property page)).
Рис. 7.13. Диалоговое окно (Управление контактами с клиентами)
| Обратитесь к постановке задачи для приложения Управление контактами с клиентами {
I (разд. 2.3.3), а также к решенным примерам в главе 4. Обратитесь также к примерам
j 7.1,7.2 и 7.3 в этой главе.
* Рассмотрите папку со вкладками для окна Maintain Organizations, приведенную на <
рис. 7.2 (пример 7.1). Одна из вкладок называется Contacts (Контактные лица). Она ’
предназначена для осуществления доступа и модификации данных поля Contact (класс :
Contact) с помощью этой папки со вкладками. При ее отсутствии пользователь вынуж- '
| ден был бы всегда возвращаться в главное окно и активизировать отдельное вторичное ,
; окно для ведения учетной информации по контактам.
I Цель этого примера заключается в проектировании содержимого вкладки Contacts.
800 Глава 7. Проектирование пользовательского интерфейса
На рис. 7.14 показана папка со вкладками для ввода информации о новых орга-
низациях, занимающихся рекламой. Четыре вкладки разделяют большой объем
информации, вводимой пользователем, на четыре группы. Командные кнопки в
нижней части экрана применимы ко всему окну, а не только к текущей видимой
странице вкладки.
Рис. 7.14. Папка со вкладками
Как показано на рис. 7.15, вкладка Contacts отображает только имена контактных
лиц в организации. Однако, вкладка обладает собственным набором командных кно-
пок (Add, Edit и Delete) для добавления, редактирования и удаления выделенных в те-
кущий момент Элементов из базы данных по учету информации о контактах. Действия
по добавлению (Add) или редактированию (Edit) контактной информации приводят к
открытию вторичного окна Maintain Contacts поверх окна Maintain Organizations. Ок-
но Maintain Contacts является модальным по отношению к окну Maintain Organizations.
7.4.2.3. Выпадающий список
В некоторых случаях удобной заменой странице вкладки может служить выпадаю-
щий список (drop-down list) или набор выпадающих списков. Выпадающий список обес-
печивает список выбора элементов, из которого пользователь может выделить один
подходящий элемент. Для выполнения операции вставки нового элемента в список
пользователь может ввести новое значение, которое добавляется в список и отобра-
жается при открытии списка в следующий раз.
Как видно из рис. 7.16, выпадающий список не обязательно должен быть простым
списком, он может представлять собой окно просмотра деревьев.
ЧА. Оконный интерфейс 301
Рис. 7.15. Папка с вкладками (Управление контактами
с клиентами)
Рис. 7.16. Выпадающий список
302 Глава 7. Проектирование пользовательского интерфейса
AIM2000 Duta Dictionary Maintenance t
A
Рис. 7.17. Окно сообщения
На рис. 7.17 показано сообщение, которое требует подтверждения (кнопка ОК) от
пользователя.
7.5. Зависимость между окнами
С точки зрения пользователя приложение выглядит как набор взаимодействующих
окон. Задача разработчика GUI-интерфейса состоит в том, чтобы организовать зависи-
мости между окнами в виде последовательной легко понятной структуры. Пользователь
никогда не должен чувствовать себя заблудившимся среди открытых окон.
В идеале между главным окном и верхним текущим открытым вторичным окном
должна устанавливаться простая, даже не иерархическая связь. Это достигается за
счет придания вторичному окну статуса модального по отношению к предыдущему ок-
ну. Многодокументный интерфейс (multiple document interface — MDI), рассматри-
ваемый в разд. 7.5.3, должен позволять обрабатывать любую сложную ситуацию, не
прибегая к необходимости использования немодальных окон.
В то время, как проектирование GUI-интерфейса должно способствовать исследо-
ванию интерфейса пользователем, хороший проект строки меню остается принципи-
альным методом объяснения возможностей приложения. Команды меню, доступные
пользователю при использовании выпадающих или выдвигающихся меню, служат в
качестве косвенного объяснения зависимостей между окнами.
7.5.1. Документ и его представление
Проектирование GUI-интерфейса в среде Microsoft Windows непосредственно за-
висит от классов, поставляемых компанией Microsoft, которые реализуют объекты и
элементы управления Windows — API-интерфейса Windows (application programming
interface — интерфейс прикладного программирования). Соответствующая библиоте-
ка классов называется библиотекой MFC (Microsoft Foundation Classes — базовые клас-
сы Microsoft).
Программирование для Windows связано с порождением и использованием объек-
тов MFC, а также с созданием специфичных для приложения классов, наследующих ис-
ходные функциональные возможности классов MFC. Программирование для Windows
требует также принятия на вооружение специфической структуры, определяющей за-
висимости и взаимодействие между окнами. Эта структура известна как подход к про-
граммированию на основе механизма документ/представление (document/view) [38].
Документ— это механизм MFC, позволяющий собрать данные в приложении таким
образом, что пользователь может взаимодействовать с ними. Документ может содер-
жать помимо текстовых любые другие типы данных. Объект-документ является про-
изводным объектом класса CDocument библиотеки MFC.
7.5. Зависимость между окнами 303
Обычно на экране отображается только фрагмент данных, хранимых в объекте
CDocument. Этот фрагмент называется представлением (view). Объект представления
является производным объектом класса CView. Для одного документа может сущест-
вовать множество представлений. С технической точки зрения объект CView и окно
(фрейм), в котором он отображается, — это не одно и то же.
На рис. 7.18 показано, в чем состоит видимое различие между документом и пред-
ставлением. В данном случае документ представляет собой документ, созданный с по-
мощью текстового процессора, но в общем случае он может быть любым файлом, со-
держащим информацию, которая извлечена из базы данных.
Рис. 7.18. Документ и его представление
7.5.2. Однодокументный интерфейс
В случае некоторых простых приложений проект GUI-интерфейса может состоять
из единственного главного окна, в котором одновременно отображается только один
открытый документ. Библиотека MFC поддерживает эту возможность, которая полу-
чила распространение под названием SDI-интерфейса (single document interface— однодо-
кументный интерфейс).
В проекте GUI-интерфейса для приложения “Управление контактами с
клиентами” используется SDI-приложение. В любой момент времени пользователю
представлены события, относящиеся к одному дню (рис. 7.19).
7.5.3. Многодокументный интерфейс
Для более сложных приложений безусловно может потребоваться открывать од-
новременно несколько документов. Документы могут быть однотипными, однако, за-
частую они принадлежат разным типам. Библиотека MFC поддерживает возмож-
ность, которая получила распространение под названием MDI-интерфейса (multiple
document interface— многодокументный интерфейс).
304 Глава 7. Проектирование пользовательского интерфейса
Рис. 7.19. Приложение с однодокументным интерфейсом (SDI) (с любезного разрешения
компании ACNielsen AdEx, Сидней, Австралия)
MDI-приложение все так же использует только одно главное окно. Это окно называет-
ся родительским окном (parent window). Однако, MDI-приложение позволяет открывать
несколько документов внутри фрейма родительского окна. Каждый документ называ-
ется дочерним окном (child window). Логически каждое дочернее окно ведет себя так, как
если бы оно было главным окном, которое может появиться только внутри родитель-
ского окна (но не на рабочем столе компьютера).
Тот факт, что архитектура MDI обладает только одним главным окном, по сущест-
ву, выражается в том, что все дочерние окна совместно используют одну строку меню.
Аналогично дочерние окна, как правило, совместно используют панель инструментов
и строку состояния. Однако, существует возможность внести модификации в доступ-
ные пользователю действия, содержащиеся в меню и панели инструментов, чтобы
отразить функциональные возможности текущего активного дочернего окна.
На рис. 7.20 показано MDI-приложение. Внутри фрейма главного окна открыто
четыре документа (броузера строк). Пятый документ, расположенный в левой части
главного окна, представляет собой броузер деревьев.
7.6. Навигация по окнам
Графическая картина GUI-окон, построенная с использованием прототипов или
других средств визуализации, ничего не говорит о том, каким образом пользователь
может фактически перемещаться по окнам. Нам еще требуется спроектировать систему
навигации по окнам. Диаграмма навигации по окнам призвана визуализировать окна
приложения и управляющие объекты, которые позволяют пользователю переме-
щаться от одного окна к другому.
7.6. Навигация по окнам 305
К сожалению, UML не обладает методами графического моделирования для моде-
лирования навигации по окнам. Необходимо разработать собственную модель или
воспользоваться преимуществами стереотипов UML и настроить одну из диаграмм
UML для представления навигации по окнам.
Ф Quality Control
Dictionary
......Bl Ad
-B Ad Link
-B Ad Link Merge...
. В Advertiser
-B Advertiser Grou;
......В Agency
- B Agency Groups
......В Brand...
В Category
В Category Prodm
-0Й Contact
]-B Link Restriction
В Organisation
- В Outlet
2V
2!»
20
20
20
2
2v
20
20
20
20
00
00
оо
оо
00
оо
001
ОО'
оо
H-€3RawAd
Bl Rew Ad-All
I -Bl Raw Ad TV J
I r—HB Raw Ad Radi]
120 Bar
12th Night Theatre
13 Car Dealers Keilor Rd Essnd
13 Dentist Ph Directory Svc
13 Find Phone No Svc
13 PAID’
131-SHOP Business Svcs
14 Plus Fashions Wmns Qthg St
156 Outdoor Home Fitness Ctr
1626 Ladies Clothing Rng
Hotels/Pubs/T avernl
Theatres
Motor Dealers A-E I
Dial It Services I
Directories
Electronic/Phone Bay
Directories
Fashion Retail-Worn!
Fitness Centres
Range
Puc. 7.20. Приложение с многодокументным интерфейсом (MDI)
7.6.1. Введение навигационных стереотипов в
диаграмму видов деятельности
Оказывается, диаграмма видов деятельности является неплохим потенциальным
стереотипом для оконной навигации. Диаграмма видов деятельности показывает пере-
ходы между видами деятельности (разд. 2.2.3.2). Однако, диаграмма видов деятельности,
будучи разновидностью конечного автомата, может также обрисовать состояния объек-
тов. Эту двойственность диаграмм видов деятельности можно использовать в изобрази-
тельных целях— для интерпретации аналогичной двойственности, присущей GUI-
объектам. GUI-окна похожи на состояния в ожидании событий (видов деятельности).
Состояния и виды деятельности диаграммы видов деятельности можно превратить в
стереотипы. Стереотипы состояния могут обозначать различные типы окон и другие
GUI-объекты, которые “продолжают существовать” между событиями, т.е. которые об-
ладают длительностью. На рис. 7.21 показано состояние, играющее роль стереотипа
главного окна. Состояние представляет окно просмотра (сетку) для товаров, отображае-
мое в главном окне приложения. Это также и начальное состояние модели.
3Q6 Глава 7. Проектирование пользовательского интерфейса
«Primary Window»
Product Browser
Рис. 7.21. Состояние, обозначенное как стереотип
GUI-объекта
Рис. 7.22. Вид деятельности, обозначенный как стереотип управляющего GUI-объекта
Стереотипы видов деятельности могут обозначать различные типы управляющих
элементов GUI-интерфейса, которые можно использовать для запуска событий на со-
стояниях (теперь обозначенных как объекты GUI-окон). В противоположность со-
стоянию деятельность обладает очень короткой длительностью — можно сказать, что
на нашей относительной временной шкале они обладают нулевой длительностью.
Виды деятельности (овалы) можно представить внутри состояния (прямоугольник
со скругленными краями), к которому они применяются. На рис. 7.22 показано три
вида деятельности в состоянии Product Browser. Окно Product Browser можно
использовать для инициирования события вставки, удаления или обновления товара.
Все три события можно запустить с помощью командной кнопки панели инструмен-
тов или пункта меню. Двойной щелчок мышью на строке товара в окне просмотра
также поддерживает событие обновления.
Полный список стереотипов состояний и Видов деятельности для поддержки про-
ектирования системы навигации по окнам, как правило, зависит от выбранного GUI-
интерфейса. Разработчики могут также подумать над использованием стереотипов в
виде пиктограмм. Ниже приведен неполный перечень стереотипов для GUI-
интерфейса Microsoft Windows.
Состояния (окна)
— Главное окно
Панель в главном окне
Окно просмотра строк
Окно просмотра деревьев
Web-страница
- Вторичное окно
Диалоговое окно
7.6. Навигация по окнам 307
Окно сообщений
Папка со вкладками
— Типы данных окон
Текстовое поле
Комбинированное окно
Спиновое окно
Колонка
Строка
Группа полей
Виды деятельности (элемент управления окном)
~ Пункт выпадающего меню
- Пункт всплывающего меню
- Кнопка панели инструментов
— Командная кнопка
— Двойной щелчок мышью
— Выбор из списка
- Клавиша клавиатуры
- Функциональная клавиша клавиатуры
- Комбинация клавиш клавиатуры
— Бегунок полосы прокрутки
- Кнопка закрытия окна
7.6.2. Диаграмма навигации по окнам
После определения стереотипов состояний и видов деятельности можно исполь-
зовать линии перехода для соединения видов деятельности и состояний. В результате
получится диаграмма навигации по окнам, в которой виды деятельности запускают
переходы на состояниях.
Рис. 7.23 расширяет предыдущий пример и показывает состояния, которые явля-
ются результатом запуска трех видов деятельности, присутствующих в окне Product
Browser. Состояние, запускаемое событием Update, расширено. Окно Update
Product (<<dialog Ьох>>) содержит четыре деятельности (<<command
buttons»). Нажатие на кнопке ОК или Cancel вызывает обратный переход в окно
Product Browser. Нажатие на кнопке Save или Clear не изменяет активное окно
(если нам требуется зафиксировать изменение состояния внутри активного окна, не-
обходимо расширить нашу модель за счет дополнительных стереотипов).
Модель на рис. 7.23 ограничена объектами GUI. В главе 9 будет показано, каким
образом мс>жно дальше развить стереотипы диаграммы видов деятельности, чтобы
визуализировать всю логику приложения, включая доступ к базе данных.
308 Глава 7. Проектирование пользовательского интерфейса
Обратитесь к постановке задачи для приложения Управление контактами с клиентами
(разд. 2.3.3), а также к решенным примерам а главе 4. Обратитесь к примерам 7.1,7.2 и
7.3 в этой главе.
Рассмотрите главное окно на рис. 7.6 (пример 7.2) и диалоговое окно на рис. 7.13
(пример 7.3). Разработайте диаграмму навигации по окнам в этих двух окнах. Диаграм-
ма должна обозначать и представлять модель основных событий, инициируемых поль-
зователем, для главного и диалогового окон. Следует также обратиться к использова-
нию окна Calendar— “плавающего” комбинированного окна.
Рис. 7.23. Диаграмма навигации по окнам
Диаграмма навигации по окнам для нашего примера должна рассматривать в качест-
ве состояний три окна Contact Management (<<primary window>>), Task/Event
Details («dialog box») и Calendar («combo box»). Левую и правую панели
главного окна также можно рассматривать как возможные состояния (подокна) главно-
го окна-состояния. Однако, в предлагаемом решении мы пропускаем панели.
7.6. Навигация по окнам 809
Как следует из панели инструментов, показанной на рис. 7.6, существует большое
количество видов деятельности (мероприятий), которые можно запустить на главном
окне. Однако, наша задача заключается в определении только основных инициируе-
мых пользователями событий, включая те, которые активизируют вторичные окна
Task/Event Details и Calendar.
На рис. 7.24 показана диаграмма навигации по окнам для нашего примера. Собы-
тие Calendar («toolbar button») отображает деятельность Calendar
(«combo box»). Комбинированное окно может “плавать” по экрану. Щелкнув на
квадратике закрытия окна можно избавиться от него. Выбор месяца («scroll»)
или выбор даты («select») не удаляют комбинированное окно.
Доступ к окну Task/Event Details («dialog box») получают посредст-
вом события Update Event («toolbar button/menu item/double
click»). Командные кнопки OK и Cancel удаляют диалоговое окно с экрана и
возвращают управление главному окну. Активизация кнопки Complete приводит
к заполнению полей завершения мероприятия (Complete) в окне, но управление
остается у диалогового окна. Это является следствием того, что пользователь мо-
жет пожелать создать новое мероприятие. Нажатие кнопки New Event очищает
поля экрана и позволяет пользователю ввести детальную информацию, относя-
щуюся к новому мероприятию.
Обратитесь к постановке задачи для приложения Телемаркетинг (разд. 2.3.4) и к ре-
шенным примерам для приложения Телемаркетинг в главе 4. Рассмотрите приведенные
ниже уточняющие детали и спроектируйте диаграмму навигации по окнам.
Интерфейс главного окна для приложения Телемаркетинг представляет собой пустое <
окно со строкой названия приложения и двумя командными кнопками. Кнопки позволя-
ют телемаркетеру осуществить следующий звонок (Next Call) благотворителю или
выйти из приложения (Quit). Нажатие кнопки Next Call вызывает отображение сооб-
щения с приветствием благотворителю и информационных полей окна с данными о те-
кущем звонке.
В ходе разговора с благотворителем телемаркетер взаимодействует с системой, нажи-
мая различные командные кнопки. На панели инструментов имеется ряд кнопок для за-
писи результатов звонка (таких как заказ на билеты, перепланирование звонка или не-
удача). Имеется также ряд командных кнопок для просмотра более подробной инфор-
мации, относящейся к кампании или благотворителю.
На рис. 7.25 представлена диаграмма навигации по окнам для приведенного выше
примера. Хотя Entry Window и Call Window— это одно и то же главное окно
(«primary window»), мы в явном виде представляем два состояния окна. Состоя-
ние' Entry Window становится активным после начального запуска программы, а
также в том случае, когда результат звонка неудачен (Unsuccessful). Возможна си-
туация, при которой мероприятия во вторичном окне могут возвращать управление
окну Entry Window, но это не отражено в модели. Нажатие кнопки выхода Quit в
любом состоянии приводит к закрытию приложения.
310 Глава 7. Проектирование пользовательского интерфейса
. Рис. 7.24. Диаграмма оконной навигации для приложения “Управление контактами
с клиентами”
Резюме 311
«primary window»
Entry Window
Weicome Message
«dialog box»
Order Window
«command button»
Campaign Detaiis
«command button»
Next Cail
«dialog box» «message box»
Callback
Window
«command button» \ /«command button»
Next Cail Quit
«primaiy window»
Cali Window
«toolbar»
Call Outcome
'«command button»
Quit
«command button»
Supporter History
«command button»
. Welcome Message
«tab foider»
Supporter
Window
«dialog box»
Campaign
Window
Puc. 7.25. Диаграмма оконной навигации для приложения “Телемаркетинг”
Резюме
Разработка GUI-интерфейса охватывает весь жизненный цикл производства про-
граммного продукта — она начинается на этапе анализа и продолжается до реализа-
ции. Данная глава обращена к проектированию GUI-интерфейса, в особенности для
среды Microsoft Windows. В ней также вводится графическая нотация для представле-
ния навигации по окнам.
Проектирование GUI-интерфейса представляет собой междисциплинарную деятель-
ность, требующую объединения усилий различных специалистов. Проектирование
должно вестись в соответствии с руководящими принципами, декларируемыми произ-
водителями оконного интерфейса, на использование которого ориентирован проект.
Эти принципы направлены на решение таких вопросов, как принцип локализации
управления на стороне пользователя, соответствие, индивидуализация, настройка,
терпимость к ошибкам, обратная связь, эстетичность и удобство использования.
В интерфейсе системы Microsoft Windows различают главное окно и вторичное
окно. Главное окно может быть окном просмотра строк, окном просмотра деревьев или
312 Глава 7. Проектирование пользовательского интерфейса
Web-страницей. Вторичное окно может быть диалоговым окном, папкой со вкладками,
выпадающим списком или окном сообщений. Вторичное окно может быть по отно-
шению к своему главному окну модальным или немодальным. Дальнейшее уточнение за-
висимостей между окнами осуществляется применительно к использованию SDI-
интерфейса или MDI-интерфейса.
Визуальное проектирование отдельных окон представляет собой лишь один из ас-
пектов разработки GUI-интерфейса. Второй основополагающий аспект разработки
связан со схемами перемещения по окнам, которые призваны зафиксировать возможные
пути навигации пользователя между окнами приложения. В данной главе были введе-
ны диаграммы навигации по окнам как один из подходов к решению этой проблемы.
Диаграммы навигации по окнам расширяют диаграммы видов деятельности языка
UML. В действительности, они представляют собой новый профиль UML для модели-
рования навигации по окнам.
|М| Вопросы
В1. Перечислите и дайте краткое определение руководящих принципов разработки GUi-
интерфейса.
В2. В чем отличие главного окна от вторичного окне?
вз. Что такое панель? В чем она может быть полезной при проектировании GUi-интерфейса?
В4. Что такое папка со вкладками? В чем ее отличие от диалогового окна?
В5. В чем заключается сущность подхода “документ/представление" к построению графиче-
ского интерфейса?
В8. Д опускает ли MDI-интерфейс использование нескольких главных окон? Объясните свой ответ.
В7. Каким образом окна и элементы управления окнами представляются не диаграммах нави-
гации по окнам? Соответствует ли это представление назначению диаграмм видов дея-
тельности в языке UML? Объясните свой ответ.
В| Упражнения
Рассмотрите следующие дополнительные требования для приложения Телемаркетинг.
1. Окно Telemarketing Control представляет собой главное окно интерфейса для '
приложения Телемаркетинг. Это окно выводит на экран компьютера телемаркетера
список вызовов а текущей очереди. Когда телемаркетер запрашивает вызов из оче- >
реди, система устанавливает соединение, и телемаркетер получает возможность \
обработать телефонное подключение. При этом на экране отображеется информа- :
ция о звонке (Call Summary) — выводится время начала, завершения и продолжи- ,
тельность текущего звонка. j
2. После установления соединения окно Telemarketing Control отображает инфор-
мацию о текущем звонке — кому произведен звонок, в рамках какой кампании, какой !
тип звонка осущестален. Если для текущего телефонного номера запланировано бо- t
лее одного звонка, телемаркетеру предоставляется возможность осуществить цикл
этих звонкое. >
3. На любом этапе разговора телемаркетер может просмотреть предысторию благо- *
творителя (окно Supporter History), относящуюся к предыдущим кампаниям. ,
Упражнения 313
Аналогично можно просмотреть подробности, относящиеся к кампании, в рамках ко- s
торой произведен текущий звонок (окно Campaign). i
4. GUI-интерфейс обеспечивает возможность быстрой фиксации результатов звонка. К !
возможным результатам относятся: “размещение" (т.е. билеты были заказаны), j
“обратный вызов", “неудача", “нет ответа", “занято", “автоответчик", “факс", ?
“неверный номер" и “разрыв сеязи”. х
5. Окно Campaign отображает подробности, относящиеся к кампании, билетам и при- ;
зам, разыгрываемым в рамках кампании. Подробности, относящиеся к кампании, 5
включают: идентификационный номер, назевние, даты начала, окончания и розы- ?
срыта призов. Подробности, относящиеся к билетам, включают: количество биле- >
тов, участвующих в кампании, сколько из них продано и сколько еще имеется в нали- j
чии. Подробности, относящиеся к призам, включают: описание приза, цена приза и j
место среди других призов (первое, второе или третье). ;
6. Окно Supporter History отображает предысторию звонков и предысторию уча- ;
стия благотворителя в прошлых кампаниях. История звонков включает перечень по- *
следних звонков, типы зеонков, результаты, а также идентификаторы кампаний и те- |
лемаркетеров. Предыстория кампаний содержит информацию о размещении биле- |
тов и выигрышах призов благотворителем. |
7. При выборе действия Placement (Размещение) активизируется окно placement, которое J
позволяет пользователю выделить билеты благотворителю и зафиксировать платеж. j
8. При выборе действия No Answer или Engaged для каждого текущего звонка в сис- )
теме в качестве результата записываются значения “нет ответа” и “занято” соответ- }
ственно. Затем звонки перепланируются системой на другое время следующего дня '
при условии, что каждый звонок не выходит за пределы лимита попыток, установ- |
ленного для данного типа звонка. t
9. При выборе действия Machine в системе в качестве результата записывается зна- ;
чение “автоответчик”. Продолжительность звонка устанавливается только для пер- •
вого из текущих звонков. Затем звонки перепланируются системой на другое время
следующего дня при условии, что каждый звонок не выходит за пределы лимита по-
пыток, установленного для данного типа звонка.
10. При выборе действия Fax или Wrong в системе в качестве результата записываются
значение “факс” или “неверный номер". Продолжительность звонка устанавливается
только для первого из текущих звонков. После этого для каждого благотворителя с
текущим номером телефона данные, относящиеся к благотворителю, обновляются,
в них заносится признак “испорчанный телефон”.
11. При выборе действия Disconnected в системе в качестве результата записывается
значение “разрыв связи”. После этого для каждого благотворителя с текущим номе-
ром телефона данные, относящиеся к благотворителю, обновляются, в них заносит-
ся признак “испорченный телефон*.
12. При выборе действия Callback в системе в качестве результата записывается значе-
ние “обратный аызов". Продолжительность звонка устанавливается только для первого
из текущих звонков. Чтобы получить время и дату обратного вызова и поместить их,
вызывается окно Call Scheduling. Затем звонок перепланируется системой (с при-
своением ему нового приоритета) на время и дату, полученные с помощью окна Call
Scheduling. Новому звонку присваивается тип “обратный вызов”. |
13. Если при выходе из окна Placement все оставшиеся билеты кампании уже распре- !
делены, все последующие звонки благотворителям для данной кампании не имеют |
смысле. Все подобные звонки должны быть удалены из очереди звонков. >
У1. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к
решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диа-
грамме видов деятельности для книги. Рассмотрите диаграмму классов из примера 4.7
(разд. 4.2.1.2.3).
314 Глава 7. Проектирование пользовательского интерфейса
Модифицируйте и расширьте диаграмму классов, показанную на рис. 4.4, для поддержки
дополнительных требований, которые сформулированы выше.
У2. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к
решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диа-
грамме видов деятельности для книги.
Спроектируйте и сделайте набросок главного окна для приложения “Телемаркетинг”, т.е.
окна Управление телемаркетингом. Объясните, каким образом это окно удовлетворяет
соответствующие требования к приложению.
УЗ. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к
решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диа-
грамме видов деятельности для книги.
Спроектируйте и сделайте набросок окна Supporter History для приложения
“Телемаркетинг". Объясните, каким образом это окно удовлетворяет соответствующие
требования к приложению
У4. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к
решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диа-
грамме видов деятельности для книги.
Изобразите диаграмму навигации по окнам для приложения Телемаркетинг. Если потен-
циальное решение оказывается слишком сложным, разделите диаграмму на несколько
меньших диаграмм. Старайтесь не слишком поддаваться влиянию диаграммы навигации
по окнам из примера 7.6 (разд. 7.6.2). Объясните, каким образом это окно удоелетворяет
требования к приложению.
У5. Internet-магазин — обратитесь к решениям, приведенным в наставлении по приложению
Internet-магазин, как определено в диаграмме видов деятельности для книги.
Спроектируйте и сделайте набросок Web-страницы, которая отображает состояние теку-
щего заказа для клиента. Объясните, с какими сложностями вы встретились.
Ув. Internet-магазин — обратитесь к решениям, приведенным в наставлении по приложению
Internet-магазин, как определено в диаграмме видов деятельности для книги.
Изобразите диаграмму навигации по окнам для приложения Internet-магазин. Если потенциаль-
ное решение оказывается слишком сложным, разделите диаграмму на несколько меньших диа-
грамм. Объясните, каким образом это окно удовлетворяет требования к приложению.
Проектирование баз данных
Можно сказать, что информационные системы являются многопользовательскими
системами по определению. Это свойство само по себе требует наличия базы данных,
с которой могут одновременно работать многие пользователи. Прикладные програм-
мы зависят от базы данных, однако, обратное утверждение неверно. Вывод очеви-
ден — надлежащий проект базы данных, который может объединить и поддерживать
прикладные программы, является необходимым условием реализации информацион-
ной системой предусмотренных функциональных возможностей.
В языке UML диаграмма классов определяет структуры данных, требуемые прило-
жением. Структуры данных, которые постоянно находятся в базе данных, моделиру-
ются с помощью классов-сущностей, а также как отношения между классами-
сущностями. Классы-сущности необходимо отобразить в структуры данных, распо-
знаваемые базой данных. Эти структуры данных изменяются в зависимости от базо-
вой модели базы данных, которая может быть объектно-ориентированной, объектно-
реляционной или реляционной.
В этой главе рассматривается отображение объектов в базы данных. Здесь объяс-
няется, каким образом осуществляются преобразования классов-сущностей, ассоциа-
ций, агрегаций и обобщений в структуры данных, имеющиеся в распоряжении каж-
дой из трех моделей баз данных. Рамки книги не позволяют коснуться вопроса
“интеграции схемы”, т.е. интеграции перекрывающихся структур базы данных, кото-
рые возникают в результате требований со стороны многих прикладных программ,
конкурирующих за одни и те же ресурсы базы данных.
8.1. Уровень постоянных объектов
. базы данных
На протяжении всей книги мы постоянно проводили различие между разработкой
клиентского приложения и проектированием сервера баз данных. Мы подчеркивали,
что модель классов и пакеты классов BCED (разд. 6.1.3.2) отражают классы приложе-
ния, а не структуры хранения баз данных.
Классы-сущности представляют постоянные объекты базы данных для приложения,
однако, они не являются постоянными классами для базы данных. Классы базы данных ин-
капсулируют взаимодействие между приложением и базой данных, однако они ни в коей
316 Глава 8. Проектирование баз данных
мере не являются постоянными классами. Нам по-прежнему необходимо спроектиро-
вать уровень архитектуры для постоянных объектов базы данных (persistent data base layer).
Архитектурный уровень постоянных объектов базы данных может поддерживать-
ся различными типами СУБД: реляционными (например, Sybase, DB2, Oracle8), объ-
ектно-реляционными (например, UniSQL, Oracle8) или объектными (например, ОЬ-
jectStore, Versant). Маловероятно, чтобы модель хранения для новой системы при-
надлежала к одному из устаревших типов моделей наподобие иерархической
(например, IMS), сетевой (например, IDMS), инвертированной или аналогичной мо-
дели (например, Total, Adabas). В некоторых случаях, но не в случае действительно
современных приложений ИС, уровень постоянного хранения может быть реализо-
ван с использованием простых плоских файлов.
8.1.1. Модели данных
Специалисты по базам данных выработали свое собственное представление о ми-
ре моделирования. Базы данных хранят данные. Исторически специалисты по базам
данных концентрировались на моделях данных (т.е. на языке UML — моделях состоя-
ния). Современные возможности баз данных по хранению и выполнению программ рас-
пространили эту перспективу на модели поведения (ориентированные на триггеры и
хранимые процедуры), однако моделирование данных по-прежнему остается альфой
и омегой разработки баз данных.
Модель данных (data model) (называемая также схемой базы данных (database schema} —
это абстракция, которая представляет структуры базы данных в терминах более по-
нятных, чем эти страшные биты и байты. Широко известная классификация уровней
модели данных выделяет три уровня абстракции.
1. Внешняя (концептуальная модель).
2. Логическая модель данных.
3. Физическая модель данных.
Внешняя схема (external schema} представляет обобщенную концептуальную модель
данных, необходимую для единственного приложения. Поскольку база данных обыч-
но поддерживает много приложений, конструируются несколько внешних схем. За-
тем они интегрируются в виде одной концептуальной модели данных. Наиболее из-
вестным методом концептуального моделирования данных являются ER-диаграммы
(entity-relationship — сущность связь) [51].
Логическая схема (logical schema} (иногда называемая также глобальной концептуаль-
ной схемой) представляет модель, которая отражает структуры хранения СУБД.
Именно глобальная интегрированная модель поддерживает текущие и перспектив-
ные приложения, которым требуется доступ к информации, хранимой в базе данных.
Физическая схема (physical schema} отражает специфику конкретной СУБД. Она опре-
деляет способ фактического хранения данных в энергонезависимых устройствах па-
мяти, как правило, это дисковые накопители. Физическая схема касается таких во-
просов, как использование индексов и кластеризация данных для повышения эффек-
тивности обработки данных.
Конструкторские CASE-средства (т.е. средства, направленные на проектирование и
реализацию систем) предоставляют разработчикам единый метод моделирования
данных для логической и физической схемы. Обычно такие средства трактуют по-
добную комбинированную модель как физическую модель данных.
8.1. Уровень постоянных объектов базы данных 317
На рис. 8.1 показано, каким образом в UML моделируется отношение приложения
и модели постоянно хранимых объектов базы данных. Классы пакетов-сущностей
представляют “бизнес-объекты” приложения. Диаграмма классов UML (для классов-
сущностей) может заменить ER-диаграмму в качестве альтернативного средства кон-
цептуального моделирования баз данных.
Пакеты баз данных не “направляют” процесс моделирования баз данных, они ско-
рее направляются им. Пакет баз данных изолирует модель приложения от модели ба-
зы данных, проектируется одновременно с определением уровня архитектуры посто-
янно хранимых объектов базы данных или после определения этого уровня. Пакет
баз данных разъединяет классы-сущности от схемы базы данных. Он устанавливает
отображение между объектами и базой данных.
Рис. 8.1. UML и модели постоянно хранимых объектов
8.1.2. Отображение объектов в базу данных
Отображение между приложением и базой данных, за которое отвечает пакет баз
данных, может быть очень запутанным вопросом (разд. 6.1.3). В основе трудностей ото-
бражения лежат две фундаментальные причины. Во-первых, структуры хранения базы
данных могут не иметь практически ничего общего с объектно-ориентированной пара-
дигмой. Во-вторых, база данных почти никогда не проектируется для единственного
приложения.
Первая причина равнозначна преобразованию классов пакета сущностей (разд.
5.2.4 и 6.1.3.2) в отличные от объектно-ориентированных структур, обычно — реляцион-
ные таблицы. Даже если целевая база данных является объектной базой данных, осо-
бенности базы данных потребуют аккуратного преобразования.
318 Глава 8. Проектирование баз данных
Вторая причина требует оптимального проектирования базы данных для всех при-
ложений, а не только для одного приложения, рассматриваемого в данный момент.
Приложениям следует назначить приоритеты с точки зрения их значения для бизнес-
процессов, так что структуры базы данных настраиваются на те приложения, которые
наиболее важны для организации. Не менее важно, чтобы проектировщик базы дан-
ных всегда смотрел вперед, предвидел будущие требования к данным со стороны пер-
спективных приложений и проектировал базу данных таким образом, чтобы адапти-
роваться к этим требованиям.
Уровень постоянно хранимых объектов базы данных имеет все шансы оказаться
реляционной базой данных. Технология реляционных баз данных превалирует на рынке.
Что касается баз данных больших предприятий, то их переход на объектную техноло-
гию может совершаться эволюционным путем и должен обязательно включать проме-
жуточный (если не конечный) этап освоения объектнореляционной технологии.
Мы начнем рассмотрение с представления идеального, хотя и маловероятного,
сценария, в котором в качестве постоянного хранилища используется чисто объект-
ная база данных. Затем обсудим отображение из объектной в объектно-реляционную ба-
зу данных. И наконец, мы рассмотрим модель реляционной базы данных, отличающую-
ся наиболее жесткими ограничениями и, поэтому, наиболее трудную для отображе-
ния модель.
8.2. Модель объектной базы данных
Модель объектной базы данных (ОБД) доставляет меньше всего хлопот при ото-
бражении структур данных между прикладной программой и базой данных. В дейст-
вительности, главенствующей целью объектной СУБД является прозрачная интегра-
ция базы данных с языком программирования, на котором написано приложение.
Консорциум ODMG (Object Data Management Group — Группа по управлению объ-
ектными данными) стандартизировал модель ОБД. Организации, входящие в состав
ODMG, представляют всех основных поставщиков ПО СУБД. Совсем недавно ODMG
изменила направления своей деятельности, сконцентрировав основные усилия на
отображении объектов в реляционные и другие типы баз данных. Эти усилия нашли свое
выражение в разработке стандартного API-интерфейса объектной памяти (Object Storage
API), который способен работать с любыми постоянными источниками данных. В
сущности, этот стандарт можно использовать в качестве пакета баз данных (рис. 8.1)
для отображения между приложением и базой данных. Последний стандарт (январь
2000 года) получил название объектного стандарта данных (Object Data Standard):
ODMG 3.0 [58].
Стандарт определяет, что система управления объектными базами данных (СУОБД)
не обеспечивает отдельного языка для баз данных (наподобие SQL) для манипулирова-
ния данными в пределах среды языка программирования. Вместо этого он предусматри-
вает появление объектов базы данных в языке программирования приложений в каче-
стве обычных объектов языка программирования. Другими словами, язык программи-
рования расширяется за счет объектов базы данных, которые реализуют функции
постоянного хранения объектов, управления транзакциями, навигационные запросы
(т.е. запросы, которые позволяют “перемещаться” вдоль отношений) и т.д.
Кроме того, стандарт включает отдельный язык запросов для доступа к базе дан-
ных вне среды языка программирования. Обычно такой язык называют “объектным
8.2. Модель объектной базы данных 319
SQL” (OSQL). Язык OSQL расширяет возможности запросов реляционного SQL
за счет навигационных запросов и возможности обработки более сложных типов
данных, таких как шаблоны (разд. 6.2.2.5).
8.2.1. Элементарные типы модели ОБД
Базовыми элементарными типами модели объектной базы данных выступают объект
и литерал [58], [20]. Каждый объект обладает идентификатором (OID) (разд. 2.1.1.3). У
литерала OID отсутствует — роль идентификатор литерала играет его значение.
В ОБД проводится различие между классом (реализацией) и типом (спецификацией).
Тип может обладать несколькими классами. Например, тип Employee (Сотрудник)
может быть реализован в виде Smalltalk-класса и/или Java-класса. Семантика типа по-
зволяет отделить спецификацию от ее различных реализаций. Спецификация абст-
рактного поведения типа называется интерфейсом. Непосредственно материализо-
вать интерфейс нельзя.
Класс ОБД обладает свойствами и операциями. Свойство может быть атрибутом или
отношением (т.е. атрибутом, который связывает объект с одним или несколькими дру-
гими объектами).
8.2.1.1. Типы литералов и объектов
Одним из главных преимуществ ОБД является встроенная поддержка типов лите-
ралов и объектов. Это делае'г ОБД естественной платформой реализации для объект-
но-ориентированной разработки ИС. Если переход разработчиков ИС к использова-
нию ОБД и не приобрел массового характера, то только из-за того, что ОБД присущи
некоторые другие недостатки (наподобие слабой многопользовательской поддерж-
ки), а также благодаря коммерческому и политическому влиянию, оказываемому бо-
лее мощными производителями СУБД.
Стандарт ODMG 3.0 предусматривает следующие типы литералов [58]:
атомический (простой);
структурный;
коллекция (шаблон);
пустой (null).
Атомические литералы принадлежат к одному из следующих подтипов:
числовой
— short (короткое целое со знаком);
— long (длинное целое со знаком);
. — unsigned short (короткое без знака);
— unsigned long (длинное без знака)';
— float ((десятичное) число с плавающей точкой одинарной точности);
— double (число с Плавающей точкой двойной точности);
буквенно-цифровые и специальные символы
— char (одиночный символ);
— string (строка символов);
— boolean (т.е. логические значения “истина” или “ложь”);
320 Глава 8. Проектирование баз данных
- octet (двоичная строка для представления “сырых” данных);
— enum (перечислимый список допустимых значений).
Структурированный литерал представляет собой предопределенную структуру дан-
ных, состоящую более чем из одного атомического литерала. Структурированный ли-
терал может принадлежать одному из следующих типов:
дата (например, 9 июля 2001);
время (например, 11:14);
временная метка (например, 9 июля 2001 11:14:56);
интервал (например, 11:14, 11:19).
Литерал-коллекция представляет собой шаблон на литералах, т.е. параметризован-
ный тип (разд. 6.2.2.5), при этом значения формальных параметров являются лите-
ральными значениями. Существуют следующие типы литералов-коллекций:
set<t> (тип set (множество), при этом все элементы принадлежат одному
литеральному типу t; например, set<dept_name>, где dept_name принадлежит
типу string);
bag<t> (мультимножество (множество, допускающее дублирование элементов));
list<t> (упорядоченное (отсортированное) множество);
array<t> (упорядоченная совокупность элементов, количество которых
устанавливается динамически, а каждый элемент можно отыскать по его позиции в
совокупности);
dictionary<t,v> (неупорядоченная последовательность (индекс) пар значений
ключей, не содержащая повторяющихся ключей).
Пустой литерал (null) можно задать для любого другого литерального типа
(например, string или listo). Пустой литерал означает пустое значение. Применительно
к реляционным базам данных значение null представляет одну из следующих возможно-
стей: “неопределенное в данный момент значение” (например, “Я не знаю даты твоего
рождения”) или “неприменимое значение” (например, “Если ты мужчина, у тебя не мо-
жет быть девичьей фамилии”). Пустое значение — это не нулевое значение и не символ
пробела, это специальный поток битов, который обозначает пустое значение. (В поле
базы данных такое значение выглядит именно как null. Прим. ред.).
Стандарт ODMG 3.0 предусматривает следующие типы объектов [58]:
атомический объект;
структурный объект;
коллекция (набор возможных значений, аналогичный коллекции литералов,
однако, параметры принимают значения объектов; например, set<Dept>, где
Dept — это класс).
На рис. 8.2 приведен пример объявления типов. Класс Employee обладает пятью i
свойствами. Одно из этих свойств (emp_name) — структурированный объект. Значе- :
нием свойства emp_name является OID экземпляр класса PersonName. Класс
PersonName не показан, но, судя по всему, состоит из таких атрибутов, как
family_name (фамилия), first_name (имя) Hmiddle_initial (инициал).
8.2. Модель объектной базы данных 821
«ODB»
_______Employee______
empjd: string
emp_name: PersonName
date_of_blrth: date
gender: enum{M,F}
phone_num: array<string>
salary: float
Puc. 8.2. Объявление типов
в объектной базе данных
8.2.1.2. Отношения и инверсии
Модель ОБД строится на модельных элементах, рассмотренных в предыдущем
разделе. Что касается трех типов отношений (т.е. ассоциации, агрегации и обобще-
ния), модель ОБД непосредственно поддерживает ассоциацию и обобщение. Агрега-
ция поддерживается только с помощью ограничения ассоциации.
Ассоциация реализуется с использованием типов объектов-коллекций, в частно-
сти, множества (Seto) и списка (Listo). На практике ассоциации отвечают за пе-
реход от реляционно-ориентированного доступа к базе данных, характеризуемого
значением, назад к навигационному доступу к базе данных. (Здесь употребляется вы-
ражение “переход... назад”, поскольку старомодные сетевые базы данных использова-
ли навигацию в качестве присущего им modus operandi.)
На рис. 8.3 показано, каким образом ассоциация типа “многие ко многим” между
классами Student и Courseoffering представляется в модели ОБД. Графическая
модель проводит различие между атрибутами и отношениями. Между классами не
изображается никаких линий, поскольку свойства отношений (crs_of f и std) уже
реализуют эту ассоциацию.
Ключевое слово inverse, показанное в определении схемы, накладывает на ассоциа-
цию требование ссылочной целостности (referential integrity) и исключает возможность появ-
ления зависших указателей (danglingpointers) (т.е. указателей, указывающих на несуществую-
щие (удаленные) объекты. Прим, ред.) Например, чтобы добавить объект Student к объек-
ту Courseoffering, программист может либо добавить объект Courseoffering (если
быть точным— OID объекта) к множеству курсов Set<CourseOffering>, или добавить
объект Student к списку студентов List<Student>. После того, как программист изме-
няет один конец ассоциации, противоположный конец (инверсный) автоматически изме-
няется СУОБД.
Хотя это и не показано в приведенных выше определениях классов, модель ОБД
позволяет задавать ключи (key) — уникальные идентифицирующие значения для объек-
тов классов. В отличие от реляционных баз данных ключ не является единственным
или даже главным средством идентификации объектов (этой цели служат значения
OID). Однако, иногда для поиска данных в ОБД в качестве дополнительной возмож-
ности можно воспользоваться значением ключа.
Ключ может быть простым (simple) или составным (compound) (в последнем случае он
состоит более, чем из одного атрибута). Поскольку у класса может быть несколько
ключей, для того, чтобы отличать эти ключи друг от друга, можно использовать по-
следовательные номера (или другой визуальный метод).
322 Глава 8. Проектирование баз данных
«ODB»
_______________Student_______________
«attribute» name: string
«attribute» studJd: string
«relationship» crs off: Set<CourseOffering>
class Student
«ООВ»
_________Courseoffering______
«attribute» crs_name: string
«attribute» semester: string
«relationship» std: List<Student>
I
attribute string name;
attribute string stud_id;
relationship Set<CourseOffering> crs-off inverse Courseoffering: :std;
};
class Courseoffering
i
attribute string crs_name;
attribute . string stud_id;
relationship List<Student> std
inverse Student: :crs_off;
};
Puc. 8.3. Представление ассоциации в модели объектной базы данных
8.2.1.3. Наследование типа ISA и EXTENDS
Объектная модель ODMG определяет два типа отношений обобщения. Это отно-
шения типа ISA и EXTENDS. Отношение типа ISA соответствует (попросту говоря)
данному нами ранее определению наследования интерфейса (разд. 5.3.3). Отношение
типа EXTENDS соответствует наследованию реализации (разд. 5.3.4). (ISA означает не
что иное, как is а— “является одним из представителей”, a EXTENDS означает
“расширяет". Из приведенного примера ясно, что “класс сотрудников” является пред-
ставителем “класса личностей”, причем не единственным, и в то же время класс
“менеджеров” расширяет класс “сотрудников”. Прим. ред.}.
На рис. 8.4 показана расширенная диаграмма UML, содержащая отношения ISA и
EXTENDS. Класс “сотрудников” Employeeclass наследует определение интерфейса
от класса “личностей” Personinterface. Класс Personinterface — абстрактный
класс. Класс “менеджеров” ManagerClass наследует реализацию, включая объявле-
'ние метода аде (возраст) от класса EmployeeClass.
Стандарт ODMG использует ключевое слово interface при определении абстрактно-
го класса, наподобие Personinterface. Ключевое слово class используется только
для определения конкретного класса, который может быть материализован, например,
такого как Managerclass и EmployeeClass.
8.2. Модель объектной базы данных 828
Рис. 8.4. Наследование в модели объектной базы данных
8.2.1.4. Встроенные операции
Поставляемые объектные СУБД оснащены встроенными операциями, поддержи-
вающими типы литералов и объектов. К наиболее интересным операциям относятся
те, которые поддерживают структурированные типы и коллекции. Чтобы воспользо-
ваться преимуществами интерфейсов СУОБД при разработке проектных моделей,
системный проектировщик должен быть знаком с этими интерфейсами.
Ниже приводится перечень некоторых сигнатур поддерживаемых сегодня (или в
перспективе) интерфейсов для структурированных типов и коллекций [58]. Назначе-
ние операций довольно очевидно из их сигнатур.
Date
— ushort day_of_year()
— Month month_of_year()
- Weekday day_of_week()
- boolean is_leap_year()
— boolean is_greater(in Date a^date)
- boolean is_between(in Date a_date, in Date b_date)
- Date add_days(in long days)
- - long subtract_date(in Date a_date)
Time
- ushort millisecond ()
— boolean is_equal(in Time a_time)
- boolean is_between(in Time a_time, in Time b_time)
- Time subtract_interval(in Interval an_interval)
324 Глава 8. Проектирование баз данных
- Interval subtract_time(in Time a_time)
Timestamp
— ushort millisecond()
- ushort month()
— boolean is_between(in Timestamp a_stamp, in Timestamp b_stamp)
— Timestamp plus(in Interval an_interval)
- Timestamp minus(in Interval an_Interval)
Interval
- ushort second()
- Interval plus(in Interval an_interval)
- boolean is_less_or_equal(in Interval an_interval)
- boolean is_zero()
Объекты-Коллекции совместно используют несколько операций. Поэтому СУОБД
обычно определяют суперкласс с именем Collection. Специфические классы кол-
лекций наследуют общее поведение от суперкласса Collection (как всегда, унасле-
дованная операция может быть при необходимости уточнена или замещена). К об-
щим операциям относятся следующие.
unsigned long cardinality()
boolean is_ordered()
boolean contains_element(in any element)
void insert_element(in any element)
void remove_element(in any element) raises(ElementNotFound)
Set
— Set create_union(in Set other_set)
- boolean is_subset_of(in Set other_set)
— boolean is_proper_superset(in Set other_set)
Bag
- unsigned long occurrences_of(in any_element)
— Bag create_intersection(in Bag other_bag)
List
- any retrieve_element_at(in unsigned long index) raises(Invalidlndex)
- void insert_element_after(in any element, in unsigned long index)
raises(Invalidlndex)
- void insert_element_first(in any element)
— void remove_last_element() raises(ElementNotFound)
— List concat(in List otherjist)
— void append(in List otherjist)
8,2. Модель объектной базы данных 825
Array
. — void remove_element_at(in unsigned long index) raises(Invalidlndex)
- any retrieve_element_at(in unsigned long index) raises(Invalidlndex)
- void resize(in unsigned long new_size)
Dictionary
— any lookup(in any key) raises(KeyNotFound)
- boolean contains_key(in any key)
8.2.2. Отображение в ОБД
Отображение UML-моделей в ОБД осуществляется относительно беспрепятст-
венно. Основная задача ОБД состоит в том, чтобы предоставить объектно-
ориентированную реализацию для объектно-ориентированной модели. Фактически,
мы моделируем проект ОБД с помощью обозначенных как стереотипы диаграммы
классов для выражения свойств и ограничений ОБД.
Процесс отображения необходимо выполнить для тех фрагментов моделей состояний
и поведения, которые относятся к постоянным объектам. По существу отображение огра-
ничено аспектами состояния и поведения классов, входящих в пакет сущностей.
В этой задаче превалирует аспект отображения состояний. Отображение поведе-
ния обычно осуществляется как часть архитектурного проектирования (разд. 6.1),
проектирования кооперации (разд. 6.2) и проектирования программ клиент/сервер
(Chapter 9). В частности, именно в рамках архитектурного проекта должно быть при-
нято начальное решение в отношении того, где должны выполняться различные
процессы — на клиенте или на сервере. Это решение влияет на детализированный
проект кооперации и проектирование программ клиент/сервер.
8.2.2.1. Отображение классов-сущностей
Внимательный читатель наверняка обратил внимание на неудобное для работы с
UML-моделями предположение, касающееся того, что атрибуты классов определены
на элементарных типах данных и на некоторых встроенных структурированных типах
данных (Date, Currency). Ассоциативные роли предполагают, что при проектирова-
нии будут использоваться коллекции (шаблоны), однако, решение по поводу коллекций
обычно откладывается до тех пор, пока не прояснится вопрос их поддержки со сто-
роны выбранной базы данных и среды программирования.
Но что можно ответить на простые вопросы вроде: “Что если у сотрудника не-
сколько телефонных номеров? Каким образом моделировать эту ситуацию в ходе ана-
лиза? Действительно ли необходимо держать отдельный класс для телефонных номе-
ров?” Вероятно, можно задать и другие трудные вопросы, например, такие: “Можно
моделировать имя сотрудника в виде одного атрибута, обладающего внутренней
структурой, отображающей тот факт, что имя состоит из фамилии, собственно имени
и инициала посередине? Действительно ли необходимо держать отдельный класс для
имен сотрудников?”
Теоретически UML не препятствует расширению системы типов за счет опреде-
ления новых классов (в ходе анализа) и использования шаблонов (в ходе проектиро-
вания). Практически, чтобы избежать разрастания количества маловажных классов,
не следует делать этого до тех пор, пока не прояснится вопрос о поддержке, которую
326 Глава 8. Проектирование баз данных
можно получить со стороны платформы реализации для расширяемой системы ти-
пов, а равно и для встроенных структурированных типов и коллекций. В результате,
вопросы, наподобие приведенных выше, зачастую попросту игнорируются вплоть до
этапа проектирования.
Попробуем прояснить эти и аналогичные вопросы, взяв некоторые из наших мо-
делей анализа и отобразив их в схеме классов ОБД. В этом разделе рассматриваются
классы, отличные от классов-сущностей. В последующих разделах мы также рассмот-
рим отношения между классами-сущностями.
Обратитесь к спецификациям классов для приложения Управление контактами с кли- 1
ентами в примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Рассмотрите классы Contact и ;
Employee. Заметим, что приведенные выше вопросы сформулированы применитель- f
но к этим двум классам. |
Класс Contact обладает атрибутами family_name и first_name, однако, в нем от- I
сутствует понятие “контактного имени” (т.е. имен контактного лица). Аналогично <
Employee содержит атрибуты f amily_name, first_name и middle_name, но у нас нет I
возможности запросить в базе данных “имя работника”, поскольку подобного понятия j
просто не существует.
. I
Класс Contact обладает также атрибутами phone, fax и email. Модель в ее настоя- ;
щем виде не позволяет контактному лицу иметь более одного номера телефона, фак- (
са или адреса электронной почты — на практике подобное предположение довольно |
нереально. •
Наша задача в данном примере заключается в отображении классов-сущностей
Contact и Employee в проект ОБД. Это отображение должно быть обращено на указан- »
ные проблемы. j
Один из вариантов искомого отображения показан на рис. 8.5. Мы ввели два ОБД-
интерфейса— PersonShortName (Сокращенное имя лица) и PersonLongName
(Полное имя лица). Первый интерфейс определяет тип данных для “контактного
имени” contact_name. Мы задаем тип для contact_name явно внутри класса
Contact и дополнительно через отношение ISA. Строго говоря, отношение ISA яв-
ляется здесь избыточным. Классу Contact не требуется наследовать два отдельных
атрибута класса PersonShortName. Он использует PersonShortName только в каче-
стве типа своего собственного атрибута contact_name.
Класс PersonLongName наследует два атрибута класса через отно1пение ISA и вместе
со. своим собственным атрибутом образует тип д ля атрибута employee name. Как и в
предыдущем случае, отношение'ИЗА между классами Employee и PersonLongName дает
только визуальную связь, в остальном же оно является избыточным.
Возможность контактного лица (Contact) обладать несколькими телефонами и
факсами, а также адресами электронной почты реализуется с помощью типа set —
одного из типов коллекций, поддерживаемых ОБД-системами.
8.2. Модель объектной базы данных 827
Рис. 8.5. Отображение классов-сущностей на проект ОБД
(Управление контактами с клиентами)
8.2.2.2. Отображение ассоциаций
В UML-моделях ассоциации между классами позволяют осуществлять навигацию
по объектам этих классов. Это именно то, что составляет сильную сторону объектной
базы данных — навигация по объектам, связанным с помощью идентификаторов по-
стоянных объектов.
Поэтому отображение ассоциаций в ОБД — не вызывающая особых затруднений
деятельность, что, собственно, и было продемонстрировано на примере ассоциации
между классами Student и Courseoffering в разд. 8.2.1.2 (рис. 8.3). Свойство отно-
шения для класса ОБД обозначается именем класса (или коллекции классов), с кото-
рым он связан ассоциативной связью.
В свете сказанного может потребоваться в ходе спецификации отображения оп-
тимизировать проект. В частности, можно принять решение о том, что некоторые
атрибуты UML (или классы UML) следует моделировать как интерфейсы ОБД, пре-
следуя при этом цель использования данных интерфейсов как типов для свойств клас-
сов ОБД (как показано на рис. 8.5).
Обратитесь к спецификациям ассоциаций для приложения Управление контактами с j
клиентами в примере 4.8, рис. 4.5 (разд. 4.2.2.3). Обратитесь также к предыдущему ?
примеру отображения классов-сущностей (рис. 8.5). j
Наша задача заключается в отображении модели, представленной на рис. 4.5, в проект ;<
ОБД. В процессе отображения может потребоваться выяснить, какие UML-атрибуты или I
классы наилучшим образом подходят на роль интерфейсов ОБД. Затем можно исполь- ;
зовать (повторно использовать) эти интерфейсы для релевантных классов ОБД. j
Одно из возможных решений для нашего примера показано на рис. 8.6. Помимо вве-
денных в предыдущем примере ОВД-интерфейсов (PersonShortName и PersonLongName)
мы создали иерархию наследования (inheritance hierarchy) для ОБД-интерфейса Address. Затем
ввели атрибуты объектов postal_address и courier_address внутрь ОБД-классов
328 Глава 8. Проектирование баз данных
Organization и Contact в качестве вложенных атрибутов (nested attribute). Ассоциативные
связи на рисунке не показаны, поскольку отношения представлены как свойства классов.
«ODB Class»
_________Organization________
organizationJd: unsigned short
phone: set<string>
fax: set<string>
email: string
is_current: boolean
postal_address: PostalAddress
courier_address: CourierAddress
contact: Set<Contact>
task: Set<Task>
«ODB Ciass»
______________Contact_____________
«key» contact Jd: unsigned short
contact_name: PersonShortName
phone: set<string>
fax: set<string>
email: set<string>
postal_address: PostalAddress
courier_address: CourierAddress
organization: Organization
task: Set<Task>
«ODB Ciass»
_______ Event_________
description: string
task: Task
created_dt: date
createdjemp: Employee
due_dt .-date
due_emp: Employee
completed_dt: date
priority: char
«ODB Class»
' , . Task ,
description: string
created_dt: date
value: float ,s<
created_emp: Employee
event: List<Event>
organization: Organization
contact: Set<Contact>
«ODB Class»
___________Employee___________
«key» employeeJd: string
employeejiame: PersonLongName
createdJask: List<Task>
created_event: Set<Event>
due_event: List<Event>
completed e/ent: Set<Event>
Puc. 8.6. Отображение ассоциаций на проект ОБД (Управление контактами с клиентами)
8.2. Модель объектной базы данных 329
8.2.2.3. Отображение агрегаций
Как было объяснено ранее (разд. 2.1.4, 4.2.3 и 5.4), UML распознает только две се-
мантики в отношении агрегации — собственно агрегацию с семантикой “по ссылке" и
композицию с семантикой “по значению”. Ввиду этих ограничений нотация UML для
агрегации конечно не поддерживается напрямую реализацией ОБД (и в этом отно-
шении — любой другой базой данных).
В базе данных отношения агрегации можно моделировать как ассоциации или
вложенные атрибуты. Если вводить специальную семантику агрегации, то этого
можно добиться скорее с помощью процедурных средств (т.е. ввести семантику
прямо в программу), чем декларативных (за счет введения семантики структуры
данных).
Принцип отображения агрегаций прост. Агрегация UML отображается в модель
ОБД так, как будто это ассоциация. Композиция UML превращается в составной
класс ОБД, который содержит вложенные атрибуты, представляющие компо-
нентный класс. Поскольку компонентный класс обладает внутренней структурой
(т.е. не является атомическим), О БД-интерфейс должен сначала определяться как
структурированный тип объекта. Затем вложенные атрибуты принимают значе-
ния объектного типа. В целях достижения определенного уровня эффективно-
сти, повторного использования, масштабируемости и приспособленности к со-
провождению и т.д. возможно применение некоторых вариантов описанной вы-
ше стратегии отображения.
Обратитесь к спецификациям агрегаций для приложения Запись на университетские ;
курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
I Наша задача заключается в отображении модели, представленной на рис. 4.6, в проект <
I ОБД. Чтобы ввести вложенные атрибуты и упростить модель, может потребоваться оп-
I ределить и использовать некоторые ОБД-интерфейсы как типы атрибутов классов.
На рис. 8.7 показана предлагаемая модель. Мы определили два интерфейса:
YearSemester и AcademicRecord. Первый носит лишь “косметический” характер —
модель может обойтись без него. Второй необходим для определения UML-
композиции как вложенного атрибута academic record класса Student.
UML-агрегация между классами Course и Courseoffering моделируется как
обычная ассоциация. Семантику агрегации может потребоваться ввести процедурно.
Свойства отношения определяют отношение агрегации и ассоциации, представлен-
ное на рис. 4.6.
8.2.2*4. Отображение обобщений
Отображение отношения обобщения UML на отношения ISA и EXTENDS ОБД яв-
ляется по существу, отношением “один к одному”. Отношение ISA является результа-
том наследования от ОБД-интерфейса. Наследование от класса ОБД моделируется с
помощью отношения EXTENDS.
Преобразование модели обобщения UML в модель ОБД показано на рис. 8.8. По-
скольку иерархия обобщения на рис. 4.7 представляла наследование интерфейса, мы
использовали отношение ISA OMG.
380 Глава 8. Проектирование баз данных
Класс UML Rentalconditions преобразуется в ОБД-интерфейс. Этот ОБД-
интерфейс используется как структурированный объектный тип для атрибута
rental_cond, встроенного в ОБД-интерфейс VideoMedium. Мы принимаем, что
класс Rentalconditions является свойством VideoMedium и, следовательно, дол-
жен быть встроен в конкретный класс, наследуемый из интерфейса VideoMedium
(т.е. BetaTape, VHSTape и DVDDisk).
Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в
примере 4.10, рис. 4.7 (разд. 4.2.4.3).
Наша задача заключается в отображении модели, представленной на рис. 4.7, в проект '
ОБД. Хотя подклассы UML-модели не содержат саоих собственных атрибутов (пока что),
мы предполагаем, что они отличаются по состоянию и поведению и в свое время к этим :
классам будут добавлены свойства.
«ODB interfase»
_____YearSemester
year: date
semester: unsigned short
<<ODB Class»
•___________Course______________
course_code: string
course_name: string
creditjpoints: unsigned short
course offering: list<CourseOffering>
«ODB Ciass»
AcademicRecord
course_code: string
year_sem: YearSemester
grade: string
«ODB Class»
___________Courseoffering__________
year_sem: YearSemester
enrolment_quota: unsigned short
course: Course
student: list<Student>
academic in charge: AcademicinCharge
f «ODB Class»
. s ___________Student _______________
studentJd: string <
student_name: string
currentjees: float
course_off: list<CourseOffering>
academic ^record: s6t<AcademicRecord>
. . . . . • .• - . ..
«ODB Class»
_______AcademicinCharge_______
course off: list<CourseOffering>
Puc. 8.7. Отображение агрегаций на проект ОБД (Запись на университетские курсы)
8.3. Объектно-реляционная модель базы данных 331
Рис. 8.8. Отображение обобщений на проект ОБД (Магазин видеопроката)
8.3. Объектно-реляционная модель
базы данных
Следующей “большой волной” в области технологий баз данных является объект-
но-реляционная модель [87]. Как ясно из названия, объектно-реляционная база дан-
ных (ОРБД) сочетает в себе старомодную реляционную модель и новомодную объ-
ектную модель. Одна и та же объектно-реляционная система управления базами дан-
ных (СУОРБД) способна обрабатывать реляционные структуры данных (реляционные
таблицы) и объектные структуры данных (объектные таблицы).
Стандарт для модели ОРБД был согласован в 1999 году, после более чем шестилетней
разработки (этот стандарт известен под неофициальным именем SQL3). Данный стандарт
является результатом труда Американского национального института стандартов
(American National Standards Institute — ANSI) и Международной организации по стандар-
тизации (International Organization for Standardization — ISO). Официальное название это-
го стандарта SQL:1999 [21]. Стандарт оставил многие вопросы, касающиеся ОРБД, нере-
шенными и должен по положению пересматриваться примерно раз в три года.
332 Глава 8. Проектирование баз данных
Модель ОРБД совместима “снизу вверх” с последним стандартом для реляционных
баз данных — так называемым стандартом SQL92. Модель расширяет традиционные
возможности реляционных таблиц за счет нового механизма, позволяющего хранить
объекты в SQL таблицах. Модель также расширяет ограниченную реляционную под-
держку для определяемых пользователем типов за счет введения произвольных слож-
ных структурированных типов (чтобы инкапсулировать атрибуты и операции в одном
объектном типе — классе).
Хотя стандарт развивался (и продолжает развиваться), большинство поставщиков ре-
ляционных баз данных (Oracle, IBM, Informix) взялись за задачу поставки продуктов для
СУОРБД, обеспечивающих по меньшей мере частичную поддержку модели ОРБД. Одной
из основных проблем для поставщиков остается интеграция ранее существовавших реля-
ционных возможностей с новыми объектноориентированными, чтобы сделать возмож-
ным беспрепятственный перенос реляционных систем в решения, основанные на исполь-
зовании ОРБД. Стандарт SQL: 1999 фактически не касается этой проблемы.
В последующем изложении мы стремимся придерживаться спецификаций
SQL: 1999 [21], однако, время от времени обращаемся к рассмотрению реальных про
дуктов СУОРБД (в частности, для Oracle 8), чтобы подчеркнуть различия между тео
рией и практикой.
8.3.1. Элементарные типы модели ОРБД
Элементарные типы модели ОРБД включают новые объектные элементарные ти-
пы и прежние реляционные элементарные типы. Принципиально новым объектным
элементарным типом является определяемый пользователем структурированный тип,
соответствующий нотации ОБД для интерфейса и нотации UML для класса.
Структурированный тип определяется заданием его атрибутов и операций. Его
можно также определить как подтип другого структурированного типа. На самом деле
модель ОРБД поддерживает множественное наследование интерфейса (разд. 5.3.3).
В качестве механизма хранения данных используется таблица. Столбцы таблицы мо-
гут принимать значения структурированных типов, определяемых пользователем. В не-
которых реализациях СУОРБД (например, в Огас1е8) подобные таблицы называются
объектными таблицами, чтобы отличить их от традиционных реляционных таблиц.
В ОРБД также поддерживаются структурированные типы и типы коллекций, вве-
денных для ОБД. Специальный вид структурированного типа— называемого строч-
ным типом (row 'type) — позволяет задать вложенные структуры данных в рамках объ-
ектных таблиц. Строчный тип можно также использовать для определения ссылочно-
го типа (reference type). Ссылки обеспечивают возможности навигации по объектам.
8.3.1.1. Особые и структурированные типы
Поля столбцов в таблице ОРБД могут принимать значения встроенных типов или
типов, определяемых пользователями. Что касается встроенных типов, то возможности
ОРБД аналогичны возможностям, которые обычно реализуются ОБД (разд. 8.2.1.1).
То же самое можно сказать в отношении встроенных операций.
Типы данных, определяемые пользователями, можно разделить на две категории:
особый тип (distinct type) — выражается в виде единственного предопределенного
типа, называемого исходным типом (source type) (особый тип соответствует
атомическому объектному типу стандарта ODMG);
8.3. Объектно-реляционная модель базы данных 333
структурированный тип (structured type) — выражается в виде списка определений
атрибутов и операций (структурированный тип соответствует структурированному
объектному типу стандарта ODMG).
Структурированный тип позволяет пользователям вводить свои собственные име-
нованные типы. Определение структурированного типа состоит из объявления сле-
дующих компонент.
Атрибуты, представляющие состояние объектов структурированного типа.
Операции, определяющие поведение объектов структурированного типа.
Операции, определяющие эквивалентность/неэквивалентность, упорядоченность и
преобразование объектов структурированного типа (необходимы, если нам
требуется сравнивать два объекта структурированного типа на эквивалентность,
некоторым образом сортировать их или преобразовывать из одного
структурированного типа в другой).
Структурированный тип атрибута может определяться с помощью исходного типа,
особого типа, типа коллекции или другого структурированного типа. Стандарт SQL: 1999
определяет следующие типы коллекций (продукты ОРБД могут определять больше
типов коллекций):
множество (set);
список (list);
мультимножество (multiset) (тип, аналогичный типу tag ОБД);
массив (array).
На рис. 8.9 показано определение структурированного типа для класса Employee,
соответствующее определению для ОБД, приведенному на рис. 8.2. При сравнении
определений видно, что их различия незначительны и связаны со встроенными ис-
ходными типами (если речь не идет о конкретной СУОРБД, их выбор довольно про-
изволен). Атрибут gender (род) введен как char, поскольку типичная СУОРБД, как
правило, не поддерживает тип enum. Аналогичного результата для ОРБД можно дос-
тичь, задав проверку ограничения (check constraint) на типе gender (разд. 8.4).
«structured type»
_______EmplayeeTY_______
empJd: char(7)
emp_name; PersonName
date_of_birth: date
gender:char
phonenuni: set(varchar(12))
salary: money
Puc. 8.9. Объявление типов в объект-
нереляционной модели базы данных
8.З.1.2. Объектные таблицы
Таблица (объектная таблица) представляет собой множество строк и столбцов.
При этом строка может состоять из стольких полей, сколько столбцов содержит таб-
334 Глава 8. Проектирование баз данных
лица объектов. Строка таблицы (table row) — это объект (экземпляр) строчного типа (см.
разд. 8,3,1.3 ниже). Каждая строка в таблице объектов — объект, уникальным иденти-
фикатором которого служит OID. Соответственно, строка таблицы — это наименьшая
единица данных, которую можно поместить в таблицу или удалить из нее.
Для того, чтобы быстро отличить объектный тип от объектной таблицы, на практике
в имени структурированного типа рекомендуется использовать суффикс TY. Для по-
стоянного хранения экземпляров типа EmployeeTY в ОРБД необходимо создать таб-
лицу EmployeeTY. Удобно назвать подобную таблицу по имени типа, но без суффикса
TY. В соответствии со стандартом SQL:1999 объявление могло бы выглядеть следую-
щим образом
create' table Employee of EmployeeTY;
В стандарте SQL: 1999 не определена инкапсуляция атрибутов структурированного
типа с помощью операций (например, разд. 2.1?2.1.2 и 5.1.4) [21]. Однако, стандарт
SQL: 1999 предполагает, что ОРБД должна генерировать для каждого атрибута опера-
ции наблюдателя (observer (get)) и мутатора (mutator (set)). Они, соответственно, по-
зволяют зачитывать и модифицировать каждый атрибут.
8.3.1.3. Строчные типы
Строчный тип (row type) позволяет строить относительно сложные внутренние
структуры даже без необходимости использования структурированных типов или
коллекций. Строчный тип представляет собой последовательность полей (пар <имя
поляХтип данных>). На самом деле строчный тип дает возможность поместить одну
таблицу внутри другой. Столбец таблицы может содержать строчные значения.
Следующий пример объясняет; каким образом использовать строчные типы для
определения таблицы со сложной внутренней структурой. Источником для этого
примера послужили некоторые классы приложения Управление контактами с клиента-
ми (см. рис. 8.6).
create table Contact
(contact_id integer,
contact_name row
(family_name varchar(30),
first_name varchar(20)),
postal_address row
(po_box varchar(10),
post_code varchar(10),
address row ’
(street varchar(30),
cityvarchar(20),
state varchar(20),
country varchar(25)))j; 1
С точки зрения программирования баз данных строчные типы дают возможность
хранить полные строки таблицы в переменных, передавая их в качестве входных ар-
гументов операций и возвращая их как выходные аргументы операций или возвра-
щаемых значений.
8.3. Объектнофеляционная модель базы данных 335
8.3.1.4. Ссылочные типы
Структурный тип можно использовать для определения ссылочного типа (reference
type). Для определения ссылки используется ключевое слово ref. Например, етр
ref (EmployeeTY) представляет собой ссылку в объектной таблице на структуриро-
ванный тип. В SQL:1999 ссылочные типы обладают областью действия— таблица, на
которую они ссылаются, известна во время компиляции (т.е. динамическая классифи-
кация не поддерживается (см. разд. 2.1.5.2.3)).
Как И следовало ожидать, значением ссылочного типа является OID, и оно уникаль-
но в пределах базы данных; указывает на строку в таблице, которая допускает ссылки на нее
(referenceable table). Эта подходящая для ссылок таблица должна быть типизированной таб-
лицей (typed table), т.е. таблицей с ассоциированным структурированным типом. Ссылоч-
ные типы можно использовать в ОРБД для реализации ассоциаций “один к одному”.
' Для реализации ассоциаций “многие ко многим" можно использовать коллекции (разд.
8.3Л.1) ссылок— при их наличии. На рис. 8.10 использован пример, представленный
на рис. 8.3, чтобы продемонстрировать, каким образом можно представить в ОРБД
ассоциацию “многие ко многим” между объектами Student и Courseoffering.
«object table»
____________Student____________
name: varchar(60)
studjdchar(8)
crs off: set(ref(CourseOffering))
«object table»
Courseoffering
crsjiame: varchar(40)
semester: char
std: list(ref(Student)
Puc. 8.10. Ассоциация в объектно-реляционной модели базы данных
8.3.1.5. Столбцы, поля и атрибуты
Стандарт SQL:1999 проводит четкое различие между понятием столбцов, полей и
атрибутов [83]. Это важное терминологическое уточнение. Ниже приводится смысл
различий.
Столбец (column) — это структурный компонент таблицы.
Поле (field) — это структурный компонент строчного типа.
Атрибут (attribute) — это структурный компонент структурированного типа.
Столбец доступен для пустых значений (nullable) и может принимать значения NULL.
Он может быть также идентифицирующим столбцом (принимающим значения OID).
Типом данных столбца, поля и атрибута может быть ссылочный тип.
8.З.1.6. Наследование типа OF и UNDER
Стандарт SQL:1999 допускает специализацию существующих типов. В настоящее время
допустимо только одинарное наследование. Иерархию таблиц можно создать в соответствии с
иерархией типов, т.е. “супертаблица” должна быть объявлена как “принадлежащая” (англ,
“of’) супертипу, а “подтаблица” как “принадлежащая” подтипу. Однако, в иерархии табли-
цы тип может быть “пропущен”, как показано на рис. 8.11.
Программа на языке SQL:1999, приведенная ниже диаграммы на рис. 8.11, отно-
сится к типу с наиболее сильной специализацией (ManagerTY) и к таблице (Manager).
Ключевое слово under используется в SQL: 1999 для установления иерархии типов и
иерархии таблиц. Ключевое слово of устанавливает структурированный тип таблицы.
336 Глава 8. Проектирование баз данных
Мы также используем ключевое слово OF как имя отношений обобщения между таб-
лицами и Их типами на диаграмме.
Мы объявили тип ManagerTY как instantiable — это значит, что мы можем соз-
давать объекты этого типа. Мы также объявили его как специализированный тип
final — это значит, что подтипы для него больше недопустимы.
create type ManagerTY
under FullTimeEmployeeTY
as (managerial position varchar (20),
salary_supplement money)
instantiable
final;
create table Manager of ManagerTY
under Employee;
Puc. 8.11. Наследование в объектно-реляционной модели базы данных
Заметим, что SQL: 1999 не содержит какого-либо явного понятия интерфейса. Ин-
капсуляция (закрытый, защищенный, открытый) не определена. Принятое в SQL: 1999
наследование является одинарным наследованием реализации.
8.3.2. Отображение в ОРБД
Так же, как в случае модели ОБД, отображение классов UML, содержащихся в па-
кете сущностей, в проект схемы ОРБД может быть осуществлено средствами самого
UML. Стереотипов UML и других механизмов расширяемости должно быть доста-
точно для выражения понятий ОРБД.
8.3. Объектно-реляционная модель базы данных 337
Заметим, однако, что на практике отображение осуществляется не по отношению
к “абстрактному” стандарту SQL:1999, а к реальному продукту ОРБД. Реальный про-
дукт может не поддерживать некоторых возможностей SQL: 1999 и, в то же время,
может обладать возможностями, не представленными в SQL:1999.
Поэтому, например, текущая версия Огас1е8 (на момент написания книги — редак-
ция 8.1.5.0.0 Oracle8i) не поддерживала ни наследования, ни строчного типа. В каче-
стве типа коллекции она включала только массив и не включала каких-либо других ти-
пов коллекций, а также включала понятие вложенной таблицы, которая допускала
вложенную таблицу ссылок. Она включала понятие представления объекта для
“преобразования” реляционных таблиц в объекты и т.д.
8.3.2.1. Отображение классов-сущностей
Обратитесь к спецификациям классов для приложения Управление контактами с клиента- !
ми е примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Обратитесь также к примеру 8.1 (разд. 8.2.2.1). !
Наша задача заключается в разработке проекта модели ОРБД, семантически соответст- i
вующей проекту ОБД, представленному на рис. 8.5.
Рис. 8.12. Отображение классое-суцрюстей в проект схемы объектнореляционной
модели базы данных (Управление контактами с клиентами)
338 Глава 8. Проектирование баз данных«
Этот пример требует принять решение по поводу того, каким образом отобразить
ОБД-интерфейсы (рис. 8.5). В SQL: 1999 интерфейсы не поддерживаются, но нам по-
прежнему необходимо некоторым образом моделировать классы PersonShortName и
PersonLongName.
Рис. 8.12 демонстрирует два возможных решения. В случае класса
PersonLongName для него создается структурированный тип. Затем он используется
в качестве типа атрибута EmployeeTY. В случае класса PersonShortName мы создаем
класс (person short name) для “имитации” строчного типа (строчный тип — это не
объектно-ориентированное понятие!). Таблица Contact принадлежит типу
ContactTY, однако, она включает дополнительный столбец person_short_name,
принадлежащий строчному типу. Отношение зависимости по отношению к классу
person_short_name используется для отображения структуры строчного типа.
8.3.2.2. Отображение ассоциаций
Обратитесь к спецификациям ассоциаций для приложения Управление контактами с 5
клиентами в примере 4.8, рис. 4.5 (разд. 4.2.2.3). Обратитесь также к предыдущему •:
примеру отображения для приложения “Управление контактами с клиентвми”, приве- !
денному в разд. 8.2.2.2 и 8.3.2.1. • (
Задача в этом примере заключается в разработке проекта модели ОРБД, семантически !
соответствующей проекту ОБД. представленному на рис. 8.6 (разд. 8.2.2.2). Чтобы уп- i
ростить решение и в то же время сконцентрироваться на спецификации ассоциации, j
предположим, что все ОБД-интерфейсы, приведенные на рис. 8.6, преобразованы к i
строчному типу нашего проекта ОРБД (в решении нет необходимости показывать опре- ;
деления строчных типов). >'
Наше решение для примера показано на рис. 8.13. Объектные таблицы содержат
столбцы, типизированные как строчные типы, и столбцы, типизированные как ссы-
лочные типы. Структурные типы содержат атрибуты, типизированные как исходные
типы или как коллекции исходных типов.
8.3.2.3. Отображение агрегаций
| Обратитесь к спецификациям агрегаций для приложения Запись на университетские <
| курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
J Наша задача в этом примере заключается в отображении UML-модели, показанной на •
| рис. 4.6, в проект схемы ОРБД. Хотя мы разработали проект ОБД для этой проблемы в
[примере 8.3, мы не желаем оказаться под его влиянием при решении данного примера. >
Мы предполагаем, что коллекции структурированных типов (не только коллекции элемен- >
тарных исходных типов) поддерживаются как типы атрибутов в структурированных типах. ,
При разборе этого примера требуется принять решение по поводу того, каким образом
моделировать в терминах ОРБД UML-агрегацию и UML-композицию. Предположение,
изложенное в определении примера, дает нам четкие указания. Композицию между клас-
сами Student и AcademicRecord можно моделировать в классе Student с помощью ат-
рибута, типизированного как коллекция классов AcademicRecord. Это показано на
рис. 8.14. Коллекция представляет собой множество set (AcademicRecordTY).
8.3. Объектно-реляционная модель базы данных 339
Рис. 8.13. Отображение ассоциаций в проект схемы объектно-реляционной модели базы
данных (Управление контактами с клиентами)
UML-агрегацию между классами Course и Courseoffering можно моделировать
как обычную ассоциацию — с помощью ссылок. Для каждой таблицы объектов необ-
ходимо задать соответствующий структурированный тип. Это необходимо, помимо
340 Глава 8. Проектирование баз данных
прочего, с точки зрения того требования стандарта языка SQL:1999, что значение ти-
па ref должно идентифицировать строку в типизированной таблице (т.е. таблице за-
данного структурированного типа).
Рис. 8.14. Отображение ассоциаций в проект схемы обьектнореляционной модели
базы данных (Управление контактами с клиентами)
8.3. Объектно-реляционная модель базы данных 341
8.3.2.4. Отображение обобщений
। Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в ;
* примере 4.10, рис. 4.7 (разд. 4.2.4.3). Обратитесь также к предыдущему примеру ото- i
{ бражения обобщений в проект ОБД в разд. 8.2.2.4.
! Наша задача заключается в разработке проекта модели ОРБД, семантически соответст- ?
| вующей проекту ОБД, представленному на рис. 8.8. (разд. 8.2.2.4).
I Поскольку у нас нет уверенности в том, каким образом модель ОРБД должна поддерживать i
| выводимые и статические атрибуты, мы предполагаем, что они вычисляются процедурно и
| моделировать их в качестве структур данных ОРБД нет необходимости. Рассмотрение каса- ;
; ется двух атрибутов: is_in_stock (B3Bnace)nnumber_currently_available (в наличии).
Основная трудность при решении этого примера имеет только косвенное отношение к
отображению обобщения. Основная проблема связана с ограничением стандарта
SQL:1999, которое выражается в том, что значение ссылочного типа ref “заключено” в
пределах области действия. В области действия типа ref может находиться только одна
таблица, и эта область действия должна быть известна статически — во время компиляции.
Перед этим мы связали класс MovieTitle с интерфейсом VideoMedium в предпо-
ложении, что любой объект VideoMedium (т.е. BetaTape, VHSTape или DVDDisk)
связан с MovieTitle. Теперь же, чтобы справиться с проблемой, мы вынуждены соз-
дать в MovieTitle три ассоциации. Полностью решение приведено на рис. 8.15.
Рис. 8.15. Отображение обобщения в проект схемы объектнореляционной модели базы
данных (Магазин видеопроката)
?>4Э. Глава 8. Проектирование баз данных
8.4. Модель реляционной базы данных
В течение последних двадцати лет реляционная модель господствовала на рынке
ПО баз данных. Модель реляционной базы данных (РБД) пришла на смену иерархи-
ческой и сетевой моделям баз данных. Во второй половине 1990-х годов поставщики
реляционных систем управления базами данных (СУРБД) постоянно увеличивали
свое внимание к модели объектной базы данных, стандартам ODMG и различным
продуктам СУОБД.
Как следствие возник целый ряд продуктов СУОБД, которым сегодня прочат ве-
дущую роль в будущем. Поставщики традиционных СУРБД, такие как Oracle, IBM или
Informix, предлагают сегодня продукты, которые оказывают наибольшее влияние на
этот сегмент рынка. (Компания Informix вместе с соответствующими продуктами бы-
ла приобретена в 2001 году компанией IBM. Прим. ред.). Между тем слабые продукты
СУОБД не увеличили своей рыночной доли, более того, произошел сдвиг в самом их
назначении — они превратились в API-интерфейсы хранилищ объектов, предназна-
ченные для поддержки интероперабельности клиентских приложений и различных
серверных источников данных, в частности, реляционных баз данных.
Хотя будущее более и не принадлежит моделям РБД, инерция развития бизнеса
такова, что должно пройти десятилетие, если не больше, прежде чем станет замет-
ным переход больших систем на технологию ОРБД или ОБД. Кроме того, в ближай-
шем будущем появится огромное количество приложений, разработанных в техноло-
гии РБД, просто потому, что предприятия и организации стремятся избегать слож-
ных и трудных в освоении объектных решений.
Ныне действующий (и последний из разработанных) стандарт для модели РБД из-
вестен как стандарт SQL92. Он был принят ANSI и ISO в 1992 году. Подавляющее
большинство продуктов СУРБД на рынке (Oracle, DB2, Sybase, Informix, Microsoft
SQL Server и др.) соответствуют этому стандарту, хотя каждый в своей собственной
манере. Фактически, некоторые концепции РБД (например, триггер (trigger)) уже были
широко реализованы в продуктах СУРБД, прежде чем получили официальное при-
знание в рамках стандарта SQL: 1999.
8.4.1. Элементарные типы модели РБД
Элементарные типы модели РБД, конечно же, элементарны по определению. Про-
стота модели РБД, которая вытекает из математического понятия множества, .составляет
как сильную, так и слабую стороны этой модели. Математический фундамент, на кото-
ром зиждется реляционная модель, определил ее декларативный характер (в противопо-
ложность процедурному). Пользователь просто объявляет, что ему требуется получить от
базы данных, а не инструктирует систему о том, как именно отыскать нужную информа-
цию (СУРБД знает, как искать данные в своей базе данных).
Однако то, что кажется простым поначалу, становится довольно сложным вместе с
ростом сложности решаемой проблемы. Для сложных проблем нет простых решений.
Чтобы решить сложную проблему, требуются тонкие механизмы. Чтобы приступить к
моделированию, потребуются развитые элементарные типы данных.
Наверное лучший путь охарактеризовать модель РБД — сформулировать, какие из
элементарных типов она не поддерживает. Из основных элементарных типов моде-
лирования, применяемых в моделях ОБД и ОРБД, реляционная модель не поддержи-
вает следующих.
8.4. Модель реляционной базы данных 343
Объектные типы и связанные с ними понятия (такие, как наследование или
методы).
Структурированные типы.
Коллекции.
Ссылки.
Основным элементарным типом модели РБД является реляционная таблица
(relational table), которая состоит из столбцов. Столбцы таблицы могут принимать толь-
ко атомические значения — структурированные значения или значения коллекций не
допускаются.
Модель РБД ведет себя весьма жестко в отношении любых видимых пользователю
навигационных связей между таблицами — они исключаются. Отношения между табли-
цами поддерживаются с помощью сравнения значений в столбцах. Постоянные связи
отсутствуют. Полезное свойство ОРБД по поддержанию предопределенных отноше-
ний между таблицами называется ссылочной целостностью (referential integrity).
На рис. 8.16 показаны элементарные типы модели РБД и зависимости между' ними.
Все понятия выражены с помощью существительных в единственном числе, однако,
некоторые зависимости применимы, более чем к одному экземпляру понятия. Па-
пример, ссылочная целостность определяется на одной или более таблицах. Большая
часть понятий, приведенных на рис. 8.16, рассматривается в последующих разделах
этой главы. Другие понятия более подробно рассмотрены в главе 9.
Рис. 8.16. Зависимости между элементарными типами модели РБД
344 Глава 8. Проектирование баз данных
8.4.1.1. Столбцы, домены и правила
Реляционные базы данных определяют данные в столбцах и строках. Значение
данных, хранимых на пересечении любого столбца и строки, должно быть простым
(неделимым) и однократным (не повторяющимся) значением. Мы. говорим, что
столбцы образуют атомические домены (atomic domains) (типы данных).
Домен (domain) определяет допустимое множество значений, которое может при-
нимать столбец. Домен может быть безымянным (например, gender char (1)) или
может быть поименован (например, gender Gender). В последнем случае домен
Gender был определен ранее и используется в определении столбца. Ниже приводит-
ся возможный синтаксис определения домена.
create domain Gender char(l);
Именованный домен.можно использовать для определения многих столбцов в раз-
личных таблицах. Это способствует достижению непротиворечивости между этими
определениями. Изменения, вносимые в определение домена, автоматически отра-
жаются на определении столбца. Хотя подобная возможность и выглядит на первый
взгляд довольно привлекательно, ее использование тут же становится помехой, как
только база данных заполняется, т.е. загружается данными.
Со столбцами и доменами могут быть связаны некоторые бпзпес-правила, накла-
дывающие на них ограничения. Бизнес-правила могут определять следующие харак-
теристики данных.
Значение, используемое по умолчанию (например, если для города (city) не задано
никакого значения, предполагается значение “Сидней”).
Диапазон значений (например, допустимое значение для возраста (аде) лежит в
пределах от 18 до 80).
Список значений (например, допустимыми цветами (color) могут быть “зеленый”,
“желтый” или “красный”).
Регистр, используемый для представления значения (например, значение должно
состоять из символов верхнего или нижнего регистра клавиатуры).
Формат значения (например, значение должно начинаться с буквы “К”).
С помощью средств задания правил можно определить только простые правила,
относящиеся к единственному столбцу или домену. Более сложные правила, охваты-
вающие таблицы, можно определить с помощью правил ограничения целостности. Ос-
новным механизмом определения бизнес-правил являются триггеры.
8.4.1.2. Реляционные таблицы
Реляционная таблица (relational table) определяется фиксированным множеством
своих столбцов. Типы данных, которые хранятся в столбцах, относятся к встроенным
или определяемым пользователем типам (т.е. доменам). Таблица может содержать
произвольное количество строк (или.записей). Поскольку таблица есть не что иное,
как математическое множество, повторяющиеся строки в таблице отсутствуют.
Для некоторых столбцов допускается, что значение столбца в определенной стро-
ке может принимать значение NULL. Значение NULL означает одну из двух возможно-
стей: “не определенное в данный момент значение” или “неприменимое значение”
(разд. 8.2.1.1).
8.4. Модель реляционной базы данных 345
Одним из следствий требования к модели РБД, которое состоит в недопустимости
дублирования строк, является наличие у каждой таблицы первичного ключа (primary key}.
Ключ— это минимальное множество столбцов (возможно один) таких, что значения в
этих столбцах единственным способом идентифицируют одну строку в таблице. Таблица
может содержать много подобных ключей. Один из этих ключей произвольным обра-
зом выбирается как наиболее важный — это первичный ключ (primary key}. Другие ключи
называются потенциальными (candidate) или альтернативным (alternative) ключами.
На практике таблица СУРБД не обязана иметь ключ. Это значит, что таблица (без
уникального ключа) может содержать идентичные строки — чудное бесполезное
свойство реляционной базы данных, когда две строки, содержащие одинаковые зна-
чения во всех своих столбцах, никак нельзя отличить. В системах ОБД и ОРБД по-
добное различение обеспечивается за счет наличия OID (два объекта могут быть рав-
ными, но не идентичными, например, как две копии одной книги).
Хотя существует возможность ввести в UML стереотипы для моделирования реля-
ционных баз данных, более удобно использовать специально предназначенные для
этого диаграммные методы, позволяющие осуществить логическое моделирование
реляционных баз данных. На рис. 8.17 показана одна из подобных систем нотации. В
качестве целевой базы данных здесь использовалась база данных DB2 копании IBM.
Employee
emp id CHAR(7) <pk> not null
family_name VARCHAR(30) <ak> not null
first_name VARCHaA(20) not null.
date_of_birth DATE <ak> not null
gender Gender not null
phone_num1 VARCHAR(12) null
phone_num2 VARCHAR(12) null
salary DEC(8,2) null
Рис. 8.17. Определение таблиц реляционной
базы данных
Таблица Employee состоит из восьми столбцов. Последние три столбца допускают в
качестве значений использование значения NULL. Столбец emp_id представляет собой
первичный ключ. Столбцы {family name, date_of_birth} определяют потенци-
альные (альтернативные) ключи. Столбец gendeг определен на домене Gender.
Поскольку на РБД накладывается ограничение, которое заключается в том, что
столбцы могут принимать только атомические Однократные значения, моделирова-
ние имени и телефонного номера работника вызывает у нас определенные затрудне-
ния. В предыдущем случае мы использовали два столбца : family_name и
first__name. Столбцы не сгруппированы и никак не связаны в модели. В последнем
случае мы предпочли решение с двумя? столбцами (phone numl, phone_num2 ), допус-
кающими наличие максимум двух телефонных номеров у каждого работника.
После того, как таблица определена с помощью CASE-средств, можно автоматиче-
ски сгенерировать программный код для создания таблицы, как показано ниже. Сге-
нерированный текст программы включает определение домена Gender и определе-
ние бизнес-правила, определенного на этом домене.
346 Глава 8. Проектирование баз данных
—• Domain: Gender
create distinct type Gender as CHAR(l) %WITHCOMPAR%;
— Table: Employee
create table Employee (
emp_id CHAR(7) not null.
family_name VARCHAR(30) not null.
first_name VARCHAR(20) not null,
date_of_birth DATE not null.
gender Gender not : null
constraint C_ gender check (gender in ('F' ','M','f','m')),
phone_numl VARCHAR(12) ,
phone_num2 VARCHAR(12) ,
salary DEC(8,2),
primary key (emp_id),
unique (date__of_birth, family_name)
) ;
8.4.1.3. Ссылочная целостность
Модель РБД поддерживает отношения между таблицами посредством ограниче-
ний ссылочной целостности. Отношения не привязаны к связям отдельных строк
между собой. Вместо этого РБД “отыскивает” связи между строками всякий раз, когда
пользователь просит систему отыскать соответствующие отношения. Это
“нахождение” осуществляется с помощью сравнения значений первичных ключей в
одной таблице со значениями внешних ключей в той же самой или другой таблице.
Внешний ключ (foreign key) определяется как множество столбцов в одной или более
таблицах, значения которых либо равны NULL, либо должны совпадать со значениями
первичного ключа в той же самой или другой таблице. Это соответствие между пер-
вичным и внешним ключом называется ссылочной целостностью. Первичный и внеш-
ний ключи, участвующие в определении ссылочной целостности, должны быть опре-
делены на одном и том же домене, однако, они не обязательно должны иметь одина-
ковые имена.
На рис. 8.18 показано графическое представление ссылочной целостности. В ре-
зультате изображения отношения между таблицами Employee и Department к таб-
лице Employee был добавлен внешний ключ dept_id. Для каждой строки таблицы
Employee значение внешнего ключа должно быть либо равно NULL, либо совпадать с
одним из значений dept_id в таблице Department (в противном случае сотрудник
может работать в несуществующем подразделении).
8.4» Модель реляционной базы данных 347
Department
dept id SMALLINT <pk> not null
dept_name VARCHAR(50) not null
address VARCHAR(120) null
deptjd = deptjd
Upd(R); Del(R)
Employee
emp id CHAR(7) <pk> not null
deptjd SMALLINT <fk> null
family_name VARCHAR(30) <ak> not null
first_name VARCHAR(20) not null
date_of_birth DATE <ak> not null
gender Gender not null
phone_num1 VARCHAR(12) null
phone_num2 VARCHAR(12) null
salary DEC(8,2) null
Рис. 8.18. Ссылочная целостность
Дополнительное описание, сопровождающее линию отношения, декларативно оп-
ределяет поведение, связанное со ссылочной целостностью. Существует четыре воз-
можных декларативных ограничения ссылочной целостности, связанных с опера-
циями delete и update. А именно, вопрос состоит в том, что делать со строками таблицы
Employee при удалении или обновлении строк таблицы Department (т.е. обновляет-
ся столбец dept_id). На этот вопрос существует четыре варианта ответа.
1. Upd (R) ; Del (R) — ограничить операции update или delete (т.е. не давать воз-
можности операции выполниться, если только еще в таблице Employee суще-
ствуют строки, связанные с данным подразделением — Department).
2. Upd (С) ; Del (С) — каскадировать операцию (т.е. удалить все строки таблицы
Employee, связанные с данным подразделением — Department).
3. Upd (N); Del (N) — установить значение ключа равным null (т.е. обновить или
удалить строку таблицы Depar tment и установить ключ dept_id для связанной
строки таблицы Employee в NULL).
4. Upd(D); Del (D) — установить значение ключа равным значению, принятому
по умолчанию (т.е. обновить или удалить строку таблицы Department и устано-
вить ключ dept_id для связанной строки таблицы Employee равным значению
по умолчанию).
Рис. 8.19. Ссылочная целостность для отношений “многие ко многим”
848 Глава 8. Проектирование баз данных
Моделирование ссылочной целостности усложняется, когда отношение между
таблицами принимает характер “многие ко многим”, как в случае отношения между
классами Student и Courseoffering (рис. 8.3 в разд. 8.2.1.2). Чтобы справиться с
проблемой, вызванной ограничением на РБД, которое выражается в недопустимо-
сти принятия столбцом множественных значений, нам требуется ввести перекрест-
--- таблицу (intersection table) наподобие таблицы StdToCrsOff, показанной на
8.19. Единственным назначением этой таблицы является моделирование от-
гний “многие ко многим” и задание декларативных ограничений ссылочной
стности.
1.4. Триггеры
травила и декларативные ограничения ссылочной целостности позволяют определять
тые бизнес-правила на базе данных. Их недостаточно для определения более
;ных правил или каких-либо исключений из правил. Применительно к РБД ре-
лем данной проблемы (в соответствии со стандартом SQL: 1999) является триг-
rigger).
риггер — это небольшая программа, написанная в расширенном языке SQL, ко-
я выполняется автоматически (запускается) в результате операции модифика-
таблицы, над которой определен триггер. В качестве операции модификации
;т выступать любой оператор'модификации языка SQL: insert, update или
>te.
риггер можно использовать для реализации бизнес-правил, которые выходят за
:и возможностей оператора rule правил SQL (разд. 8.4.1.1). Например, бизнес-
ило, которое запрещает вносить изменения в таблицу Employee во время выход-
можно запрограммировать в виде триггера. Любая попытка применить к табли-
зератор SQL insert, update или delete в выходные дни приводит к срабатыва-
триггера, и база данных отказывается выполнять операцию.
риггер можно также использовать для приведения в действие более сложных ог-
(чений ссылочной целостности. Например, наше бизнес-правило может гласить,
при удалении строки таблицы Department (подразделение) строка таблицы
.оуее, которая представляет информацию о работнике, который является ме-
сером этого подразделения, также должна быть удалена. При этом для всех ос-
ных работников (не менеджеров) значения dept_id должны быть установлены в
Подобное бизнес-правило невозможно ввести декларативно. Чтобы привести
. исполнение, необходимо задействовать процедурный триггер.
ели для введения ссылочной целостности над базой данных используются триг-
I, декларативные ограничения ссылочной целостности обычно ликвидируются,
пение процедурных и декларативных ограничений — плохая идея, поскольку зна-
льно затрудняет их взаимодействие. Как следствие, сегодня преобладает практи-
рограммирования ограничений ссылочной целостности только на основе тригге-
ров. Проблема на самом деле не так страшна, как может показаться на первый взгляд,
поскольку мощные CASE-средства способны генерировать большую часть программ-
ного кода автоматически. <
Например, ниже приведена программа для триггера, сгенерированная с помощью
CASE-средств для СУРБД Sybase. Триггер реализует декларативное ограничение
Del (г) — т.е. он не позволяет удалить строку таблицы Department до тех пор, пока
существует хоть одна строка таблицы Employee, связанная с ней.
8.4. Модель реляционной базы данных 349
create trigger keepdpt
on Department
for delete
as
if @@rowcount = 0
return /* avoid firing trigger if no rows affected
*/
if exists
(select * from Employee, deleted
where Employee.dept_id =
deleted.dept_id)
begin
print 'Test for RESTRICT DELETE failed. No deletion'
rollback transaction
return
end
return
go
Оператор проверяет, осуществляется ли операция SQL delete (которая запускает
триггер) по удалению вообще какой-либо строки. Если это не так, триггер прекращает
свои действия — никакого вреда нанесено быть не может. Если строка таблицы
Department может быть удалена, СУБД Sybase запоминает эти (подлежащие удале-
нию) строки в промежуточной таблице с именем deleted. Затем триггер выполняет
операцию логического соединения по столбцу dept_id на таблицах Employee и
deleted, чтобы определить, существует ли хоть один сотрудник, работающий на
подразделение, информация о котором подлежит удалению. Если это так, то триггер
отклоняет действие по удалению, отображает сообщение и осуществляет откат тран-
закции. В противном случае строку таблицы Department разрешается удалить.
8.4.1.5. Реляционные представления
Реляционное представление {relational view) (иногда называемое сленговым термином
взгляд. Прим, ред.) — хранимый и поименованный SQL-запрос. Поскольку результатом
любого SQL-запроса является переходная таблица, представление может использо-
ваться вместо таблицы в другом SQL-операторе, выводиться на основе одной или бо-
лее таблиц и/или одного или более других представлений (рис. 8.16).
EmpNoSalary
Employee.empjd
Employee.deptjd
Employee.family_name
Employee.first_name
Employee.date_of_blrth
Employee, gender
Employee.phone_num1
Employee.phone_num2
S Employee
Puc. 8.20. Реляционное представление
350 Глава 8. Проектирование баз данных
На рис. 8.20 показан графический вид представления EmpNoSalary — представление
отображает всю информацию из таблицы Employee за исключением столбца salary.
Оператор создания представления create view демонстрирует, что представление
фактически является именованным запросом, который выполняется всякий раз при
выдаче SQL-запроса или оператора обновления применительно к представлению.
— View: EmpNoSalary
create view EmpNoSalary () as
select Employee.emp_id, Employee.dept_id,
Employee.family_name. Employee.firstjiame,
Employee.date_of_birth, Employee.gender.
Employee,phone_numl, Employee.phone_num2
from Employee;
Теоретически представление являет собой очень мощный механизм, который на-
ходит множество применений; использоваться для поддержки безопасности базы date
ных за счет ограничения круга пользователей, имеющих возможность просмотра таб-
лицы; представить данные пользователю в различных разрезах. Оно может изолиро-
вать приложение от изменения определений таблицы, если изменяемое определение не
составляет части представления. Оно позволяет упростить выражения для сложных
запросов — запрос может быть встроен в манере “разделяй и властвуй” за счет исполь-
зования нескольких уровней представлений.
На практике использование концепции представления в модели РБД жестко oq>a-
ничено из-за невозможности обновления представления. Обновление представления
эквивалентно возможности отправки операции модификации (SQL-операторы
insert, update или delete) представлению и изменению в результате базовых таб-
лиц базы данных. Поддержка обновления представления в рамках стандарта SQL92
весьма ограничена — она практически отсутствует.
8.4.1.6. Нормальные формы
Можно с уверенностью утверждать, что одной из наиболее важных, но в то же
время недооцениваемых концепций проектирования РБД является нормализация
{normalization). Реляционная таблица должна быть представлена в нормальной форме
(НФ). Существует шесть типов нормальных форм.
1-я НФ
2-я НФ
3-я НФ
НФБК (Нормальная форма Бойса-Кодда (Boyce-Codd))
4-я НФ
5-я НФ
Таблица, представленная в младшей нормальной форме, также представлена и в
более старшей НФ. Она должна быть приведена, по меньшей, мере в 1-й НФ. Таблица,
в которой отсутствуют структурированные или многозначные столбцы, выражена в 1-
й НФ (и это составляет фундаментальное требование модели РБД).
8.4. Модель реляционной базы данных 351
Таблица в младшей НФ может проявлять так называемые аномалии обновления.
Аномалия обновления— это нежелательный побочный эффект, возникающий в результате
выполнения операции модификации (insert, update, delete) над таблицей. Напри-
мер, если одна и та же информация многократно повторяется в одном и том же столбце
таблицы, обновление этой информации должно осуществляться в каждом месте ее хра-
нения, иначе база данных останется в некорректном состоянии. Можно показать, что
аномалии обновления постепенно устраняются по мере перехода к старшим НФ.
Итак, каким образом можно нормализовать таблицу к старшей НФ? Таблиц}' мож-
но привести к старшей НФ, разделив ее по вертикали вдоль столбцов на две или более
таблицы меньшего размера. Эти меньшие таблицы, скорее всего, окажутся в старшей
НФ и заменят исходную таблицу в проекте модели РБД. Исходная таблица, однако,
может всегда быть восстановлена с помощью объединения меньших таблиц с исполь-
зованием SQL-оператора join.
Рамки этой книги не позволяют нам рассмотреть теорию нормализации сколько-
нибудь подробно. За подробностями читатель может обратиться к книгам Дейта
(Date) [17], Мацяшека (Maciaszek) [51], Зильберкатца (Silberschatz) [79], Рамакриш-
нана (Ramakrishnan) и Герке (Gehrke) [67]. Единственный момент, который нам хо-
телось бы подчеркнуть, это то, что надлежащее проектирование РБД проводится на
надлежащем уровне нормализации.
Что мы подразумеваем под надлежащим проектом в контексте нормализации? Над-
лежащий проект означает, что у нас есть понимание того, каков будет характер использо-
вания РБД с точки зрения смеси операций обновления и получения информации. Если
база данных отличается динамизмом, т.е. подвергается частым операциям обновления,
то мы, естественно, должны стремиться создавать небольшие по размерам таблицы для
лучшей локализации и осуществления этих действий по обновлению. Таблицы создают-
ся в старшей НФ, и аномалии обновления будут устранены или уменьшены.
С другой стороны, если база данных отличается относительно статичным харак
тером, т.е. над ней часто выполняются операции поиска информации, а ее содержи-
мое обновляется время от времени, приобретает смысл денормализованный проект базы
данных. Это является следствием того, что поиск в одной таблице большого размера
оказывается намного более эффективным, чем аналогичный поиск в нескольких таб-
лицах, которые требуется объединить перед началом поиска.
8.4.2. Отображение в РБД
При отображении модели классов UML в проект схемы РБД необходимо учиты-
вать ограничения на модель РБД. Речь идет о том, чтобы поступиться некоторой дек
ларативной семантикой диаграмм классов в счет процедурных решений проекта логиче-
ской схемы базы данных. Другими словами, может оказаться невозможным выразить
некоторую встроенную декларативную семантику классов в реляционной схеме. По-
добная семантика должна получить процедурное разрешение в программах базы дан-
ных, т.е. в хранимых процедурах (разд. 9.1.2.1).
Проблемы отображения в модель РБД широко изучались в контексте ER-
моделирования и расширенного ER-моделирования (например, [51], [22]). В ходе
этих исследований использовались те же принципы и были выявлены все основные
вопросы. Так же как в случае моделей ОРБД и ОБД, отображение должно не просто
соответствовать некоторым стандартам (в случае РБД это SQL92), но также учиты-
вать особенности целевой СУРБД.
352 Глава 8. Проектирование баз данных
8.4.2.1. Отображение классов-сущностей
Отображение классов-сущностей в реляционные таблицы должно удовлетворять
1-й НФ таблиц. Столбцы должны быть атомическими типами. Однако, хотя об этом п
неудобно напоминать, как мы уже отмечали в разд. 8.2.2.1, атрибуты классов (в проти-
воположность атрибутам отношений) в модели анализа UML уже относятся к атоми-
ческому типу. Это упрощает отображение.
i Обратитесь к спецификациям классов для приложения Управление контактами с клиен-
‘ тами в примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Рассмотрите также обсуждение, касаю-
J щееся не атомических атрибутов в примере 8.1.
I Отобразите классы Contact и Employee в проект РБД таким образом, чтобы продемон-
• стрировать несколько альтернативных стратегий отображения.
Наше решение для данного примера приведено на рис. 8.21. В решении предполагает
ся использование СУРБД Oracle. Мы моделируем contact_name как атомический тан
данных в таблице Contact. Для каждого контактного лица (Contact) предполагается на-
личие только одного факса и адреса электронной почты. Однако, мы допускаем щхлст-
вольное количество телефонных номеров. Этой цели служит таблица Contact Phone.
В таблице Employee мы держим три отдельных атрибута для имен работника:
family_name, first_name и middle_initial. Однако, в базе данных не содержит-
ся никаких сведений об имени работника employee_name как некоторой комбинации
этих трех атрибутов.
Employee
employee id CHAR(8) <pk> not null
family_name VARCHAR2(30) not null
first_name VARCHAR2(20) not null
middle initial CHAR null
Puc. 8.21. Отображение классов-сущностей в проект РБД (Управление контактами
с клиентами)
8.4.2.2. Отображение ассоциаций
Отображение ассоциаций в РБД связано с использованием ограничений ссылочной
целостности между таблицами. Любую ассоциацию кратности “один к одному” или “один
ко многим” можно непосредственно выразить с помощью помещения внешнего ключа в
одну из таблиц для установления соответствия первичному ключу другой таблицы.
В случае ассоциации “один к одному” внешний ключ может быть добавлен к любой
из таблиц (решение здесь принимается на основе использования шаблонов ассоциа
8.4. Модель реляционной базы данных 353
ций), а также может быть желательно составить комбинацию из двух классов-
сущностей в одной таблице (в зависимости от требуемого уровня нормализации).
Для рекурсивных ассоциаций “один к одному” и “один ко многим” внешний ключ и
первичный ключ помещаются в одной таблице. Каждая ассоциация “многие ко многим"
(независимо от того, рекурсивна она или нет) требует введения перекрестной табли
цы, как показано на рис. 8.19.
С7|
Обратитесь к спецификациям ассоциаций для приложения Управление контактами с
! клиентами в примере 4.8, рис. 4.5 (разд. 4.2.2.3).
’ Отобразите диаграмму, представленную на рис. 4.5, в модель РБД.
Этот пример оказывается довольно простым из-за отсутствия в спецификации ассо-
циаций UML-ассоциаций типа “многие ко многим”. Диаграмма РБД (для СУРБД DB2) по-
казана на рис. 8.22. В соответствии с принципами построения РБД мы создали несколько
новых столбцов в качестве первичных ключей; решили сохранить модель, приведенную
на рис. 8.21, как частичное решение этого примера. Ради экономии места отказались от
отображения способности столбцов принимать значение NULL и индикаторов ключей.
Ограничения ссылочной целостности между таблицами PostalAddress и
CourierAddress с одной стороны, и таблицами Organization и Contact с другой
стороны моделируются с помощью внешних ключей в таблице адресов. Это отчасти
произвольное решение, и ограничения можно было бы моделировать в противопо-
ложном направлении (т.е. посредством введения внешних ключей в таблицы
Organization и Contact).
8.4.2.3. Отображение агрегаций
Модель РБД не различает отношений ассоциации и агрегации за исключением
случаев их процедурной реализации с помощью триггеров или хранимых процедур.
Основные принципы отображения ассоциаций (разд. 8.4.2.2) применимы и к отобра-
жению агрегаций. Только в том случае, когда ассоциация может быть преобразована в
несколько результирующих реляционных решений, семантика агрегации (как специ-
фической формы ассоциации) оказывает влияние на решение.
В случае строгой формы агрегации (т.е. композиции) следует попытаться создать ком-
бинацию подмножества и супермножества класса-сущности в одной таблице. Это возмож-
но в случае агрегации “один к одному”. Для агрегаций типа “один ко многим” класс под-
множества (в сильной и слабой форме агрегации) должен моделироваться в виде отдель-
ной таблицы (с внешним ключом, связывающим ее с ее таблицей-владелицей).
Примерв.П .Запйсьнауниверситетские курсы
» Обратитесь к спецификациям агрегаций для приложения Запись на университетские
курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
Отобразите диаграмму, представленную на рис. 4.6, в модель РБД.
Этот пример включает в отношения агрегации — композиция от класса Student к
классу AcademicRecord и слабая агрегация от класса Course к классу' Course
Offering. Обе агрегации относятся к типу “один ко многим” и требуют отдельных таб-
лиц “подмножества”.
354 Глава 8. Проектирование баз данных
Organization
organization id INTEGER
organfzation_name VARCHAR(BO)
phone VARCHAR) 15)
fax VARCHAR(15)
email VARCHAR(30)
is_current CHARACTER
organizatior iJd = organization id
PostalAddress
___________Contact
contact id
organizationjd
contact_name
fax
email
SMALLINT
INTEGER
VARCHAR(50)
VARCHAR) 15)
VARCHAR) 15)
organizationjd = organization jd
postal id
organizationjd
contactjd
street
po_box
city
state
post_code
country
INTEGER
INTEGER
SMALLINT
VARCHAR(80)
VARCHAR(20)
VARCHAR(50)
VARCHAR(30)
VARCHAR(8)
VARCHAR(50)
contactjd = contactjd
CourierAddress
contact id -
contact
organizationjd = organizationjd
courier id INTEGER
organizationjd INTEGER
contactjd SMALLINT
street_and_directions VARCHAR(255)
city VARCHAR(50)
state VARCHAR(30)
country VARCHAR(30)
contactjd = contactjd
Task
organizationjd = organizationjd
taskjd - taskjd
task id
organizationjd
contactjd
employeeJd
description
created_dt
value
SMALLINT
INTEGER
SMALLINT
CHAR(8)
VARCHAR(255)
DATE
FLOAT
contact id = contact id
______Contact Phone_____
phone VARCHAR) 15)
contactjd SMALLINT
employeeJd = emplcyeejd
Event
event id INTEGER
taskjd SMALLINT
created_empjd CHAR(8)
due_empjd CHAR(8)
completed_emp ld CHAR(8)
description VARCHAR(255)
created_dt DATE
due_dt DATE
completed_dt DATE
priority SMALLINT
Employee
emplcyeejd = created_empid employee Id CHAR(8) family_name VARCHAR(30) firstname VARCHAR(20) middleJnitial CHAR(1)
employeejd = due_empjd
emplcyeejd = completed_empjd
Puc. 8.22. Отображение ассоциации в проект РБД (Управление контактами с клиентами)
Для UML-модели, представленной на рис. 4.6, мы предполагаем (что довольно е<
тественно) опосредованную навигационную связь от класса AcademicRecord к кассу
Course. Что касается проекта РБД, нам может потребоваться установить непосредст
8.4. Модель реляционной базы данных 35f-
венную ссылочную целостность между таблицами AcademicRecord и Course. Кроме
того, таблица AcademicRecord обладает атрибутом course_code как частью ее пер
вичного ключа. Аналогичный атрибут можно ввести во внешний ключ в таблице
Course. Это показано на рис. 8.23 (для СУРБД Informix).
student_id = studentJd
AcademicRecord
student id NCHAR(8) <pk.fk1> not null
course code CHAR(7) <pk.fk2> not null
year DATE <pk> not null
semester NCHAR <pk> not null
grade VARCHAR(2) not null
course code - course code
Student
student id NCHAR(8) <pk> not null
student_name VARCHAR(50) not null
current fees MONEY null
course code = course code
studentJd = studentJd
_____________StdToCrsOff______________
student id NCHAR(B) <pk.fk1> not null
ersoff Id SERIAL <pk.fk2> not null
ersoffJd = crsoffjd
Courseoffering
ersoff id SERIAL <Ek> not nui- ;
course_code CHAR(7) <.ak,fk> not null I
year semester DATE NCHAR <ak> <ak> not null ’ not null I
enrolment_quota SMALLINT null
academicjn_charge VARCHAR(60) null
Puc. 8.23. Отображение ассоциации в проект РБД (Запись на университетские курсы)
Ассоциация “многие ко многим” между классами Student и Courseoffering ведег
нас к другому замечательному наблюдению, хотя и не связанному с отображением <и
регации. Результатом ассоциации является перекрестная таблица StdToCrsOff <
первичным ключом, который образуется в результате конкатенации первичных клю
чей двух главных таблиц.
Первичный ключ для таблицы Courseoffering может выглядеть каь
{course_code, year, semester}. Однако, подобный ключ имеет результатом гро
моздкий первичный ключ для таблицы StdToCrsOff. Поэтому мы останавливаем
свой выбор на первичном ключе в таблице Courseoffering, сгенерированном си<
темой. Он называется ersoff и обладает типом SERIAL (в СУРБД Informix сгеперн
рованные уникальные идентификаторы относятся к типу SERIAL; в других СУРБД.
аналогичный тип может называться иначе— например, в Sybase on называется
IDENTITY, в Microsoft SQL Server-UNIQUEIDENTIFIER и в Oracle - SE_QUENCE).
8.4.2.4. Отображение обобщений
Отображение отношений обобщения можно осуществить разными способами, од-
нако, принципы отображения менее сложны, чем можно было бы ожидать. Следует
однако, помнить, что выражение обобщения через структуры данных РБД пгнорнр'
ет вопросы, которые составляют “соль” обобщения — наследование, полиморфизм,
повторное использование программного кода и т.д.
356 Глава 8. Проектирование баз данных
Для иллюстрации стратегий отображения агрегации рассмотрим пример, пока-
занный на рис. 8.24. Для преобразования иерархии обобщения в проект модели РБД
существует четыре стратегии (хотя для некоторых из этих стратегий возможны до-
полнительные варианты).
1. Отобразить каждый класс в таблицу.
2. Отобразить полную иерархию класса в одну таблицу “суперкласса”.
3. Отобразить каждый конкретный класс в таблицу.
4. Отобразить каждый отдельный класс в таблицу.
Рис. 8.24. Иерархия обобщения, иллюст-
рирующая отображение в модель РБД
Первая стратегия проиллюстрирована на рис. 8.25. Каждая таблица имеет свой
первичный ключ. Представленное решение ничего не говорит о том, “наследует” ш
таблица “подкласса” некоторые из ее столбцов от таблицы “суперкласса”. Например,
хранится ли person_name в Person и “наследуется” ли таблицами Employee.
Student и StudentEmployee? “Наследование” означает в действительности онера
цию соединения, и плата за производительность соедиения может заставить нас про-
дублировать person__name во всех таблицах иерархии.
Вторая стратегия отображения проиллюстрирована на рис. 8.26 (для СУРБД Mi-
crosoft SQL Server). Таблица Person должна содержать комбинированное множество
атрибутов во все классах иерархии обобщения. Она также содержит два столбца
(is_employee и is_student) для фиксирования того, является ли лицо работником,
студентом или и тем и другим.
Для иллюстрации третьей стратегии отображения мы предполагаем, что класс
Person является абстрактным. Все атрибуты класса Person “наследуются” таблицами,
соответствующими конкретному классу. Результат аналогичен показанному на рис. 8.27.
Последняя из стратегий проиллюстрирована на рис. 8.28 (для СУРБД Informix),
при этом по-прежнему предполагается, что класс Person является абстрактным. В
противоположность модели, показанной на рис. 8.25, мы предполагаем, что нам все-
гда известен тот факт, является работник также студентом и наоборот. Отсюда заире i
на значения null для столбцов типа BOOLEAN.
8.4. Модель реляционной базы данных 357
Рис. 8.25. Отображение каждого класса в таблицу
Person
personjd uniqueidentifier <рк> not null
is_employee char(1) null
is student . char(1) null
Puc. 8.26. Отображение иерархии классов в таблицу
Рис. 8.27. Отображение каждого конкретного класса в таблицу
Employee
employee id NCHAR(8) <pk> not null
is^student BOOLEAN not null
Student
student id NCHAR(10) <pk> not null
is employee BOOLEAN not null
Puc. 8.28. Отображение каждого отдельного конкретного класса в таблицу
Проект РБД (для СУРБД Sybase) на рис. 8.29 содержит таблицу для каждого из грех
конкретных классов (BetaTape, VHSTape и DVDDisk). Таблицы дублируют следующую
информацию: video_condition, rental_period_in_days и rental charge
per_period. Для каждой ленты или диска может быть зафиксировано только по одному
параметру rental_period_in_days и one rental_charge_per_period.
358 Глава 8. Проектирование баз данных
Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в
j примере 4.10, рис. 4.7 (разд. 4.2.4.3). Обратитесь также к некоторым расширениям мо-
; дели, введенным в примере 8.4 (разд. 8.2.2.4).
; Задача заключается в том, чтобы отобразить диаграмму, представленную на рис. 4.7, в
' модель РБД с учетом расширений, приведенных на рис. 8.8 (пример 8.4). Мы восполь-
4 зуемся третьей стратегией отображения каждого конкретного класса в таблицу.
I Нам требуется рассмотреть, каким образом справиться с производным атрибутом
• is_in_stock и статическим атрибутом number_currently_available. Как и в преды-
5 дущих моделях, для приложения Магазин видеопроката мы игнорируем возможность
наличия более одного условия аренды для одного и того же видеоносителя (т е.
BetaTape, VHSTape и DVDDisk).
movie_code = movie_code
Mo/ieTitle
movie code char(10) <pk> not null
movie_title varchar(IOO) not null
director varchar(30) null
is_in_stock bit not null
mcwte_code = movie_code
mcwiecode = movie_code
BetaTape
betajd
movie^code
video_condition
rental_period_in_days
identity <pk> not null
char( 10) <fk> not null
chart 1) null
smallint not null
rentai_charge_per_period numeric not null
is taped over bit
not null
DVDDisk
dvd id identity <pk> not null
moviecode char(10) <fk> null
video_condition chart 1) null
rental_periodjn_days smallint not null
rental_charge_per_period numeric not null
differentjanguages bit not null
differentendings bit not nui;
VHSTape
vhs id identity <pk> not null
movie_code chart 10) <fk> not null
video_condition chart 1) null
rental_periodJn_days smallint not null
rental_charge_per_period numeric not null
is_taped_over bit not null
Puc. 8.29. Отображение обобщения в проект РБД (Магазин видеопроката)
Столбцы is_taped_over, dif ferent_languages, dif ferent__endina.s л
is_in_stock введены с типом bit. По определению тип bit не допускает значений
null (столбец типа bit принимает два значения: “0” и “1”).
Столбец is_in_stock устанавливается равным “истина” (“1”), если в запасе име-
ется в наличии, по меньшей мере, одна лента или диск с конкретным фильмом. Э го не
слишком полезная информация, если клиент интересуется одним из трех видсопосн-
телей. Лучшим решением было бы введение трех столбцов типа bit или предполо
Резюме 359
жение о том, что эта информация никогда не хранится, т.е. является производном
(вычисляемой) всякий раз, когда клиент спрашивает ленту или диск.
Статический атрибут number_currently_available не хранится ни в одной из
таблиц, рассматриваемых в нашем проекте. Единственная таблица, в которой он moi
бы постоянно храниться, — это таблица MovieTitle. Если принимается решение вс<
же хранить его в этой таблице, то к нему применимы те же соображения, что для ат
рибута is in_stock.
Резюме
Эта глава отражает крайне важную роль, которую играют базы данных при разрабты
ПО. Неудовлетворительный проект базы данных нельзя компенсировать другими с|х-дс-|
вами, включая качественную разработку приложений. Были рассмотрены все три основ
ные модели баз данных — объектная, объектно-реляционная и реляционная модель.
Существует три уровня моделей баз данных — внешняя, логическая и физическая
В этой главе мы сконцентрировались на логической модели. Под отображением объектов
базу данных мы понимаем отображение классов UML-модели в логическую модель ба
зы данных.
Отображение в логическую модель ОБД осуществляется наиболее просто. Модель
ОБД поддерживает объектные типы наряду со структурированными литералами и лише
ралами-коллекциями. Отношения моделируются с помощью инверсии. Для отображения
обобщений UML можно использовать наследование двух видов: ISA и EXTENDS. Агре
гации UML можно отображать с помощью коллекций.
Логическая модель ОРБД отличается большей сложностью по сравнению с моде лью
ОБД. Модель ОРБД проводит четкое различие между структурированным типом и
таблицей как единственным механизмом хранения данных. Строчный тин позволят i
задавать вложенные структуры данных — возможность, которая ие так просто реали-
зуется в UML. Поддерживаются также ссылки и коллекции ссылок. Для отображения
обобщений UML можно использовать наследование двух видов: ОЕч UNDER.
Отображение в логическую модель РБД особенно неудобно. Модель РБД не поддер
живает объектные типы, наследование, структурированные типы, коллекции пли
ссылки. Данные хранятся в таблицах, связанных ограничениями ссылочной целостности
Для программирования семантики, зафиксированной в бизнсс-правилах, вытекаю
щих из моделей классов UML, можно использовать триггеры. Кроме того, на отобра
жение влияет нормализация таблиц.
И] Вопросы
В1. Дайте пояснения относительно трех уровней моделей баз данных: внешней, логической и
физической модели.
В2. Как происходила эволюция стандартов ОБД? Каково практическое значение этой эволки щи?
ВЗ. В чем заключается различие между типом ОБД и классом ОБД?
В4. Что такое литерал коллекции ОБД? В чем он может быть полезен при отображении из мо
дели классов UML?
В5. Что такое объектный тип коллекции ОБД? В чем он может быть полезен при отображении
из модели классов UML?
В6. Дайте пояснения в отношении семантики и применимости ключевого слова inverse в схеме ОБД.
360 Глава 8. Проектирование баз данных
В7. В чем заключается различие между наследованием по типу ISA и по типу EXTENDS в схеме ОБД >
В8. Как главным образом используется строчный тип (row type) в ОРБД? Можно ли его испо/-г •
зовать для определения ссылочных типов? Объясните свои соображения.
В9. В чем заключается различие между строкой ссылок и коллекцией ссылок в ОРБД?
В10. Поддерживают ли системы ОРБД динамическую классификацию? Поясните свой ответ.
В11. Объясните, в чем заключается различие между столбцом, полем и атрибутом ОРБД?
В12. В чем заключается различие между наследованием по типу OF и по типу UNDER в схеме ОРБД?
В13. Что такое ссылочная целостность РБД? В чем она может быть полезна при отображении из
модели классов UML?
В14. Дайте пояснение в отношении четырех типов декларативных ограничений ссылочной це
лостности.
В15. Что такое триггер РБД? Как он связан со ссылочной целостностью?
В16. Что такое надлежащий уровень нормализации в РБД? Поясните свой ответ.
В] Упражнения
У1. Телемаркетинг— обратитесь к разбору примера Телемаркетинг, как это определено е.
диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему ОБД. Объясните свое решение по отображению.
У2. Телемаркетинг — обратитесь к разбору примера Телемаркетинг, как это определено в
диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему ОРБД. Объясните свое решение по отображ ению.
УЗ. Телемаркетинг— обратитесь к разбору примера Телемаркетинг, как это определено -т
диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему РБД. Объясните свое решение по отображению
Глава
Проектирование программ
и транзакций
Следует различать проектирование системы и проектирование программы. Про-
ектирование программы относится к той области системного проектирования, кото-
рая связана с моделированием логики выполнения программы и определяет схему
кооперативного взаимодействия объектов применительно к архитектуре клиент-
сервер. Программы ИС выполняют бизнес-транзакции. Транзакция — это логический
элемент базы данных, на который может оказать влияние СУБД при условии, что об-
ласть действия транзакции определена в программе.
Проект программы и транзакции соединяет воедино артефакты системного про-
екта и знаменует собой кульминацию процесса системного проектирования. Он вно-
сит логику приложения в проект GUL-интерфейса и базы данных. Результатом являс г-
ся проектный документ, который содержит достаточно подробные указания для того,
чтобы программисты могли начать “кроить программу”. На самом деле некоторая на-
чальная программа может быть сгенерирована автоматически (прямое конструиро-
вание) на основе проекта. Расширение этой начальной программы, производимое
программистами, можно подвергнуть “реконструкции”, вновь вернувшие!, к проекту и
завершая, таким образом, замкнутый цикл конструирования.
9.1. Проектирование программы
Проектирование программы— неотъемлемая часть проектирования всей системы
(главы 6, 7 и 8). Архитектурное проектирование пакетов классов и компонент устанавлива-
ет исходную схему работы приложения. Детализированное проектирование GUI-
интерфейса и баз данных определяет клиентскую и серверную составляющие этой схе-
мы. Проектирование программы заполняет бреши в начальной схеме и превращает ее в
проектный документ, который можно передать программистам для реализации.
Проектирование концентрируется одновременно на одной программе приложе-
ния. В этом смысле проектирование программы является прямым продолжением про
ектирования пользовательского интерфейса, рассмотренного в главе 7. При проекчпро-
вании программы используется фрагмент (подсхема) проекта базы данных (глава 8) для
362 Глава 9. Проектирование программ и транзакций
определения связанных с ним процедурных аспектов — хранимых процедур и опреде-
ляемых программно триггеров.
Логика выполнения программы разделена между клиентским и серверным про-
цессами. Клиентский процесс реализует большую часть динамики кооперативных взаи-
модействий объектов (разд.6.2), воплощенных в программе. Верный выбор соотно-
шения между связностью и связанностью объектов (разд.9.1.1) может помочь спра-
виться со сложностью этих взаимодействий. Серверный процесс, помимо прочего,
следит за выполнением бизнес-транзакций, инициированных клиентским процессом.
9.1.1. Связность и увязка классов
Мимоходом, в частности в главах 5 и 6, мы определили основные принципы каче-
ственного проектирования программ, правда, по большей части в контексте качест-
венного системного проектирования. Краеугольным камнем создания попятных,
удобных в сопровождении и масштабируемых программ является введение иерархии
классов. Чтобы избежать создания объектно-ориентированных программ, которые ус-
таревают на следующий день после передачи их заказчикам, необходимо правильно
пользоваться такими мощными (в том числе по своей разрушительной силе!) средст-
вами, как наследованием делегирование.
Надлежащее проектирование программы предполагает сбалансированность между
связностью (cohesion) и увязкой (coupling) классов. Термины связность и увязка были вырабо-
таны в рамках методов структурного проектирования. Однако, эти термины имеют похо-
жий смысл и значение и для объектно-ориентированного проектирования [60], [77].
Под связностью классов понимают степень внутреннего самоопределения класса.
Связность является мерой независимости класса. Классы, обладающие сильной связ-
ностью, выполняют одно действие или их функционирование подчинено одной цели.
Чем выше уровень связности, тем лучше.
Под увязкой классов понимают, насколько тесно связаны между собой классы. Увязка
является мерой взаимозависимости классов. Чем ниже уровень увязки, тем лучше
(однако, не следует забывать, что для кооперации классы должны быть “увязаны”!).
Связность и увязка находятся в противоречии друг с другом. Лучшая связность
приводит к ухудшению увязки и наоборот. Задачей конструктора является достиже-
ние их наилучшей сбалансированности. Риль (Riel) [70] предложил несколько эври-
стик, посвященных этой проблеме.
Два класса должны быть либо независимы друг от друга, либо один из классов
должен зависеть только от открытого интерфейса другого класса.
Атрибуты и связанные методы должны находиться в одном классе (эта эвристика
часто нарушается классами, обладающими большим количеством методов
открытия доступа (get, set), определенных в их открытом интерфейсе).
Класс должен охватывать одну и только одну абстракцию. Информация, не имеющая
отношения к данной абстракции, когда подмножество методов работает на
соответствующем подмножестве атрибутов, должна быть перенесена в другой класс.
Системная логика должна быть распределена по возможности равномерно (так,
чтобы классы были равномерно загружены совместной работой).
9.1. Проектирование программы 363
9.1.1.1. Виды увязки классов
Чтобы взаимодействовать, классы должны быть “увязаны”. Между классом X и
классом Y существует увязка, если класс X может непосредственно ссылаться на класс
Y. Пейдж-Джонс (Pagejones) [60] приводит восемь типов увязки классов (которые он
называет набором непосредственных межклассовых ссылок).
1. X наследует от Y.
2. X обладает атрибутом класса Y.
3. X обладает атрибутом шаблона с параметром класса Y.
4. X обладает методом со входным аргументом класса Y.
5. X обладает методом с выходным аргументом класса Y.
6. X осведомлен о глобальной переменной класса Y.
7. X осведомлен о методе, содержащем локальную переменную класса Y.
8. X — класс, дружественный классу Y.
9.1.1.2. Закон Деметра
Увязка классов необходима для взаимодействия объектов, однако, как мы заметили
в разд. 5.2, она должна быть по возможности ограничена рамками уровней иерархии
классов (т.е. сведена к увязке внутри уровня). Межуровневое взаимодействие должно
быть сведено к минимуму и тщательно направляться. Дополнительные руководящие
принципы для ограничения произвольного взаимодействия классов сформулированы
в законе Деметра (Demeter) [50].
Закон Деметра определяет, на что могут быть нацелены сообщения в рамках мето-
дов класса. Он гласит, что целью сообщений может быть только один из перечислен-
ных ниже объектов [60].
1. Объект, в котором определен метод (т.е. в C++ — это this, в Java— self, а в
Smalltalk — super).
2. Объект, который является аргументом сигнатуры метода.
3. Объект, на который ссылается атрибут объекта (включая объект, на который
ссылается один из атрибутов коллекции).
4. Объект, созданный методом.
5. Объект, на который ссылается глобальная переменная.
Для ограничения увязки, вызванной наследованием, можно ограничить третье-
правило атрибутами, определенными в самом классе. Тогда атрибут, унаследованный
классом, не может использоваться для обозначения целевого объекта для сообщения.
Это. ограничение известно как строгое правило Деметра [60].
9.1.1.3. Методы открытия доступа и бессмысленные классы
Как упоминалось в разд. 9.1.1, атрибуты и связанные с ними методы должны нахо-
диться в одном классе [70]. Класс должен сам “решить свою судьбу”. Он может огра-
ничить доступ других классов к своему состоянию за счет запрещения методов откры-
тия доступа в своем интерфейсе. Методы открытия доступа (accessor methods) определя-
ют операции наблюдателя (observer (get)) или мутатора (mutator (set.)) (разд.8.3.1.2).
364 Глава 9. Проектирование программ и транзакций
Методы открытия доступа “открывают” класс для внутренних манипуляций со сто-
роны другого класса. Хотя увязка и подразумевает определенную долю использования
объекта другого класса “в своих интересах”, чрезмерная распространенность методов
открытия доступа может привести к неравномерному распределению
“интеллектуальной” нагрузки на классы. Класс, содержащий слишком много методов,
рискует оказаться бессмысленным — другие классы определяют, что для него “хорошо”.
В свете сказанного становится ясно, что существуют ситуации, когда класс должен
“открыться” другим классам. Это имеет место всякий раз, когда необходимо реализо-
вать некоторую политику (или стратегию) “отношений” между двумя или более клас-
сами [70]. За примером недалеко ходить.
Предположим, что у нас имеется два класса INTEGER и REAL и нам необходимо реа-
лизовать “политику” преобразования целых (integer) чисел в вещественные (real) и на-
оборот. Для этого требуется ответить на некоторые вопросы. В каком из двух классов
должна быть реализована политика? Требуется ли нам специальный класс-
преобразователь CONVERTER для реализации этой политики? В противном случае, по
крайней мере, один из классов должен допускать использование методов открытия дос-
тупа и вследствие этого может стать “бессмысленным” по отношению к этой политике.
Здесь уместно будет привести знаменитое высказывание Пейдж-Джонса: “На объект! ю-
ориентированной ферме и молоко объектно-ориентированное. Значит ли это, что объ-
ектно-ориентированная корова должна отправлять объектно-ориентированному молоку
сообщение uncow_yourself (“освободиться от коровы”), или объектно-ориентиро-
ванное молоко должно отправлять объектно-ориентированной корове сообщение
unmilk_yourself (“избавиться от молока”)” (из выступления Пейдж-Джонса на конфе-
ренции OOPSLA'87).
! В главе 8 мы разработали схему кооперации для части приложения “Запись на универ-
i ситетские курсы" (примеры 6.3 и 6;4 в разд. 6.2.4.1 и Б.2.4.2). Модели кооперации
г обеспечивают относительно равномерное распределение функциональной нагрузки,
j однако, при этом никакие альтернативные решения не рассматривались.
! Предположим, к примеру, что нам необходимо добавить студента в список слушателей
: курса. Для этого следует осуществить две проверки. Во-первых, необходимо выявить,
изучение каких курсов является обязательным условием для прослушивания данного
г курса. Во-вторых, необходимо проверить учебное личное дело студента, чтобы выяс-
j нить, удовлетворяет ли студент этим обязательным условиям. Зная это, мы можем при-
| нять решение, можно ли студента внести в число слушателей курса.
; Предположим, что сообщение enrol () (записать [на предлагаемый курс]) должно от-
f правляться пограничному объекту :Enrolmentwindow. Предположим также, что три
• класса — Courseoffering, Course, и Student (Предлагаемый курс, Курс и Студент)
I кооперируются для выполнения задачи. Наша задача заключается в том, чтобы вырабо-
] тать круг возможных диаграмм кооперации для решения проблемы. Рассмотрите аргу-
: менты за и против различных вариантов решения.
На рис. 9.1 показан первый вариант решения. Пограничный объект
: EnrolmentWindow инициирует транзакцию с помощью отправки сообщения
enroll () объекту aCourse. Объект aCourse запрашивает у объекта aStudent дан-
ные относительно учебного досье и сравнивает их с обязательными условиями. Объ-
ект aCourse решает, может ли объект aStudent быть внесен в список, и дает указа-
ние объекту aCourseOf f ering добавить aStudent в его список студентов.
9.1. Проектирование программы 365
Сценарий, показанный на рис. 9.1, дает слишком много полномочий объекту
aCourse. Объект aCourse становится, так сказать, “вершителем политики”. В этих
условиях роль объекта aStudent лишена смысла. Решение не сбалансировано, одна-
ко, ясного выхода из ситуации не видно.
Можно переместить акценты с объекта aCourse на объект aStudent, в результате
получим решение, показанное на рис. 9.2. Теперь пограничный объект
: Enrolmentwindow требует от объекта aStudent выполнить основную работ'. Объ-
ект aStudent вызывает метод-наблюдатель getPrereq() объекта aCourse. Объект
aStudent решает, возможна ли запись, и дает указание объекту aCourseOffering
записать студента.
Рис. 9.3 является иллюстрацией более сбалансированного решения, при котором
вершителем политики является объект aCourseOffering. Решение
“беспристрастно” по отношению к объектам aCourse и aStudent, но оно делает су-
ществование этих двух объектов довольно бесполезным и бессмысленным. Объект
aCourseOffering действует подобно “главной программе” (по выражению Рисля
(Riel) [70], играет роль класса “Бог”).
Решение, представленное на рис. 9.3, можно улучшить за счет введения управляю-
щего объекта, призванного обрабатывать “политическую информацию” (см. подход
ВСЕ— разд.5.2.4). Управляющий объект :EnrolmentPolicy на рис. 9.4 устраняет
увязку трех классов-сущностей из политики записи на курсы. Это сулит определенные
преимущества, так как любые изменения политики инкапсулированы в пределах од-
ного управляющего класса. Однако, существует риск, что класс Enrolmentpolicy
может вырасти в класс “Бог”.
Рис. 9.1. Объект aCourse в качестве “вершителя по-
литики” (Запись на университетские курсы)
Рис. 9.2. Объект aStudent в качестве “вершителя
политики” (Запись на университетские курсы)
366 Глава 9. Проектирование программ и транзакций
Рис. 9.3. Объект aCourseOffering в качестве “вершителя
политики” (Запись на университетские курсы)
Рис. 9.4. Класс: EnrolmentPolicy в качестве “вершителя
политики” (Запись на университетские курсы)
9.1.1.4. Динамическая классификация и связность классов
со смешанными экземплярами
В разд.2.1.5.2.3 мы поднимали вопрос относительно динамической классификации и
заметили, что наиболее распространенные объектно-ориентированные среды про-
граммирования ее не поддерживают. Цена, которую приходится платить за отсутст-
вие подобной поддержки, зачастую выражается в проектировании классов, которые
отличаются связностью смешанных экземпляров.
Пейдж-Джонс дает следующее определение подобного класса: “Класс со связностьн’
смешанных экземпляров (mixed-instance cohesion) обладает некоторыми свойствами, кото-
рые не определены для некоторых объектов класса”. Некоторые методы класса при
менимы только к подмножеству объектов этого класса, и некоторые атрибуты имею т
смысл только для подмножества объектов.
Например, класс Employee может определять объекты, которые являются как
“обычнььми” работниками, так и менеджерами. Менеджерам выплачивается надбавка. От-
правка сообщения о выплате надбавки payAllowance объекту Employee не имеет смысла,
если этот объект Employee не принадлежит к подмножеству объектов-менедже{юв.
9.1. Проектирование программы 367
Для того, чтобы избавиться от связности смешанных объектов, не требуется рас-
ширять иерархию обобщения для выделения подклассов Employee, таких как
OrdinaryEmployee и Manager. Однако, объект Employee может в один день при-
надлежать категории обычных работников OrdinaryEmployee, а в другой день пе-
рейти в категорию менеджеров Manager или наоборот. Для того, чтобы исключить
связность смешанных объектов, нам требуется разрешить объектам динамически из-
менять принадлежность классу во время выполнения программы — как говорится,
“опять двадцать пять”, если динамическая классификация не поддерживается.
университетские курсы
[ Рассмотрите следующие варианты примера 9.1.
I Посещение вечернего курса возможно только для студентов-вечерников.
j Студенты стационарного обучения могут записываться только на дневные курсы.
j Если студенты-вечерники желают записаться на вечерние курсы, они должны внести
! небольшую дополнительную плату.
I Студенты-вечерники автоматически рассматриваются как студенты стационара, ес-
ли они записываются более, чем на шесть кредитных пунктов (т.е. обычно более, чем
на два предложенных курса) в данном семестре (и наоборот).
Наша задача заключается в том, чтобы предложить сильно связную структурную модель
кооперации без связности смешанных экземпляров. Затем предложенную модель сле-
! дует подвергнуть критической оценке и выдвинуть и обсудить альтернативное решение,
% позволяющее избежать проблем с динамической классификацией.
Чтобы исключить связность смешанных экземпляров, требуется произвести специа-
лизацию класса Student в виде двух подклассов PartTimeStudent (Студент-заочник) и
FullTimeStudent (Студент стационара) (рис. 9.5). Если каждый студент должен быть
отнесен к категории студентов вечерней или дневной формы обучения, класс Student
является абстрактным классом. Сообщение о необходимости внести дополнительную
плату payExtraFee (crs_of f) никогда не отправляется t объекту класса
FullTimeStudent, поскольку FullTimeStudent не содержит методов его обработки.
Рис. 9.5. Структурная схема кооперации, исключающая
связность смешанных экземпляров (Запись на универси-
тетские курсы)
Следует согласиться, что у нас по-прежнему остались проблемы. Студент-вечерник
может отдать предпочтение изучению дневного курса (т.е. evening_preference =
1 False 1), и при этом никакая дополнительная плата не вносится. Другими словами,
368 Глава 9. Проектирование программ и транзакций
для подкласса PartTimeStudent мы по-прежнему сталкиваемся с проблемой связно-
сти смешанных экземпляров. Отправка сообщения payExtraFee (crs_off) объекту
PartTimeStudent не имеет смысла, если студент берет дневной предлагаемый курс.
На рис. 9.6 показано расширение схемы кооперации, позволяющее исключить
второй аспект связности смешанных экземпляров. Для этого введен новый специали-
зированный класс, отражающий существование студентов-вечерников, отдающих
предпочтение прослушиванию дневных курсов обучения. Класс
DayPrefPartTimeStudent не обладает методом payExtraFee (crs_off). Однако,
что делать, если объект DayPrefPartTimeStudent вынужден “брать” предложение
вечернего курса, поскольку на дневном курсе обучения нет свободных мест? Навер-
ное, в этом случае применим какой-то другой вид дополнительной оплаты. Должны ли
мы продолжать развивать нашу специализацию классов, чтобы дойти до производно-
го класса, отражающего существование студентов-вечерников, отдающих предпочте-
ние прослушиванию дневных курсов обучения, которым иё удается попасть на эти
курсы — UnluckyDayPrefPartTimeStudent?
Рис. 9.6. Расширенная структурная схема кооперации, ис-
ключающая еще один аспект связности смешанных экземп-
ляров (Запись на университетские курсы)
Чтобы не оказаться в нелепом положении, следует отказаться от идеи все дальше и
дальше продолжать процесс исключения связности смешанных экземпляров. И
больше мы не станем упоминать динамическую классификацию... В действительно-
сти, текущее значение атрибута current_sem_credit_points определяет, является
лй студент студентом-вечерником или студентом дневной формы обучения.
Аналогично, студент может в любой момент изменить свое предпочтение в отно-
шении вечернего или дневного времени посещения предложенного курса. В отсутст-
вие поддержки динамической классификации со стороны среды программирования
обеспечение возможности для объекта изменить принадлежность классу во время ис-
полнения программы является прерогативой программиста. Это грубый метод —
очень грубый в случае постоянных объектов, значения OID которых содержат иден-
тификаторы класса.
9.1. Проектирование программы 369
Альтернативное решение состоит в том, чтобы ограничить глубину иерархии на-
следования, исключить необходимость динамической классификации и вновь возвра-
титься к наличию определенного уровня связности смешанных экземпляров. Напри-
мер, мы можем настоять на использовании структурной кооперации, схема которой
приведена на рис. 9.5, и решить проблему, связанную с предпочтениями прослушива-
ния курса в вечернее время, позволив объекту по-разному реагировать на сообщение
payExtraFee (crs_of f) в зависимости от значения атрибута evening_pref erence.
Подобное решение можно запрограммировать с помощью оператора if, как показа-
но в приведенном ниже примере псевдокода.
method payExtraFee(crs^off) for the class PartTimeStudent
if evening_preference = OFalseX
return
else
do it
end method
Хотя использование оператора if в объектно-ориентированной программе означает
отказ от наследования и полиморфизма, это может оказаться неизбежным по чисто
прагматическим соображениям. Вместо того, чтобы бороться с динамической классифи-
кацией, программист вводит в класс динамическую семантику. Объект по-разному реагиру-
ет на одно и то же сообщение в зависимости от его локального текущего состояния. Для
проектирования динамической семантики для класса можно использовать диаграммы
состояний. В ходе проектирования, вполне вероятно, пострадает связность класса.
9.1.2. Проектирование клиент-серверных
кооперативных взаимодействий
Чтобы получить доступ к данным программы, ИС взаимодействуют с базами дан-
ных. Для доступа к данным в базе данных и их модификации клиентская программа
должна использовать язык баз данных — обычно SQL. Чтобы понять, каким образом
клиентская программа связывается с сервером баз данных, требуется признать суще-
ствование целого ряда диалектов языка SQL, которые, кроме того, можно использо-
вать на различных уровнях программной абстракции.
На рис. 9.7 показаны пять различных уровней SQL-интефейса. На уровне 1 SQL ис-
пользуется как язык определения данных (data definition language— DDL). DDL —
язык спецификации для определения структур баз данных (схем баз данных). Основ-
ными пользователями языка SQL являются проектировщик и администратор баз дан-
ных (database administrator — DBA).
На уровне 2 SQL используется как язык манипулирования данными (data manipula-
tion language —DML) или язык запросов (query language). Термин язык запросов, однако,
неверен, поскольку SQL на уровне 2 служит не только цели доступа к данным, но и их
модификации (включая операции вставки, обновления и удаления).
SQL уровня 2 применяет широкий круг пользователей, начиная с неискушенных
случайных пользователей и заканчивая опытными DBA. На этом уровне SQL пред-
ставляет собой язык интерактивного взаимодействия, а это означает, что пользователь
может сформировать запрос вне какой-либо среды программирования и немедленно
370 Глава 9. Проектирование программ и транзакций
выполнить его над базой данных. SQL уровня 2 является отправной точкой в изуче-
нии более развитых SQL следующих уровней.
Уровень 1
проектировщик/АБД
•собственный SQL
• Клиентская библиотека БД
• ODBC/JDBC
Уровень 5
проектировщик/
программист
собственный SQL
Клиентская библиотека БД
ODBC/JDBC
4GL/SQL,
генератор приложений
PL/SQL,
хранимые процедуры
Рис. 9.7. Классификация уровней SQL-интерфейса
Прикладные программисты используют SQL уровней выше 2-го. На этих более вы-
соких уровнях SQL позволяет работать в режиме последовательной обработки записей
(record-at-a-time processing) в дополнение к возможностям последовательной обработки набо-
ров записей (set-at-a-time processing) (единственно доступных) на уровне 2. При работе в
режиме последовательной обработки наборов записей СУБД берет в качестве входа
для запроса одну или более таблиц (набор записей) и возвращает в качестве выхода
таблицу. Хотя это довольно мощное средство, использовать его в сложных запросах
не только трудно, но и небезопасно.
Чтобы быть уверенным, что запрос возвращает верный результат, программист
должен иметь возможность просматривать одну за другой записи, возвращаемые как
результат запроса, и принимать решение о том, что делать с каждой отдельной запи-
сью. Подобная возможность последовательной обработки записей, которая называет-
ся курсором (cursor), доступна в SQL уровней выше 2-го.
SQL уровня 3 встроен в традиционный язык программирования, наподобие С или
Cobol. Поскольку компилятор языка программирования не понимает SQL, необходим
предкомпилятор (препроцессор) для трансляции SQL-операторов в вызовы функций
DB-библиотеки, поставляемой изготовителем СУБД. Программист может предпо-
честь программу, непосредственно использующую функции DB-библиотеки, при этом
необходимость в предкомпиляторе отпадает.
Одним из самых распространенных способов обеспечения интерфейса клиент-
ской программы с базами данных является использование стандартов ODBC (Open Da-
tabase Connectivity — открытый интерфейс доступа к базам данных) или JDBC (Java Da-
tabase Connectivity — интерфейс организации доступа Java-приложений к базам дан-
ных). Для программирования с использованием этих интерфейсов требуется
9.1. Проектирование программы 371
программный драйвер ODBC или JDBC для определенной СУБД. Интерфейсы ODBC
и JDBC обеспечивают стандартную надстройку над языком SQL, которая с помощью
драйвера транслируется в “родной” SQL СУБД.
Интерфейсы ODBC/JDBC обладают тем преимуществом, что обеспечивают авто-
номизацию программы от “родного” языка SQL СУБД. Если в будущем требуется пе-
ренесение программы на другую платформу СУБД, в качестве основного приема осу-
ществления этого процесса служит простая замена драйверов. Что более важно, ра-
бота с интерфейсами ODBC/JDBC позволяет одному приложению выдавать запрос
более, чем к одной СУБД,
Недостатком стандартов ODBC/JDBC является то, что они выступают по отноше-
нию к SQL “наименьшим общим знаменателем”. Клиентское приложение не может
воспользоваться никакими преимуществами специальных средств SQL или расшире-
ний, поддерживаемых поставщиком конкретной СУБД.
SQL уровня 4 использует ту же стратегию встраивания SQL в клиентские програм-
мы, что и SQL уровня 3. Однако, SQL уровня 4 обеспечивает более мощную среду про-
граммирования на основе генератора приложений или графического языка четверто-
го поколения (fourth generation language — 4GL). Как правило, язык 4GL поставляется
оснащенным средствами построения экранных изображений конструирования GUI-
интерфейса. Поскольку приложения ИС требуют развитого GUI, для построения по-
добных приложений зачастую выбирают комплект 4GL/SQL.
SQL уровня 5 дополняет SQL уровней 3 и 4, обеспечивая возможность переноса не-
которых SQL-операторов из клиентской программы на активный (программируемый)
сервер баз данных. SQL используется в качестве языка программирования (PL/SQL).
Программы сервера можно вызвать изнутри клиентской программы, как рассматри-
вается далее.
9.1.2.1. Хранимые процедуры
Хранимы# процедуры (storedprocedure) впервые были введены в СУБД Sybase и сейчас
составляют неотъемлемую часть всех основных коммерческих СУБД. Хранимые про-
цедуры превращают базу данных в активную программируемую систему.
Хранимая процедура представляет собой расширение SQL, допускающее такие
конструкции, как переменные, циклы, ветвления и операторы присваивания. Храни-
мые процедуры получают имя, могут принимать входные и выходные параметры, они
компилируются и хранятся в базе данных. Клиентская программа может вызвать хра-
нимую процедуру во многом аналогично тому, как она вызывает подпрограмму.
Рис. 9.8 является иллюстрацией преимуществ вызова клиентской программой хра-
нимой процедуры вместо отправки полного запроса серверу. Запрос, сформирован-
ный в клиентской программе, пересылается серверу по сети. Запрос может содержать
синтаксические ошибки и ошибки других типов, но клиент не в состоянии исключить
их — единственное место, где можно осуществить подобную верификацию, — система
базы данных. После верификации СУБД проверяет, обладает ли вызывающая сторо-
на правами, достаточными для выполнения запроса. Если это так, то запрос оптими-
зируется для определения наилучшего плана доступа к данным. Только после этого
запрос компилируется, выполняется, и результат возвращается клиенту.
С другой стороны, если запрос (или весь набор запросов) написан в виде храни-
мой процедуры, он оптимизируется и компилируется с последующим сохранением на
сервере баз данных. Клиентской программе нет необходимости пересылать (воз-
372 Глава 9. Проектирование программ и транзакций
можно, довольно объемный) запрос по сети — вместо этого она отправляет короткий
вызов, содержащий имя процедуры и список фактических параметров. Если повезет,
процедура может располагаться в кэш-памяти СУБД. Если нет, она переносится в па-
мять из базы данных.
Полномочия пользователя внимательно анализируются так же, как и в случае SQL-
запроса. Все фактические параметры подставляются вместо формальных параметров,
и хранимая процедура выполняется. Результат возвращается вызывающей программе.
Как видно из приведенного выше сценария, хранимые процедуры дают значительно
более эффективный способ доступа к базе данных из клиентской программы. Преиму-
щества в производительности являются следствием экономии сетевого трафика и отсут-
ствия необходимости синтаксического разбора и компиляции всякий раз при получении
клиентского запроса. Что еще более важно, сопровождение хранимой процедуры локализова-
но в единственном месте, а вызываться она может из многих клиентских программ.
SQL-запрос
(из клиентского приложения)
Вызов хранимой процедуры
(из клиентского приложения)
Синтаксический разбор
Расположение процедуры
(возможно в процедурном кзшв)
Проверка синтаксиса
и объектных ссылок
Проверка авторизации
Сервер
баз
данных
Проверка авторизации
Оптимизация
Подстановка параметров
Компиляция
Выполнение
Рис. 9.8. Сравнение вызова из клиентской программы SQL-запроса
и хранимой процедуры
9.1.2.2. Триггеры
Триггеры (разд.8.4.1.4) представляют собой особый вид хранимой процедуры, ко-
торую нельзя вызвать, — они либо запускают себя, либо добавляют (insert), обнов-
ляют (update) или удаляют (delete) события из таблицы. Это значит, что каждой
таблице можно сопоставить до трех триггеров. Конечно, в некоторых системах это
так и есть (например, Sybase). В других системах (например, Oracle) выделяются до-
полнительные варианты событий, что приводит к возможности держать для каждой
таблицы более трех триггеров. (Тем не менее, доступность большего количества ти-
пов триггеров не придает большей выразительной силы триггерным программам).
Триггеры можно программировать для введения некоторых бизнес-правил, которые
применяются к базе данных и не могут быть нарушены ни одной клиентской про-
9.2. Навигация по программе 373
граммой или интерактивным DML-оператором языка SQL. Это означает, что тригге-
ры можно использовать поверх процедурного способа обеспечения ограничений
ссылочной целостности (как было рассмотрено в разд.8.4.1.4). Например, можно соз-
дать триггер, который запретит доступ к базе данных в течение определенных перио-
дов времени или в некоторые дни.
Пользователь клиентского приложения может даже не знать о том, что триггеры
“ожидают”, когда в базе данных произойдут какие-либо модификации. Если модифи-
кации не нарушают бизнес-правил, триггеры невидимы для программ. Триггер
“выказывает” себя пользователю при попытке выполнить недопустимую DML-
команду. Он оповещает пользователя о проблеме, отображая информационное сооб-
щение на экране программы и отказываясь выполнить DML-операцию.
9.2. Навигация по программе
При наличии активной базы данных количество программных объектов возраста-
ет, и кооперативное взаимодействие объектов становится более сложным. Диаграмм
навигации по окнам, используемых в качестве проектного документа, больше недос-
таточно для того, чтобы программист мог взяться за реализацию. Их необходимо
расширить (включить в) до более полных диаграмм навигации по программе.
В рамках UML не существует какой-либо стандартизованной концепции в отноше-
нии программной навигации. Тем не менее, это основополагающая абстракция моделиро-
вания, необходимая для преодоления разрыва между проектом и реализацией системы.
Альтернативой может быть только плохая инженерия программных средств — архитек-
тура илогика программы не документированы и отдаются на откуп программистам.
9.2.1. Стереотипы диаграммы видов деятельности для
навигации по программе
Для преобразования диаграммы навигации по окнам в диаграмму навигации по
программе требуется добавить серверные стереотипы к диаграммам видов деятельно-
сти UML. Необходимо ввести стереотипы как для состояний (прямоугольники со
скругленными углами), так и для видов деятельности (овалы). Стереотипы должны учи-
тывать особенности модели СУБД или даже особенности конкретной СУБД. (Это
может служить основной причиной или, скорее, оправдывает отсутствие диаграмм
навигации в UML).
Для проектирования диаграмм навигации по программам применительно к
РСУБД можно использовать приводимый ниже перечень стереотипов. В зависимости
от уровня абстракции, на котором должны быть сконструированы диаграммы навига-
ции, перечень может сократиться или, наоборот, расшириться за счет дополнитель-
ных объектов.
Состояния (объекты данных)
— База данных
- Реляционная таблица
Столбец
Запись
- Реляционное представление
374 Глава 9. Проектирование программ и транзакций
Столбец
Запись
— Индекс
— Кластер
Виды деятельности (программные объекты)
— Хранимая процедура
- Триггер
Триггер типа On Insert
Триггер типа On Update
Триггер типа On Delete
Другие типы триггеров ...
- Клиентский SQL-запрос
Запрос с использованием собственных средств СУБД
Запрос с использованием DB-библиотеки
Запрос с использованием ODBC/JDBC
9.2.2. Диаграмма навигации по программе
Чтобы проиллюстрировать диаграммы навигации по программе, мы просто рас-
ширим примеры диаграмм навигации по окнам, представленные в разд. 7.6.2. На
рис. 9.9 показана диаграмма навигации по программе, которая расширяет (и несколь-
ко переупорядочивает) диаграмму навигации по окнам, представленную на рис. 7.23.
На рис. 9.9 введены два состояния сервера: Inventory Control (<<database>>)
и Product (<<table>>). Добавлены три вида деятельности сервера: Select
Product («stored procedure>>), Update Product («stored procedure>>) и
On Update Product («trigger»). Мы также добавили клиентский вид деятель-
ности Scroll («scrollbar/keyboard»).
Вместе с добавленной информацией диаграмма навигации по программе, пред-
ставленная на рис. 9.9, информирует программиста о том, что для отображения това-
ров в окне Product Browser необходимо вызвать хранимую процедуру (Select
Product). Эта же хранимая процедура задействуется, когда пользователь осуществля-
ет прокрутку окна броузера вверх и вниз и информационное наполнение окна должно
обновляться из базы данных.
р7 Пример 9.4. Управление контактами с клиентами
Рассмотрите следующие расширения примера 7.5 (разд.7.6.2).
4 Хранимые процедуры используются для модификации мероприятий (операции In-
sert, Delete, Update, Complete).
; Для отслеживания операций Insert и Update над таблицей мероприятий Event ис-
пользуются триггеры.
< Наша задача заключается в проектировании диаграммы навигации по программе для
той части приложения “Управление контактами с клиентами”, которая обрабатывает мо-
; дификацию мероприятий.
9.2. Навигация по программе 375
Рис. 9.9. Диаграмма навигации по программе
В левой части диаграммы можно увидеть, что нажатие кнопки ОК или Save в диа-
логовом окне Update Product (<<dialog Ьох>>) вызывает хранимую процедуру
Update Product (<<stored procedure»). Триггер контролирует результат мо-
дификации данных о товарах (On Update Product).
376 Глава 9. Проектирование программ и транзакций
Наше решение для примера (рис. 9.10) включает только те состояния и виды дея-
тельности клиентской части приложения с рис. 7.24, которые касаются модификации
мероприятий. Заметим, что хранимую процедуру завершения мероприятия Complete
Event можно вызвать либо из главного окна, либо из диалогового окна. Поскольку'
процедура Complete Event обновляет таблицу Event, срабатывает триггер On
Update Event. Тот же триггер может быть активизирован хранимой процедурой со-
хранения информации по мероприятию Save Event.
Диалоговое окно Task/Event Details служит двойной цели введения информа-
ции по новому событию и обновления информации по существующему мероприятию.
Командная кнопка ОК вызывает хранимую процедуру Save Event. Список парамет-
ров вызова сообщает процедуре, означает ли нажатие кнопки ОК операцию вставки
или обновления. Соответственно, выполнение процедуры вызывает срабатывание
одного из двух триггеров: On Insert Event или On Update Event.
Puc. 9.10. Диаграмма навигации no программе (Управление контактами с клиентами)
9.3. Проектирование транзакций
Транзакция— это логическая единица работы, которая состоит из одного или более
операторов SQL, выполняемых пользователем. Транзакция также является единицей
измерения непротиворечивости базы данных— состояние базы данных после завершения
9.3. Проектирование транзакций 377
транзакции непротиворечиво. Для обеспечения этой непротиворечивости использует-
ся программа менеджера транзакций, которая служит двум целям: восстановлению базы
данных (database recovery) и управлению параллельным, выполнением, операций (concurrency
control). (Последний вид управления называется также контролем совпадений или кон-
тролем противоречивых запросов к распределенной базе данных. Прим. ред.).
Согласно стандартам SQL транзакция начинается с первого исполняемого SQL-
оператора (в некоторых системах требуется явный оператор начала транзакции на-
подобие begin transaction). Транзакция завершается операторами commit или
rollback. Оператор commit записывает изменения в базу данных как постоянные.
Оператор rollback стирает любые изменения, произведенные транзакцией.
Транзакция отличается свойством атомарности (atomic) — результат всех SQL-
операторов, содержащихся в транзакции, либо полностью подтверждается (commit),
либо отвергается (rollback). Пользователь определяет продолжительность (длину)
транзакции. В зависимости от характера бизнес-требований, области приложения,
стиля взаимодействия пользователя с компьютером транзакция может быть совсем
короткой, состоящей из одного SQL-оператора, или содержать последовательность
SQL-операторов.
9.3.1. Короткие транзакции
Для большинства традиционных приложений ИС требуются короткие транзакции.
Короткая транзакция содержит один или более SQL-операторов, которые должны быть
выполнены как можно быстрее, так, чтобы не задерживать другие транзакции.
Рассмотрим систему бронирования мест авиакомпании. Несколько туристических
агентств принимают заказы от путешественников на билеты для полетов рейсами
этой авиакомпании по всему миру. Существенным моментом здесь является быстрое
выполнение СУБД каждой транзакции заказа, так чтобы постоянно иметь доступ к
обновленной информации о наличии мест и база данных была готова к обработке
следующей транзакции, ожидающей в очереди.
9.3.1.1. Пессимистическое управление параллельностью
Архитектура традиционных СУБД — ОСУБД составляют здесь заметное исключе-
ние — ориентирована на короткие транзакции. Эти системы работают в соответствии
с алгоритмом пессимистического управления параллельностью (pessimistic concurrency control).
При обработке транзакцией каждого постоянного объекта она запрашивает блокиров
ку (lock). Существует четыре типа блокировок по объектам.
1. Привилегированная блокировка (exclusive lock) (по записи) — другие транзакции
должны ожидать, пока транзакция, удерживающая подобную блокировку, за-
вершится и освободит блокировку.
Я. Блокировка, обновления (update lock) (по возможной записи) — другие транзакции мо-
гут читать объект, однако, транзакции, удерживающей блокировку, гарантиру-
ется возможность выполнить обновление в привилегированном режиме, как
только у нее возникнет в этом потребность.
3. Блокировка чтения (read lock) (с разделением.) — другие транзакции могут читать и,
возможно, получить блокировку обновления по объекту.
378 Глава 9. Проектирование программ и транзакций
4. Отсутствие блокировки (по lock) — другие транзакции могут обновлять объект в
любой момент; подходит только для приложений, допускающих “черновое чте
ниё’, — т.е. транзакция зачитывает данные, которые могут быть модифициро-
ваны или даже удалены (другой транзакцией) до завершения транзакции.
9.3.1.2. Уровни изолированности
Описанным выше четырем типам блокировки соответствуют четыре уровня изояи
рованности (levels ofisolation) (или уровня развязки) между параллельно выполняющимися
транзакциями. Решение о том, какой уровень изолированности подходит для смеси
транзакций на базе данных, является прерогативой системного проектировщика.
Ниже перечислены эти уровни [41].
1. Возможно черновое чтение— транзакция tl модифицировала объект, но еще не
получила подтверждения; транзакция t2 зачитывает объект; если tl осуществ-
ляет откат транзакции, то t2 получает объект, который в известном смысле ни-
когда не существовал в базе данных.
2. Возможно неповторяемое чтение— транзакция tl зачитала объект; t2 обновляет
объект; tl зачитывает тот же объект снова, но в этот момент она получает дру-
гое (по сравнению с первоначальным) значение для того же объекта.
3. Возможно возникновение фантомного объекта — транзакция tl зачитала набор обь-
ектов; t2 вставляет новый объект в набор; tl повторяет операцию чтения и
обнаруживает “объект-фантом”.
4. Повторяемое чтение— транзакции tl и t2 могут продолжать выполнение, но пе-
ремежающееся выполнение этих транзакций даст тот результат, что и их вы-
полнение одна за другой (это называется выполнением, поддающимся сериалиации
(serializable execution)).
Типичное интерактивное приложение ИС, основанное на использовании GUI-
интерфейса, требует коротких транзакций. Однако, уровни изолированности различ-
ных транзакций в одном и том же приложении могут отличаться. Для этой цели можно
использовать SQL-оператор set transaction. Сущность компромисса ясна— увеличе-
ние уровня изолированности ведет к общему снижению уровня параллелизма системы.
Одно из критически важных проектных решений, однако, не зависит от рассмот-
ренных выше вопросов. Начало транзакции всегда должно откладываться до послед
ней секунды. Неприемлемо начать транзакцию из окна клиентской программы, а за-
тем заставлять транзакцию ждать, пока она не получит некоторой дополнительной
информации от пользователя прежде, чем сможет фактически завершить работу.
Пользователь при предоставлении этой информации может выказать чрезмерную
медлительность или решить отключить компьютер, хотя транзакция продолжает вы-
полняться. Перерыв в транзакции в конце концов приведет к откату транзакции, по это
успеет негативно отразиться на общей производительности системы.
9.3.1.3. Автоматическое восстановление
Закон Мерфи гласит, что если что-то может испортиться, то оно испортится. Про
граммы могут содержать ошибки, выполняющийся процесс может зависнуть или бы ть
прекращен, электропитание может дать сбой, головки диска могут поломаться и т.д. К
счастью, в большинстве ситуаций СУБД имеет возможность обеспечить автоматиче-
ское восстановление системы после отказа. Только в случае физической утраты данных
9.3. Проектирование транзакций 379
на диске требуется вмешательство АБД, чтобы дать указание СУБД о восстановлении
данных с помощью последней резервной копии базы данных.
В зависимости от состояния транзакции в момент отказа СУБД автоматически вы-
полняет откат (rollback) или повтор всех завершенных операций (roll forward) транзакции
сразу после устранения причин возникшей проблемы. Восстановление осуществляет-
ся автоматически, однако, АБД может контролировать время, необходимое на вос-
становление, за счет установления частоты контрольных точек. Контрольная точка
(checkpoint) — это процедура, которая заставляет СУБД временно приостановить все
транзакции и записать все изменения, произведенные транзакциями (с момента за-
пуска предыдущей контрольной точки) над базой данных.
На рис. 9.11 показаны основные моменты, связанные с автоматическим восста-
новлением системы после отказа [43]. Транзакция tl подтверждена после прохожде-
ния контрольной точки, но до отказа системы. Поскольку СУБД не известно, были ли
физически записаны все изменения после контрольной точки в базу данных, она по-
вторяет все завершенные операции транзакции tl после восстановления системы.
К транзакции t2 применяется откат между контрольной точкой и отказом. Как и в
случае транзакции tl, СУБД не известно, достигли ли диска изменения, связанные с
откатом, — СУБД вновь выполняет откат.
подтверждение
откат
ч
•о подтверждение
£------------1
Г4 откат
точка контроля отказ
Рис. 9.11. Автоматическое восстановление
Остальные транзакции стартуют после контрольной точки. Для транзакции t3
вновь повторяются все завершенные операции, чтобы убедиться, что произведенные
ею изменения достигли базы данных. Аналогично транзакция t4 повторяется, т.е. для
нее выполняется откат.
Транзакция t5 может не требовать никаких корректирующих действий со сторо-
ны СУБД, поскольку она выполнялась во время отказа. Любые изменения, произве-
денные транзакцией t5 до отказа, не были записаны в базу данных. Все промежуточ-
ные изменения были записаны только в файл журнала. Пользователь поставлен в из-
вестность о том, что транзакция выполнялась во время отказа, и может перезапустить
транзакцию после того, как СУБД восстановится и вновь начнет функционировать.
380 Глава 9. Проектирование программ и транзакций
9.3.1.4. Программируемое восстановление
Хотя после непредвиденных отказов системы СУБД выполняет автоматическое
восстановление, проектировщики и программисты должны контролировать и про-
гнозировать проблемы, связанные с транзакциями. СУБД обеспечивает набор воз-
можностей по откату, которые можно задействовать программным способом, так что
проблемы восстановления могут быть решены довольно изящно, при этом пользова-
тель, возможно, даже не заметит, что в некоторый момент дела пошли не так.
Для начала заметим, что принципы разработки GUI-интерфейса, такие как кон-
троль на стороне пользователя или терпимость к ошибкам (разд.7.3), требуют, чтобы
программа позволяла пользователям совершать ошибки и была способна обеспечить
восстановление системы. Откат, контролируемый программистом и применяемый в
нужном месте программы, может восстановить предыдущее состояние базы данных
(т.е. отменить ошибочные действия) при условии, что транзакция не подтверждена.
Если транзакция подтверждена, у программиста все еще остается возможность на-
писать компенсирующую транзакцию (compensating transaction). Впоследствии пользова-
тель может потребовать выполнения компенсирующей транзакции для отмены изме-
нений в базе данных. Компенсирующие транзакции проектируются специально для
того, чтобы разрешить программируемое восстановление, и должны быть отражены
в моделях прецедентов.
9.3.1.4.1. Точка сохранения
Точка сохранения (savepoint) — это оператор программы, который делит длинную
транзакцию на более короткие части. Именованная точка, сохранения помещается в
стратегически важных пунктах программы. Впоследствии программист имеет воз-
можность осуществить откат выполненной работы к точке сохранения, а не к началу
транзакции.
Например, программист может поместить точку сохранения прямо перед опера-
цией update. Если операция update завершилась неуспешно, программа выполняет
откат к точке сохранения и пытается повторить обновление. Вместо этого программа
может предпринять любые другие действия, чтобы избежать полного аварийного
прекращения транзакции.
В программах большого объема точки сохранения можно помещать перед каждой
подпрограммой. Если подпрограмма отказывает, имеется возможность осуществить
откат к началу подпрограммы и повторить ее выполнение с исправленными парамет-
рами. При необходимости специально спроектированные и запрограммированные
подпрограммы восстановления могут выполнить очистку, так что транзакция может
возобновить выполнение.
9.3.1.4.2. Триггерный откат
Триггерный откат (trigger rollback) представляет собой особый вид точки сохране-
ния. Как объяснялось в разд.9.1.2.2, триггер можно использовать для программирова-
ния бизнес-правил любой сложности. В некоторых случаях откат всей транзакции не-
приемлем, когда триггер отказывается модифицировать таблицу (из-за того, что
транзакция пытается нарушить бизнес-правило). Транзакции может потребоваться
предпринять корректирующие действия.
9.3. Проектирование транзакций 381
Вследствие приведенных выше причин СУБД может обеспечить возможности
программирования триггера для отката либо всей транзакции, либо только триггера.
В последнем случае программа (возможно, хранимая процедура) может проанализи-
ровать проблему и принять решение о дальнейших действиях. Даже если необходимо
постепенно свернуть всю транзакцию, программа будет иметь возможность более
тщательной интерпретации причины ошибки и отображения более осмысленного
сообщения для пользователя.
9.3.1.5. Проектирование хранимых процедур и триггеров
Диаграмму навигации по программе (разд.9.2.2) можно расширить таким образом,
чтобы включить в нее состояния транзакции. Это может быть довольно обременитель-
но с точки зрения графической схемы. В качестве альтернативного решения можно
разработать несколько диаграмм навигации по программе, каждая представляет оп-
ределенный аспект навигации. Один из таких аспектов может быть посвящен фикси-
рованию навигации в “среде” транзакций.
В любом случае диаграммы навигации по программе идентифицируют хранимые
процедуры и триггеры. При этом необходимо отразить информацию, касающуюся
цели, определения и детализированного проекта для каждой хранимой процедуры и
триггера. В частности, для определения алгоритмов можно было бы применить нота-
цию некоторого псевдокода.
В качестве примера ниже приводится алгоритм для хранимой процедуры
DeleteEvent приложения “Управление контактами с клиентами” (см рис. 9.10,
разд.9.2.2). Процедура проверяет, является ли пользователь (работник), который пы-
тается удалить информацию по мероприятию, также и создателем этой информации.
Если это не так, операция удаления отклоняется. Процедура также проверяет, являет-
ся ли мероприятие единственным оставшимся мероприятием для данного задания.
Если это так, то задание также удаляется.
BEGIN
INPUT PARAMETERS (@event_id, @user_id)
Select Event (where event_id = @event_id)
IF @user_id = Event.created_emp_id
THEN
delete Event (where event_id = @event_id)
IF no more events for
Task.task_id = Event.task_id AND
Event.event_id = @event_id
THEN
delete that Task
ENDIF
ELSE
raise error (’Only the creator of the event can
delete that event')
ENDIF
END
382 Глава 9. Проектирование программ и транзакций
Хранимая процедура DeleteEvent содержит операторы delete для удаления за-
писей из таблиц Event и Task. Данные операторы delete должны запускать тригге-
ры удаления на этих таблицах, если они существуют. Если алгоритм для этих тригге-
ров выходит за пределы обычной проверки ссылочной целостности, проектировщик
также должен предоставить для них спецификацию псевдокода (включая решение по
стратегии отката — триггерный откат или откат транзакции).
9.3.2. Длинные транзакции
Некоторые новые классы приложений ИС поощряют кооперативные взаимодей-
ствия между пользователями. Эти приложения известны как приложения вычислений
для рабочих групп (workgroup computing) или приложения совместной работы, поддерживае-
мой компьютером (computer-supported cooperative work - CSCW). В качестве примеров можно
привести многие офисные приложения, системы творческой кооперации, системы
автоматизированного проектирования, CASE-системы и т.д.
Во многих отношениях приложения для рабочих групп выдвигают требования к
базам данных, которые являются ортогональными по отношению к традиционным
моделям баз данных. Последние отличаются короткими транзакциями и изолируют
пользователей друг от друга. Приложения для рабочих групп требуют длинных тран-
закций, управления версиями, управления кооперативной параллельностью и т.д.
Модель ОБД дает схему групповых вычислений, и многие продукты ОСУБД нацелены
именно на эту область приложений. Пользователи, работающие с приложениями для ра-
бочих групп, совместно используют информацию и осведомлены о работах, выполняемых
ими над разделяемыми данными. Они работают в рамках собственной рабочей среды, ис-
пользуя персональные базы данных, включающие данные, выбранные (скопированные) из
общей базы данных рабочей группы; работают с длинными транзакциями, которые могул
занимать несколько сеансов работы с компьютером (пользователь может прерваться, за-
тем возвратиться и продолжить работу с той же длинной транзакщ left).
Отличительно^ чертой длинной транзакции является то, что для нее недопус тим
автоматический откат вследствие отказов без отслеживания системой хода транзак-
ции. Чтобы понять это требование, представьте мое отчаяние, если бы для этого
учебника сейчас был произведен “откат” из-за компьютерного сбоя! Откат для длин-
ных транзакций контролируется пользователями с помощью процедур точек (охране
ния, которые постоянно сохраняют объекты в личной базе данных пользователя.
Понятие короткой транзакции не исчезло из сферы приложений для рабочих
групп. Короткие транзакции необходимы для обеспечения атомарности и изолиро-
ванности во время операций извлечения данных из групповой базы данных в личную
базу и возврата данных (после их обработки в собственной рабочей среде) из личной
базы данных в общую базу данных. После выполнения описанных коротких транзак-
ций короткие блокировки освобождаются, а групповая база данных накладывает длинные
постоянные блокировки на все извлеченные из нее объекты.
Модель длинных транзакций включает несколько взаимосвязанных целей, среди
которых можно, в частности, выделить следующие [35], [52].
Обеспечение обмена информацией (даже если она является временно
противоречивой) между сотрудничающими пользователями.
Обнаружение противоречий в данных и их согласованное разрешение.
9.4. Замкнутое конструирование 383
Использование преимуществ поддержки множества версий объектов для
обеспечения управляемого совместного использования информации без потери
результатов работы в случае отказа системы.
9.4. Замкнутое конструирование
Итеративный и наращиваемый процесс (разд. 1.1.3.1) современного производства
ПО требует четкой поддержки замкнутого конструирования, осуществляемого цикли-
чески между проектированием и реализацией. Замкнутое конструирование (round-trip
engineering) определяется как сближение направленной вперед генерации программного
кода и обратного конструирования, направленного от анализа программного кода к мо-
делям проектирования. Замкнутое конструирование дает “...возможность работать как с
графическим, так и с текстовым представлением, в то время как инструментальные
средства поддерживают непротиворечивость обоих представлений” [8].
В случае приложений клиент-сервер замкнутое конструирование применяется по от-
дельности к клиентским прикладным программам и серверным программам баз данных.
Возможно и, конечно, желательно применение различных CASE-средств для проекти-
рования клиентской и серверной частей одного и того же проекта. Кроме того, CASE-
средства, применяемые для замкнутого конструирования, должны быть тесно интегри-
рованы с конкретной клиентской и серверной средами программирования.
9.4.1. Замкнутое конструирование для клиентских
программ
Принципы замкнутого конструирования для клиентских приложений относительно про-
сты — “дьявол кроется в деталях". На рис. 9.12 представлена диаграмма видов деятельно-
сти для типичного цикла замкнутого конструирования с использованием объектного
языка программирования [61], [68]. UML-модели хранятся в CASE-репозитории (как
мимоходом было объяснено, CASE-репозиторий представляет собой системы баз дан-
ных, часто — объектную базу данных).
Проектная UML-модель (UML-состояние) должна быть специально разработана
с ориентацией на язык программирования. Генерация кода (вид деятельности
UML) использует Проектную UML-модель для генерации Исходного кода (файлов
заголовков и реализации). Любые поддерживаемые пользователем определения и
вспомогательные объявления, внесенные на предыдущих итерациях замкнутого кон-
струирования, подлежат сохранению.
Исходный код позже подвергается обычным для программы изменениям и рас-
ширениям. Модифицированный код подвергается процедуре реинжиниринга, ре-
зультат которой представлен в виде UML-модели реализации. Вид деятельности, со-
ответствующий процедуре реинжиниринга, на рис. 9.12 обозначен как Генерация
UML.' Для выявления изменений в проекте с помощью сравнения текущей UML-модели
реализации и последней Проектной UML-модели используется некоторый вид ин-
струментального средства под названием Различение моделей. Все принятые изме-
нения распространяются на Проектную UML-модель, после чего возможно начинать
следующую итерацию замкнутого конструирования.
Как мы заметили выше, “дьявол кроется в деталях”. На практике многие связующие
звенья между “пониманием” языка программирования CASE-средствами и реалиями
конкретного компилятора для этого языка зачастую оказываются утерянными. CASE-
384 Глава 9. Проектирование программ и транзакций
средство может сообщить о наличии ошибок в чисто скомпилированном коде, посколь-
ку оно не распознает нюансов, характерных для конкретной версии компилятора.
Рис. 9.12. Замкнутое конструирование в случае клиентской программы
CASE-средство может оказаться не в состоянии разрешить некоторые ссылки на
объявления в зависимых от компилятора или библиотеки исходных файлах. Напри-
мер, ссылки могут быть неразрешимы, если исходный файл ссылается на символы,
определенные в другом файле и явно не включенные в данный файл. Хотя для подоб-
ных проблем и могут существовать обходные пути, они неизменно приводят к неиде-
альным решениям, требующим ручной корректировки.
Указанные трудности не означают, что от проведения замкнутого конструирова-
ния для клиентских программ следует вообще отказаться. Недоработки можно откор-
ректировать вручную, и уже откорректированные UML-модели дают разработчикам
надлежащую документацию для текущей версии программы. Альтернативой является
полная потеря контроля над реализацией приложения.
9.4.2. Замкнутое конструирование для баз данных
В процессе замкнутого конструирования для баз данных [53] со стороны проекта
участвует физическая модель данных (ФМД) (physical data model— PDM), a co стороны реа-
лизации — база данных (БД}. Модель используется вместо UML-модели, поскольку'
UML не поддерживает физического проектирования баз данных (разд.8.4). Физиче-
ская модель данных должна быть ориентирована на конкретную СУБД.
На рис. 9.13 представлена диаграмма видов деятельности для замкнутого конструиро-
вания реляционной базы данных. После построения ФМД для базы данных (состояние
Начальная ФМД) ее можно поместить в архив (вид деятельности Архив). Сравнение ар-
хивной и текущей ФМД позволяет зафиксировать последние изменения в модели.
Прямое конструирование модели Начальная БД на основе модели Начальная
ФМД осуществляется с помощью вида деятельности Создание БД. В результате этой
деятельности генерируется схема БД, включая триггеры. Начальная БД заполняется
данными с помощью рекурсивного вида деятельности Загрузка. Вид деятельности
Модификация БД вводит изменения в схему и вызывает переход базы данных в со-
стояние Текущая БД.
9.4. Замкнутое конструирование 385
Рис. 9.13. Замкнутое конструирование в случае базы данных
Рис. 9.14. Экран сеанса реинжиниринга по преобразованию БД Sybase в ФМД PowerDesigner
На этом этапе существуют две возможности: изменения в Текущей ФМД могут быть
синхронизированы с Текущей БД (вид деятельности Синхронизировать ФМД с БД) или
386 Глава 9. Проектирование программ и транзакций
наоборот—изменения в Текущей БД могут быть синхронизированы с Текущей ФМД (вид
деятельности Синхронизировать БД с ФМД). В результате этих видов деятельности мо-
жет потребоваться перенести в архив Текущую PDM, а Текущую БД перегрузить.
На рис. 9.14 показан один из экранов сеанса реинжиниринга (вид деятельности
Синхронизировать с БД) Текущей БД (Sybase), в результате которого мы получа-
ем Текущую ФМД (PowerDesigner).
В процессе замкнутого конструирования баз данных необходимо учитывать при-
веденные ниже факторы [53].
Архивирование и поддержка версий ФМД может осуществляться с
использованием CASE-средств, однако, типичная РСУБД или ОРСУБД не обладает
встроенными возможностями поддержки версий БД (отличных от простого
создания новой БД).
После генерации начальной схемы БД база загружается данными, и начинается
программирование серверной программы. Программистам необходима возможность
модифицировать (или требовать модификации) схемы БД по мере того, как
модификации постепенно синхронизируются с текущей моделью ФМД. Вид деятельно-
сти Синхронизировать ФМД с БД должен полностью выполняться во время
синхронизации, после чего должно осуществляться архивирование PDM-модели.
Любые последующие изменения в архивной PDM-модели, которые требуют
синхронизации с БД, должны быть внесены методом прямого конструирования в
новый экземпляр БД (при отсутствии версий БД).
9.4.3. Реинжиниринг реляционных баз данных
в объектно-реляционные
В главе 8 упоминалось о том, что следующее поколение технологий баз данных
должно основываться на модели ОРБД. Поэтому следует ожидать возрастания по-
требности в переносе существующих (унаследованных) реляионных баз данных на
объектно-ориентированные платформы. Реинжиниринг (reengineering) — это процесс,
направленный на изучение и изменение унаследованной системы для реконструкции
ее проекта и ее повторной реализации в новом виде.
Реинжиниринг и замкнутое конструирование разделяют технологии прямой и об
ратной разработки. Разница заключается в том, что замкнутое конструирование свя-
зано с эволюционным развитием новой системы. Реинжиниринг предшествует замкну-
тому конструированию и связан с получением начальной ФМД в результате изучения
унаследованного программного кода.
Сегодня большинство проектов по реинжинирингу направлены на то, чтобы пе-
реориентировать устаревшие системы на основе языка COBOL на технологию реля-
ционных баз данных. В будущем роль унаследованных систем перейдет к реляцион-
ным базам данных, которые на основе реинжиниринга будут превращаться в решения
на основе ОРБД или ОБД. Однако, рынок чистых ОБД вряд ли будет расти так же бы-
стро, как рынок ОРБД — отчасти из-за естественной инерции в переходе к совершен-
но новым технологиям, а отчасти из-за того, что ОСУБД обращены прежде всего к
рыночной нише систем мультимедиа и кооперативной обработки.
На рис. 9.15 представлена диаграмма, отображающая последовательность видов
деятельности в процессе реинжиниринга, целью которого является переход от сис-
9.4. Замкнутое конструирование 387
темы РБД к системе ОРБД. Здесь также показан последовательный процесс замкнуто-
го конструирования ОРБД.
Модификация модели
для ОРБД
Рис. 9.15. Реинжиниринг реляционной базы данных в объектнореляционную
Выполняется анализ Реализации существующей РБД (вид деятельности Анализ
РБД) для определения структур базы данных, бизнес-правил и логики прикладных
программ. Анализ приводит к построению проектной UML-модели, которая отражает
текущее состояние существующей (унаследованной) реализации РБД. UML-модель за-
тем модифицируется для Реализации ОРБД.
Теперь можно сгенерировать схему ОРБД, триггеры и методы (процедуры) и за-
грузить ОРБД данными. Для ОРБД создаются и тестируются прикладные программы.
Это неизбежно приводит к изменениям в ОРБД, которые требуется отразить в про-
ектной UML-модели. После этого можно сказать, что изменения подверглись реин-
жинирингу и первая итерация замкнутого конструирования завершена.
Процесс конструирования и замкнутого конструирования объектно-реляционных
баз данных сталкивается с двумя основными проблемами. Первая касается аспектов
замкнутого конструирования, а вторая связана с выразительными возможностями моде-
лей UML.
Переход от проектах моделей UML к реализациям ОРБД в процессе замкнутого
конструирования аналогичен замкнутому проектированию для реляционной базы
данных, как было рассмотрено в предыдущем разделе. Несмотря на аналогию, осно-
вополагающие технические вопросы для ОРБД значительно более трудны. Это связа-
но с тем, что модель ОРБД более сложна и семантически более богата, чем модель
РБД (глава 8). Начнем с того, что CASE-средства должны быть ориентированы на но-
вый стандарт SQL 1999 и “понимали” различные варианты SQL 1999 применительно к
коммерческим ОРСУБД.
Так же, как в случае модели РБД, рассчитывать на поддержку возможностей ФМД
для систем ОРБД особенно не приходится. UML — это преимущественно язык анализа
систем. Существуют профили UML, предназначенные для моделирования систем
[56], однако, они не обеспечивают возможностей детализированного конструирова-
ния, связанных с пониманием всех нюансов ОРСУБД, включая нюансы, относящиеся
к различным версиям одной и той же ОРСУБД.
388 Глава 9. Проектирование программ и транзакций
Например, СУБД Oracle 8 использует объектные представления для облегчения
перехода от реляционной к объектно-реляционной базе данных. Подобно другим
объектам ОРБД, объектное представление может быть обозначено как класс-
стереотип и ему, возможно, может быть присвоена собственная графическая пикто-
грамма. Безусловно стереотипному классу должна быть придана собственная точная
семантика, так что CASE-средство может понять любые ограничения и возможности,
связанные со стереотипным классом (например, какие типы отношений и других свя-
зей допустимы между стереотипным классом и любым другим класом модели). Низко-
уровневые CASE-средства от компании Oracle (в данном случае) имеют значительно
больше шансов помочь правильно решить подобные вопросы, чем исходный язык
UML наряду со стереотипами.
Резюме
В этой главе мы остановились на некоторых более внутренних концепциях проек-
тирования программ и транзакций и описали проектную деятельность, которая ле-
жит на линии перехода между проектированием и реализацией. Были рассмотрены
диаграммы навигации по программе. Мы также объяснили подход к замкнутому кон-
струированию клиентских программ и серверных программ баз данных.
Программа, спроектированная надлежащим образом, отличается высоким уров-
нем связности классов при низком уровне увязки классов. Этого требования в отношении
связности и увязки можно достичь, если проект подчиняется закону Деметра, который
определяет допустимые целевые объекты для сообщений в рамках методов классов.
Чрезмерное использование методов открытия доступа может привести к появлению
“бессмысленных классов”. Хотя связность смешанных экземпляров и представляется нежела-
тельным явлением, иногда она все же допустима, поскольку среды программирования
не поддерживают динамическую классификацию.
При разработке кооперации клиент-сервер необходимо принимать во внима-
ние существование пяти уровней SQL-интерфейсов. Особый интерес представляет
SQL уровня 5, поскольку позволяет пользователю непосредственно программиро-
вать базу данных. Хранимые процедуры и триггеры оказывают существенное влия-
ние на серверный аспект проектирования программы. Диаграммы навигации по
программе расширяют диаграммы навигации по окнам, позволяя учитывать нали-
чие базы данных.
Транзакция — это единица работы базы данных, которая начинается, когда ба-
за данных находится в непротиворечивом состоянии, и по завершении которой
база данных гарантированно окажется в непротиворечивом состоянии. Транзак-
ции обеспечивают возможности по реализации параллелизма и восстанавливае-
мости баз данных. Традиционные приложения баз данных требуют коротких
транзакций. Некоторые новые приложения баз данных работают с длинными
транзакциями.
Замкнутое конструирование— это процесс, при котором проектные модели и про-
граммы синхронизированы, однако могут развиваться самостоятельно. Замкнутое
конструирование определяется как сочетание направленной вперед генерации про-
граммного кода и обратного конструирования, направленного от анализа программ-
ного кода к моделям проектирования. Обычно замкнутое конструирование применя-
ется по отдельности к клиентским программам и программам баз данных.
Вопросы 389
[М] Вопросы
В1. Какое влияние на проектирование оказывают принципы, связанные со связностью и увязкой?
В2. Какие объекты могут выступать в качестве целевых объектов для сообщений согласно за-
кону Деметра?
ВЗ. Что такое “бессмысленный класс”?
В4. Объясните связь между динамической классификацией и связностью смешанных экземпляров.
В5. Кратко опишите пять уровней SQL-интерфейсов.
В6. В чем преимущество вызова из клиентской программы хранимой процедуры в сравнении с
SQL-запросом, пересылаемым базе данных? Существуют ли ситуации, при которых мы
вынуждены использовать SQL-запрос вместо вызова удаленной процедуры?
В7. Перечислите основные серверные объекты, моделируемые как состояния и виды деятель-
ности диаграмм навигации по программе.
В8. Кратко опишите виды блокировок при пессимистическом управлении параллельностью.
В9. Кратко опишите уровни изолированности транзакций.
В10. Может ли проектировщик или АБД управлять продолжительностью восстановления базы
данных? Объясните ваш ответ.
В11. Что такое компенсирующая транзакция? Как ее можно использовать при проектировании
программы?
В12. Что такое точка сохранения? Как ее можно использовать при проектировании программы?
В13. В чем заключается функция дифференцирования модели при замкнутом конструировании
клиентской программы?
В14. У традиционных баз данных отсутствуют встроенные возможности поддержки версий базы
данных. Как это влияет на замкнутое конструирование программ для подобных баз данных?
В| Упражнения
У1. Телемаркетинг—обратитесь к разбору примера “Телемаркетинг”, как это определено в
диаграмме видов деятельности для книги, и к решению примера У4 в главе 7.
Расширьте диаграмму навигации по окнам для приложения “Телемаркетинг” до диаграм-
мы навигации по программе. Если решение оказывается слишком сложным, разделите
диаграмму на несколько меньших диаграмм. Объясните, каким образом предложенное
вами решение удовлетворяет требования к приложению.
У2. Управление контактами с клиентами — обратитесь к решениям примера “Управление кон-
тактами с клиентами”, как это определено в диаграмме видов деятельности для книги. В
частности, рассмотрите диаграмму навигации по окнам в примере 7.5 (разд.7.6.2).
Идентифицируйте хранимые процедуры, триггеры и другие объекты базы данных (которые до
сих пор не идентифицированы), необходимые для системы управления контактами с клиентами.
Тестирование и управление
изменениями
Тестирование и управление изменениями — это не отдельные этапы ЖЦ разра-
ботки ПО — они охватывают весь жизненный цикл. Тестирование — это совсем не от-
ладка программ. Артефакты разработки каждого этапа ЖЦ должны быть протестиро-
ваны. Аналогично, понятие управления изменениями применимо не только в отно-
шении усовершенствований, требуемых заказчиками, или ошибок, обнаруженных в
ходе тестирования. Управление изменениями представляет собой фундаментальный
аспект управления проектом в целом — запросы на изменения должны быть докумен-
тированы, а влияние каждого изменения на артефакты разработки должно отслежи-
ваться и перепроверяться после их реализации. В основе тестирования и управления
изменениями лежит понятие прослеживаемости. Прослеживаемость обеспечивает
фиксацию, связь и отслеживание всех важных артефактов разработки, включая тре-
бования. Конечная цель прослеживаемости — дать возможность выработать полную
документацию на систему, которая является заведомо корректной и непротиворечи-
вой применительно к различным документам и моделям, начиная с требований и за-
канчивая технической и пользовательской документацией. Элементами прослежи-
ваемости могут быть текстовые и графические модели. Прослеживаемость устанавли-
вает явные связи между элементами прослеживаемости. Связи могут быть прямыми и
косвенными. Они позволяют проводить анализ последствий при изменении любого
элемента, находящегося на пути прослеживаемости. Ранее в этой книге мы провели
различие между системными услугами и системными ограничениями.
Прослеживаемость, тестирование и управление изменениями часто ассоциируют-
ся с системными услугами, которые заявляют о себе в требованиях, выражаемых пре-
цедентами. Однако, не следует забывать о необходимости отслеживания того, как вы-
держиваются системные ограничения, и, соответственно, тестирования и управления
их изменениями.
10.1. Тестирование системных сервисов
Скэч (Schach) [77] проводит различие между неформальным и методическим тес-
тированием системных сервисов. Каждый разработчик выполняет неформальное тес-
тирование при моделировании или реализации системных сервисов. По своему харак-
10.1. Тестирование системных сервисов 391
теру неформальное тестирование несовершенно. Тот, кто разрабатывает сервис, ме-
нее всего заинтересован в том, чтобы в программе, реализующей этот сервис, были
обнаружены ошибки.
Значение неформального тестирования незначительно, и оно должно быть до-
полнено методическим тестированием. Существует два основных вида методического
тестирования [77].
1. Тестирование без выполнения программы (формальные пересмотры) (formal
reviews)
— Сквозной контроль
— Инспекция
2. Тестирование, основанное на выполнении программы
- Тестирование по спецификации
— Тестирование по программному коду
10.1.1. Сквозной контроль
Сквозной контроль (walkthrough) представляет собой один из видов формального пе-
ресмотра артефактов методом “мозгового штурма”, который может проводиться на
любом этапе разработки. Это дружественная встреча разработчиков, тщательно
спланированная, с ясно определенными целями, повесткой дня, продолжительно-
стью и составом участников. Многие бригады ИТ-разработчиков проводят сквозной
контроль еженедельно. За несколько дней до совещания по сквозному контролю участникам
раздаются материалы (описания моделей, документы, программы и т.д.), которые
подлежат пересмотру на совещании. Материалы участникам собирает и раздает моде-
ратор сквозного контроля. Участники изучают материалы и передают модератору
свои замечания еще до начала совещания. Само совещание относительно непродол-
жительно (самое большее два-три часа). Во время совещания модератор представляет
замечания и открывает обсуждение по каждому вопросу. Цель освещения состоит в
том, чтобы уточнить проблему, а не выводить разработчиков “на чистую воду”! Разра-
ботчик, который стоит за проблемой, в данном случае не важен и может вообще оста-
ваться неизвестным (хотя обычно это не так). Общая идея состоит в том, чтобы под-
твердить существование проблемы. При этом не следует предпринимать попыток
решить проблему. О полезности и эффективности сквозного контроля свидетельст-
вуют многие факты. Он придает процессу разработки четкость и профессионализм,
вносит существенный вклад в достижение высокой продуктивности и способствует
выполнению работы в срок, имеет очень важное значение с точки зрения информи-
рованности участников проекта и, в конечном итоге, позволяет повысить качество
разрабатываемого ПО.
10.1.2. Инспекция
Подобно сквозному контролю инспекция (inspection) представляет собой совещание,
проводимое в дружелюбном духе, но под пристальным наблюдением со стороны ру-
ководства проекта. Ее целью также является выявление дефектов, подтверждение то-
го, что они действительно являются дефектами, их фиксация и назначение сроков их
устранения и лиц, ответственных за это.
392 Глава 10. Тестирование и управление изменениями
В отличие от сквозного контроля инспекции проводятся не так часто, могут быть
посвящены только отдельным, имеющим критическое значение, вопросам и носят
более формальный и более строгий характер. Инспекция организована в виде не-
скольких этапов. Она начинается с этапа планирования, на котором определяются уча-
стники инспекции и целевая область инспектирования.
До начала инспекционного заседания необходимо провести короткое информаци-
онное совещание. Во время информационного совещания разработчик, продукт которо-
го подлежит инспектированию, вводит участников в курс дела. Инспекционные мате-
риалы раздаются участникам во время или перед информационным совещанием.
Информационное совещание обычно проводится за неделю до инспекционного сове-
щания. Это дает инспекционной бригаде время изучить материалы и подготовиться к
совещанию. Во время совещания дефекты идентифицируются, фиксируются и нуме-
руются. Сразу после совещания модератор готовит журнал дефектов — в идеале он ве-
дется с использованием средств управления изменениями, связанными с проектом.
Обычно от разработчика требуется быстро решить проблемы, связанные с дефек-
тами, и зафиксировать принятое решение с помощью средств управления измене-
ниями. Модератор должен проверить отчет об устранении дефекта и решить, требу-
ется ли повторное инспектирование. В случае если он удовлетворен решением пробле-
мы, модератор, проконсультировавшись с руководителем проекта, направляет
разрабатываемый модуль группе обеспечения качества ПО (Software Quality Assurance—
SQA) организации (если такая группа существует).
Группа SQA должна состоять из лучших специалистов, имеющихся в организации.
Группа никак не должна быть связана с проектом за исключением своей роли по
обеспечению качества. Группа (а не истинные разработчики!) несет ответственность
за конечное качество продукта.
10.1.3. Тестирование по отношению к спецификации
Тестирование по отношению к спецификации представляет собой одну из разновидно-
стей тестов, основанных на выполнении (прогоне) программы. Оно применимо к ис-
полняемым программным продуктам, а не документам или моделям. Этот вид тести-
рования также известен под другими названиями, такими как тестирование по методу
черного ящика, функциональное тестирование, тестирование по входу-выходу и т.д.
Принцип тестирования по отношению к спецификации заключается в том, что разра-
ботчик рассматривает тестируемый модуль как “черный ящик”, на вход kotojxji o подается
некоторая информация и который вырабатывает некоторый выход. При этом не делается
никаких попыток понять программную логику или вычислительные алгоритмы.
При тестировании по отношению к спецификации необходимо выработать тесто-
вые требования, исходя из требований-прецедентов, а затем идентифицировать и зафик-
сировать их в отдельных документах, представляющих тест-план и тестовые преце-
денты. Эти документы предоставляют в распоряжение специалиста по тестированию
сценарий тестирования (test scenario). Сценарий можно записать с помощью специаль-
ных средств автоматизации тестирования, а затем использовать его многократно.
Подобные средства получили название средств “записи-воспроизведения”. Такие
средства особенно полезны в случае регрессионного тестирования (разд. 1.3.10).
Тестирование по отношению к спецификации подходит для выявления дефектов,
которые трудно “поймать” другим способом. В частности, тестирование по специфи-
кации позволяет обнаружить пропущенные функции— что-то, что (надо надеяться) было
10.2. Тестирование системных ограничений 393
документировано как требование-прецедент (а следовательно, и тестовое требова-
ние), однако, так и не было запрограммировано. Этот вид тестирования позволяет
также выявить пропущенные функции, которые не были оформлены документально в
виде прецедентов, но явно пропущены в реализации системы.
10.1.4. Тестирование по отношению
к программному коду
Тестирование по отношению к программному коду представляет собой второй вид тес-
тирования, основанный на выполнении программы. Он также известен под назва-
ниями тестирования по методу прозрачного ящика, тестирование по методу стеклянного
ящика, тестирование путем покрытия логики программы и тестирование путем по-
крытия путей программы. Тестирование по отношению к программному коду начи-
нается с тщательного анализа алгоритмов программы. С целью испытания программы
выводятся прецеденты — это дает определенные гарантии проверки всех возможных
выполняемых ветвей программы. Для выполнения программы специальным образом
продумывается организация данных.
Для поддержки тестирования по отношению к программному коду также сущест-
вуют средства “записи-воспроизведения” сценариев тестирования, используемые для
регрессионного тестирования. Однако, характер тестирования по коду требует при-
влечения к использованию этих средств программистов. Многие сценарии
“проигрывания” тестов должны быть написаны программистами, а не сгенерированы
средствами автоматизации. Даже если сценарии и генерируются автоматически, мо-
жет потребоваться существенно модифицировать их с помощью программистов.
Подобно всем прочим видам тестирования, основанным на выполнении програм-
мы, тестирование по отношению к программному коду не может носить исчерпы-
вающего характера из-за комбинаторного взрывоподобного роста количества воз-
можных тестовых прецедентов даже при умеренном росте сложности программы.
Даже если существует возможность тестирования каждой выполняемой ветви про-
граммы, нет никаких гарантий, что все дефекты будут обнаружены. Старая мудрость
тестирования по-прежнему остается в силе — тестирование способно устранить неко-
торые ошибки, но не в состоянии доказать правильность программы!
10.2. Тестирование системных ограничений
Тестирование системных ограничений преимущественно факта реализации ограниче-
ний в соответствии с перечнем требований и тестовой документацией основано на вы-
полнении программы. Его цель состоит в установлении ограничений. Тестирование
системных ограничений включает ряд вопросов, некоторые из них приводятся ниже.
Тестирование пользовательского интерфейса.
Тестирование баз данных.
Тестирование контроля доступа.
Тестирование производительности.
Тестирование в утяжеленном режиме.
Тестирование при отказе.
Конфигурационное тестирование.
Инсталляционное тестирование.
394 Глава 10. Тестирование и управление изменениями
Первые два типа тестирования системных ограничений — тестирование пользова-
тельского интерфейса и баз данных— очень тесно связаны с тестированием системных
услуг. Они обычно проводятся в параллель с тестированием системных ограничений.
Поэтому включаются в тестовые документы (разд. 10.3), вырабатываемые для тести-
рования системных услуг.
10.2.1 . Тестирование пользовательского интерфейса
Тестирование GUI-интерфейса пронизывает весь процесс разработки ПО. Оно
начинается на ранней стадии этапа выработки требований, сопровождая такие виды
деятельности, как работа с архивными документами, включение эскизов окон в доку-
менты описания прецедентов и разработка прототипов GUI-интерфейса. Эти ранние
тесты GUI-интерфейса концентрируются на удовлетворении функциональных требо-
ваний и удобстве использования приложения.
Позже, после реализации системы требуется послереализационное тестирование GUI-
интерфейса. Вначале тестирование проводится разработчиками, затем специалистами
по тестированию и— перед выпуском ПО— заказчиками (пилотное тестирование) .
Ниже приведен примерный перечень вопросов тестового документа, разработанного
для послереализационного тестирования [9].
Соответствует ли название окна его функции?
Является ли окно модальным или немодальным? Каким оно должно быть?
Введено ли визуальное различие между обязательными и необязательными полями?
Можно ли изменить размеры окна, переместить его и восстановить? Необходимо
ли это?
Пропущены ли какие-либо поля?
Есть ли орфографические ошибки в названиях, метках, именах приглашений для
ввода и т.д.?
Нет ли противоречий в использовании командных кнопок (OK, Cancel, Save, Clear
и т.д.) в каких-либо диалоговых окнах?
Возможно ли всегда отменить текущую операцию (включая операцию удаления)?
Все ли статические поля защищены от изменения пользователем? Может ли
приложение изменить статический текст, корректно ли это делается?
Применяются ли для статических текстовых полей согласованные шрифты
и размеры?
Соответствуют ли размеры полей редактирования диапазону принимаемых ими
значений?
Все ли поля редактирования инициализированы верными значениями при
открытии окна?
Проверяются ли значения, вводимые в поля редактирования, клиентской
программой?
Правильно ли заполняются из базы данных значения выпадающих списков?
10.2. Тестирование системных ограничений 395
Используются ли маски редактирования в полях ввода в соответствии с
определением?
Доходчивы ли сообщения об ошибках и легко ли работать с ними?
10.2.2 . Тестирование баз данных
Аналогично тестированию GUI-интерфейса тестирование баз данных связано со
многими другими видами тестирования. Так, тестирование по методу черного ящика
(тестирование по отношению к спецификации) зачастую основано на использовании
входной и выходной информации для базы данных. Однако, это не исключает необ-
ходимости в отдельной методике тестирования баз данных.
Послереализационное тестирование баз данных включает всестороннее тестирование по
методу прозрачного ящика (в соответствии с программным кодом). Наиболее существен-
ной частью тестирования баз данных является тестирование транзакций. Тестирование не-
которых других аспектов баз данных — производительности, параллелизма, проверка пол-
номочий пользователей — иногда выделяют в отдельные группы тестов.
Аналогично тестированию GUI-интерфейса некоторые тесты баз данных требуется
проводить повторно для всех различных функций приложения. Вопросы, требующие
рассмотрения при тестировании баз данных, необходимо оформить в виде общего до-
кумента. Этот общий документ следует затем присовокупить к описанию всех функцио-
нальных тестов (тестов системных услуг). Ниже приводится примерный перечень во-
просов, на которые следует обратить внимание при тестировании баз данных [9].
Проверить, выполняется ли транзакция надлежащим образом при правильных
входных данных. Корректна ли обратная связь системы с GUI-интерфейсом?
Корректно ли содержимое базы данных после транзакции?
Проверить, выполняется ли транзакция надлежащим образом при неправильных
входных данных. Корректна ли обратная связь системы с GUI-интерфейсом?
Корректно ли содержимое базы данных после транзакции?
Прервать транзакцию до ее завершения. Корректна ли обратная связь системы с
GUI-интерфейсом? Корректно ли содержимое базы данных после транзакции?
Запустить одну и ту же транзакцию параллельно во многих процессах.
Сознательно заставить одну из транзакций заблокировать ресурс, необходимый
другим транзакциям. Получают ли пользователи понятное объяснение ситуации?
Корректно ли содержимое базы данных после транзакций?
Извлечь каждый из клиентских SQL-операторов из клиентской программы и
выполнить их над базой данных в интерактивном режиме. Совпадают ли
полученные результаты с ожидаемыми, а также соответствуют ли они результатам
при выполнении SQL-операторов в составе программы?
Выполнить интерактивное тестирование каждого более сложного SQL-запроса
(выдаваемого из клиентской программы или хранимой процедуры) по методу
прозрачного ящика, включая внешние соединения, объединения, подзапросы,
значения типа null, функции агрегации и т.д.
396 Глава 10. Тестирование и управление изменениями
10.2.3 . Тестирование авторизации
Тестирование авторизации можно рассматривать как естественное расширение тес-
тирования первых двух типов системных ограничений. Как клиентские
(пользовательский интерфейс), так и серверные (базы данных) объекты должны быть
защищены от несанкционированного использования. Тестирование авторизации
должно обеспечить проверку того, что механизмы безопасности, встроенные в кли-
ентскую и серверную части системы, в действительности защищают систему от не-
санкционированного проникновения.
Хотя нарушение безопасности безусловно сказывается на базах данных, защита
начинается с клиентской части системы. Пользовательский интерфейс программы
должен быть в состоянии динамически настраивать собственную конфигурацию в со-
ответствии с уровнем полномочий текущего пользователя (который подтверждается
(аутентифицируется) идентификатором и паролем пользователя). Пункты меню, ко-
мандные кнопки и даже целые окна могут стать недоступны пользователям, если у них
нет соответствующих прав.
Не все “проходы” в защите системы могут быть обращены в сторону пользовате-
лей. Поддержка авторизации является существенной компонентой любой СУБД.
Пользователю могут быть предоставлены выборочные права доступа к серверным
объектам, при этом права (полномочия) пользователя по отношению к серверу распада-
ются на две категории.
Доступ к отдельным серверным объектам (таблицам, представлениям, столбцам,
хранимым процедурам и т.д.).
Выполнение SQL-операторов (select, update, insert, delete и т.д.).
Полномочия для пользователей можно назначать непосредственно на уровне
пользователей или на групповом уровне. Группы позволяют администратору системы
защиты назначать права доступа группе пользователей с помощью однократного вво-
да соответствующих параметров. Пользователь может как не принадлежать ни к од-
ной группе, так и принадлежать к нескольким группам.
Для обеспечения большей гибкости при работе с авторизацией большинство
СУБД вводят дополнительный уровень авторизации — ролевой уровень. Роли позволяют
администратору системы защиты назначать права доступа всем пользователям, кото-
рые играют определенную роль в организации. Роли могут носить вложенный харак-
тер, т.е. права, предоставленные разным ролевым именам, могут перекрываться.
Для больших приложений ИС проектирование авторизации требует скрупулезной
работы. Зачастую наряду с прикладной базой данных создается база данных авториза-
ции для хранения и манипулирования клиентскими и серверными полномочиями.
После входа пользователя в систему прикладная программа обращается к базе дан-
ных, чтобы установить уровень полномочий пользователя и настроить свою конфи-
гурацию применительно к этому пользователю.
Любые изменения в правах доступа к базам данных осуществляются через базу
данных авторизации — т.е. никто, включая администратора системы защиты, не имеет
возможности непосредственно изменить права доступа к базе данных без предвари-
тельного обновления базы данных авторизации. На рис. 10.1 приведен пример про-
екта базы данных авторизации.
10.2. Тестирование системных ограничений 397
co_type = {menu item, action button, window,...}
Puc. 10.1. Проект базы данных авторизации
398 Глава 10. Тестирование и управление изменениями
10.2.4 . Тестирование других ограничений
Помимо описанных выше тестирование системных ограничений включает сле-
дующие виды тестирования.
Тестирование производительности.
Тестирование в утяжеленном режиме.
Тестирование при отказе.
Конфигурационное тестирование.
Инсталляционное тестирование.
Тестирование производительности направлено на измерение ограничений произво-
дительности, требуемых заказчиком. Ограничения связаны со скоростью транзакций и
пропускной способностью. Тестирование проводится при различной рабочей загрузке
систем, включая предполагаемую пиковую загрузку. Тестирование производительности
является важной составляющей настройки системы.
Тестирование в утяжеленном, режиме проектируется таким образом, чтобы вывести
из стоя систему при предъявлении к ней завышенных требований — из-за недостатка
ресурсов, необычной конкуренции за ресурсы, непредусмотренной частоты, величи-
ны или объема требований к ресурсам. Тестирование в утяжеленном режиме часто
сочетается с тестированием производительности и может потребовать соответст-
вующей аппаратной и программной оснастки.
Тестирование при отказе направлено на изучение реакции системы на различные
аппаратные, сетевые или программные сбои. Этот вид тестирования тесно связан с
процедурами восстановления, поддерживаемыми СУБД.
Конфигурационное тестирование связано с проверкой функционирования системы
при различной аппаратной и программной конфигурации. Для большинства произ-
водственных сред предполагается, что система способна функционировать на раз-
личных клиентских рабочих станциях, которые подключаются к базе данных с ис-
пользованием различных сетевых протоколов. На клиентских рабочих станциях мо-
жет быть инсталлировано различное ПО (например, драйверы), которое может
конфликтовать с предусмотренными установками.
Инсталляционное тестирование является расширением конфигурационного тести-
рования. Оно связано с проверкой надлежащего функционирования системы на каж-
дой из платформ, на которых она инсталлируется. Это означает фактическое повто-
рение тестирования системных услуг.
10.3. Документация по тестированию
и управлению изменениями
Документация по тестированию и управлению изменениями составляет неотъемлемую
часть остальной системной документации, включая документацию по прецедентам,
рис. 10.2. Системные функции, определенные в модели бизнес-прецедентов (разд. 3.5.2),
можно использовать для написания первоначального тесг-плана. Затем модель преце-
дентов используется для написания документации по тесг-прецедентам и определения
тестовых требований. Дефекты, обнаруженные во время тестирования, фиксируются в
документации по дефектам. В документации по усовершенствованию отражаются все не-
10.3. Документация по тестированию и управлению изменениями 399
реализованные требования-прецеденты. При использовании CASE-средств у разработчи-
ков существуют следующие возможности по созданию документации.
Разработка описательных документов и их последующее использование для
создания требований (тестовые требования, требования-прецеденты и т.д.) в
С ASE-репозитории.
Использование CASE-средств для ввода требований в репозиторий и последующая
генерация документации на их основе.
На рис. 10.3 показан фрагмент документации по тест-прецедентам, используемой
для ввода тестовых требований в репозиторий. Аналогично требованиям-
прецедентам тестовые требования нумеруются и организуются в виде иерархии. Не-
которые тестовые требования непосредственно соответствуют требованиям-
прецедентам. Отсюда основной раздел документа называется “Соответствие специ-
фикации прецедентов”.
Остальные разделы документа по тестовым прецедентам должны идентифициро-
вать требования к тестированию GUI-интерфейса, тестированию баз данных и тести-
рованию повторно используемых компонент. Этот вид тестов следует включить в ви-
де составной части в тестовые или функциональные модули по двум причинам. Во-
первых, для тестирования GUI-интерфейса, баз данных и общих компонент
(например, таких, которые оформляются в виде библиотек DLL) нам необходим
функциональный контекст, в рамках которого имеют смысл входные и выходные
данные. Во-вторых, дефекты GUI, баз данных и общих компонент могут проявиться
только в контексте некоторых, но далеко не всех функциональных тестов.
Документация по тестовым прецедентам используется для фиксации результатов.
Отсюда три столбца после каждого тестового требования, показанные на рис. 10.3.
Тестовое требование может завершиться неудачным тестированием, пройти испыта-
ние условно или безусловно
Рис. 10.2. Документация по тестированию и управлению изменениями
400 Глава 10. Тестирование и управление изменениями
Рис. 10.3. Документация по тест-прецедентам
10.4. Управление изменениями
Тестирование приводит к обнаружению дефектов. Дефекты необходимо исправ-
лять. Чтобы исправить дефекты, их необходимо отправить в виде запросов на изменение
(change requests) и адресовать разработчикам. Некоторые запросы на изменение связа-
ны с усовершенствованием., а не исправлением дефектов. Как дефекты, так и усовершен-
ствования изменяют свой статус, им могут быть присвоены различные приоритеты,
за их сопровождение могут отвечать различные лица, их необходимо отслеживать в
связи с их источниками в виде документации по тестированию и прецедентам и т.д.
Управление изменениями для любого программного проекта, в котором принима-
ет участие большое количество разработчиков, представляет собой сложную и ответ-
ственную задачу. Рассмотрим сценарий, в рамках которого исправление двух различ-
ных дефектов поручено двум различным разработчикам, при этом оказалось, что ис-
правление этих на первый взгляд несвязанных дефектов требует внесения изменений
в одну и ту же программную компоненту. До тех пор, пока разработчики не будуг
знать об этом возможном конфликте, оба разработчика могут одновременно работать
10.4. Управление изменениями 401
над исправлением, и в конце концов более позднее исправление приведет к отмене
исправления, сделанного раньше.
Для надлежащего управления изменениями необходимо применение средств управ-
ления запросами на изменения (как правило, входящих в состав CASE-средств). Подоб-
ные средства обеспечивают возможность интерактивного управления изменениями и
гарантируют работу всех разработчиков с последними версиями документов. Измене-
ния, внесенные в документ одним из участников проекта, тут же становятся достоя-
нием остальных разработчиков. Потенциальные конфликты разрешаются с помощью
механизмов блокировки или управления версиями. В первом случае заблокированный
документ становится временно недоступен другим разработчикам. В последнем случае
возможно создание нескольких версий одного документа, а конфликты между вер-
сиями разрешаются позднее посредством согласования.
10.4.1. Отправка запроса на изменение
Обычно запрос на изменение связан либо с дефектом, либо с усовершенствованием.
Запрос на изменение вводится в проектный репозиторий. После ввода в репозиторий
разработчики могут отслеживать продвижение запроса на изменение, наблюдать за
его статусом и действовать в соответствии с ним. Действия, выполняемые над запро-
сом на изменение, зависят от текущего статуса запроса.
На рис. 10.4 показана основная вкладка диалогового окна ввода информации о де-
фектах [69]. Дефекты нумеруются и подробно описываются.
Рис. 10.4. Окно подготовки информации для отправки запроса на изменение
Информацию о приоритете, серьезности, проекте и ответственном исполнителе
можно ввести с помощью выбора подходящих значений выпадающего списка
402 Глава 10. Тестирование и управление изменениями
(значения атрибутов, содержащихся в выпадающем списке и в других местах формы,
можно настроить в соответствии с нуждами проекта). Остальные поля позволяют
вводить описательную информацию, включая возможность присоединения докумен-
тации, имеющей отношение к дефекту, в частности, фрагментов программного кода.
Действие по отправке запроса на изменение может привести к автоматическому уве-
домлению участников проектной бригады через электронную почту. После этого запрос
на изменение переходит в состояние Submitted. Руководство проекта может настроить ин-
струментальные средства таким образом, чтобы в каждом состоянии выполнялись зара-
нее определенные действия. Например, в состоянии Submitted могут быть допустимы
следующие действия: Assign (Назначить [задание]) (участнику бригады), Modify
(Модифицировать (некоторые детали запроса)), Postpone (Отложить), Delete
(Удалить) (без исправления), Close (Закрыть) (возможно, в результате исправления).
10.4.2. Отслеживание запросов на изменение
Каждый запрос на изменение назначается члену бригады. Член бригады может от-
крыть (Open) запрос на изменение.
Рис. 10.5. Диаграмма измерений
10.5. Прослеживаемость 403
Если запрос находится в состоянии Орт, никто из других членов бригады не может
модифицировать статус запроса. После разрешения проблемы, связанной с запросом на
изменение, разработчик может выполнить над ним действие Resolve. Подробности
решения можно ввести в форму и отправить по электронной почте уведомление руко-
водству проекта и специалистам по тестированию. Последним может потребоваться
выполнить действие по верификации (Verify) разрешенного запроса на изменение.
На любом этапе средства управления изменениями могут отследить запросы и вы-
работать легкие для понимания диаграммы и отчеты (проектные показатели (project met-
rics)). Диаграммы и отчеты могут содержать данные по оценке количества не распре-
деленных по членам бригады дефектам помогают выявить загрузку каждого члена
бригады, показать, сколько осталось неразрешенных дефектов и т.д.
На рис. 10.5 показана диаграмма распределения актуальных дефектов по приори-
тетам. Шесть дефектов должны быть разрешены немедленно, на пятьдесят пять сле-
дует обратить более пристальное внимание, шестьдесят семь находятся в обычной
очереди и шестьдесят восемь имеют низкий приоритет.
10.5. Прослеживаемость
Прослеживаемость, тестирование и управление изменениями — не самоцель, и их
значение не следует переоценивать. Разработчики должны концентрироваться на
разработке, а не на отслеживании, тестировании или управлении изменениями. С
этими проблемами, как правило, связаны значительные проектные расходы. Однако,
в долгосрочной перспективе отсутствие управления этими проблемами влечет не ме-
нее значительные затраты.
Поскольку основу тестирования и управления изменениями составляет прослежи-
ваемость, рамки и глубину прослеживаемости проекта следует определять с использова-
нием анализа затрат и результатов. По меньшей мере прослеживаемость следует под-
держивать между требованиями на основе прецедентов и дефектами. В более развитой
модели между требованиями-прецедентами и дефектами в маршрут прослеживаемости
можно добавить тестовые требования. В еще более сложной модели прослеживаемости
рамки прослеживаемости могут включать системные функции, тестовые прецеденты,
усовершенствования, точки тестовой верификации и другие артефакты разработки ПО.
Оставшаяся часть этой главы посвящена рассмотрению модели прослеживаемости,
которая соответствует связям между системной документацией, показанной на рис. 10.2.
В документации на бизнес-прецеденты перечислены системные функции. Документ, опи-
сывающий тест-план, идентифицирует тестовые прецеденты. Функции связаны с тестовы-
ми прецедентами и требованиями-прецедентами, что отражено в документации по преце-
дентам. Тестовые требования, представленные в документе по тестовым прецедентам,
можно проследить назад к тестовым прецедентам и требованиям-прецедентам. Тестовые
требования, связанные с дефектами и усовершенствованиями, прослеживаются до преце
дентов-требований. Прослеживать дефекты до усовершенствований не требуется.
10.5.1. Прослеживаемость от системных возможностей
к прецедентам и прецедентным требованиям
Функциональные возможности системы представляют собой общую часть функций,
которые должны быть реализованы в системе. Это бизнес-процесс, представляющий
собой существенную часть системы с точки зрения ее эффективности. Обычно снс-
404 Глава 10. Тестирование и управление изменениями
темные функциональные возможности соответствуют бизнес-прецедентам модели биз-
нес-прецедентов (разд. 3.5.2). Если модель бизнес-прецедентов формально не разра-
батывалась, системные возможности идентифицируются в документе, отражающем
стратегическое видение системы (в технологии Rational Rose подобный документ так
и называется — Vision. Прим, ред.)
Каждая системная возможность реализуется с помощью требований-прецедентов,
выраженных в виде одного или нескольких прецедентов. Прослеживание прецедентов
обратно к потребностям заказчиков (выраженные в системных возможностях) помо-
гает проверить обоснованность и правильность модели прецедентов. Эта стратегия
“очерчивает рамки” фиксации требований и способствует выполнению этапа уста-
новления требований. Она также помогает осуществлению наращиваемой разработки
и предоставлению программного продукта заказчикам.
Данная стратегия может стать источником проблем, если требования-прецеденты
в рамах каждого прецедента связаны с функциями только косвенно. Это может при-
вести к ситуации, при которой между функцией и прецедентом существует траекто-
рия, хотя большая часть требований-прецедентов не имеет отношения к функции.
Принятие решения о том, обоснованно ли существование траектории между функци-
ей и прецедентом, может оказаться тяжелой и неблагодарной задачей.
Рис. 10.6. Прослеживаемость от функций до прецедентов и требований-прецедентов
Чтобы избежать масштабирования и долговременных проблем, связанных с этой
стратегией, матрица прослеживаемости должна отслеживать функции не только по
10.5. Прослеживаемость 405
отношению к прецедентам, но также непосредственно по отношению к требованиям-
прецедентам. Это возможно в том случае, если сам прецедент рассматривается как
обобщенное требование-прецедент, под которым находится иерархия специализиро-
ванных требований-прецедентов.
Это показано на рис. 10.6. Столбцы содержат прецеденты и требования-прецеден-
ты в рамках прецедентов. Иерархическое представление требований-прецедентов
можно свернуть или раскрыть. Стрелки обозначают траектории от функций к преце-
дентам и требованиям-прецедентам. Некоторые стрелки перечеркнуты. Это подозри-
тельные траектории (suspect traces). Траектория становится подозрительной, когда она
направлена от или к изменению требований. Прежде, чем разорвать подозрительные
связи, разработчику следует проанализировать их.
10.5.2. Прослеживаемость от тест-плана к тест-
прецедентам и тестовым требованиям
Документ описания тест-плана играет для тест-прецедентов ту же роль, что доку-
мент описания бизнес-прецедентов для прецедентов. Тест-план идентифицирует
обобщенную проектную информацию и программные компоненты (тест-прецедент ы),
которые требуется протестировать. Тест-план описывает также стратегию тестиро-
вания для проекта, необходимые для тестирования ресурсы, усилия и затраты.
Рис. ЮЛ. Прослеживаемость от тест-плана к тест-прецедентам и тестовым требованиям
406 Глава 10. Тестирование и управление изменениями
Каждый тест-прецедент, идентифицированный в тест-плане, должен быть описан в
виде документа по тестпрецеденту. Отображение тестовых требований на тест
прецеденты и тестпланы дает преимущества, аналогичные преимуществам применения
прослеживаемости между функциями, прецедентами и требованиями-прецедентами —
ограничение области тестирования, масштабируемость и т.д.
На рис. 10.7 показана матрица прослеживаемости от тест-плана к тест-прецедентам
и тестовым требованиям в рамках тестпрецедентов. Иерархическое представление
требований-прецедентов можно свернуть или раскрыть.
10.5.3. Прослеживаемость от UML-диаграмм
к документам и требованиям
Прослеживаемость и управление требованиями применимо не только к описатель-
ным документам и требованиям, представленным в текстовом виде, которые хранятся в
CASE-репозиторйи. Репозиторий хранит также UML-модели. Графические объекты
UML-диаграмм могут быть связаны гиперссылками с документами и требованиями.
Прослеживаемость от визуальных артефактов UML к любым другим записям репо-
зитория (в частности, документам и требованиям) можно установить для различных
графических пиктограмм UML. Пожалуй, наиболее важными из этих пиктограмм явля-
ются пиктограммы прецедентов на диаграммах прецедентов.
Assoniote Document to Use Cose 'Mnintoin Ads
ell uocur. e-it
CategoiyTBV
ContactEV
ContactRBV
.
„г
''
I .
Filter Displayed Data
FilteredDisplayedData
FV
Maintain Ad Duration Tolerances
Maintain Ad Links
Maintain Ads
Maintain Advertiser Groups
Maintain Agency Groups
Maintain Billboard Splits
Maintain Categoiy-Product Links
ModifyAdLinks
DrganizationAdvertiserMDEV
OrganizationEV
Organization-OutletMDEV
TC
TC
TC
TC
uc
uc
TC
uc
uc
uc
uc
uc
uc
uc
TC
TC
TC
TC
Puc. 10.8. Установление в документе гиперссылок на графические
пиктограммы прецедентов
10.5. Прослеживаемость 407
На рис. 10.8 показано диалоговое окно для установления гиперссылок между гра-
фическими пиктограммами прецедента (Maintain Ads) и документом. Гиперссылка
устанавливается изнутри UML-диаграммы прецедентов. В качестве связанного доку-
мента может выступать любой документ репозитория, включая документы, показан-
ные на рис. 10.2.
На рис. 10.9 показано диалоговое окно для установления гиперссылок между гра-
фическими пиктограммами прецедента (Maintain Ads again) и требованием-
прецедентом. В общем случае возможно установить связь между пиктограммой и лю-
бым типом требования.
UC: Use Case Requirement Type
UC10: Filter Displayed Data
UC18: Maintain Ad Duration Tolerances J
UC18.1: Create Ad Duration Tolerance
UC18.2: Update Ad Duration Tolerance
UC18.3: Delete Ad Duration Tolerance
UC18.4: Invalid Range
UC18.5: Invalid Date
UC18.6: Ambiguous Tolerance
UC18.7: Cannot Alter Historical Tolerance
UC18.8: The system retrieves and displays the following information for a
UC19: Maintain Ad Links
UC19.1: Modify Ad Relationships
UC19.2: Make Changes
UC19.3: Modify Start Date
UC19.4: Raw Ads Associated With Ad Link
UC19.5: List of Ad Relationships
yCl9.6: Undo Business Change............... ......
All locations
Puc. 10.9. Установление гиперссылок требования на графические
пиктограммы прецедентов
10.5.4. Прослеживаемость от требований-прецедентов
к тестовым требованиям
Прослеживаемость между требованиями-прецедентами и тестовыми требования-
ми является критическим фактором при оценке того, удовлетворяет ли приложение
бизнес-требованиям, установленным для него. Связи между этими двумя типами тре-
бований позволяют пользователю прослеживать дефекты через тестовые требования
назад к требованиям-прецедентам и системным функциям (см. рис. 10.2).
408 Глава 10. Тестирование и управление изменениями
На рис. 10.10 показана матрица прослеживаемости, включающая траектории между
требованиями-прецедентами и тестовыми требованиями. Обратите внимание, что как
требования-прецеденты, так и тестовые требования организованы иерархически. Иерар-
хические уровни, на которых определяются траектории, могут быть определены заранее.
Рис. 10.10. Прослеживаемость от требований-прецедентов к тестовым требованиям
10.5.5. Прослеживаемость от требований к дефектам
Документация по тест-прецедентам представляется в виде сценариев, содержащих
тестовые требования, которые требуют верификации при тестировании. Сценарии
используются при ручном тестировании, но многие из этих сценариев можно автома-
тизировать для использования в тестовых средствах “записи-воспроизведения”. Тес-
товые требования в документации по тест-прецедентам можно затем использовать
для установления точек верификации в этих автоматизированных тестах.
Точка верификации (verification point) — это требование, содержащееся в сценарии,
которое используется (при регрессионном тестировании) для подтверждения состояния
тестового объекта в рамках различных версий (скомпонованных версий) тестируемо-
го приложения. Существуют различные типы точек верификации [69]. Точка вери-
фикации может быть установлена для проверки отсутствия изменений в тексте, точ-
ности числового значения, идентичности двух файлов, отсутствия изменений в пунк-
тах меню, соответствия полученных результатов вычислений ожидаемым и т.д.
Автоматизированное тестирование требует работы с двумя файлами данных— базис-
ным файлом данных и файлом фактических данных. Во время записи процедура точки ве -
рификации записывает информацию об объекте в базисный файл данных. Эта информация
представляет собой базис для сравнения при последующих тестах (воспроизведении). Резуль-
10.5. Прослеживаемость 409
таты того сравнения запоминаются в файле фактических данных. Результаты каждой неудач-
ной процедуры тачки верификации требуют дальнейшего изучения и, при необходимости,
внесения в репозиторий средств управления изменениями в качестве дефекта.
Безусловно все дефекты, обнаруженные с помощью средств автоматизации или
вручную, должны быть сопоставлены с тестовыми требованиями. На рис. 10.11 пока-
зано средство, которое отображает все дефекты с помощью строкового броузера в
верхней части окна. Текущий выбранный дефект можно сопоставить с одним или бо-
лее тестовым требованием. В приведенном примере показана траектория от двух тес-
товых требований к выделенному дефекту.
10.5.6. Прослеживаемость от требований-прецедентов
к усовершенствованиям
Дефекты необходимо прослеживать непосредственно до тестовых требований. Усо-
вершенствования (которые должны быть реализованы в последующих выпусках про-
дукта) должны содержать соответствующие пояснения о требованиях-прецедентах. Из-
редка, в ситуации, когда дефект был преобразован в усовершенствование, связь по про-
слеживаемости между требованиями-прецедентами и тестовыми требованиями может
позволить пользователю проследить путь дефекта до усовершенствования.
На рис. 10.12 продемонстрировано то же средство (см. рис. 10.11), которое можно
использовать для управления усовершенствованиями и дефектами, как, впрочем, и
для любых других типов запросов на изменения.
Modify Ad Links screen labels
JEx00000132
AdExOOOOOl 38 Report too large to print message
AdExOOOOOl 39 IncorrectSpecifications
1^ Rational ClearQuest - [AdEx Clearquest database lor AdExZOOO system (All Def .,
аЗгоТгУс I1 ----. — л
AdEx2000- IModi(yAdLinkEditView(E\
AdEx20CG - Product Split Report
AdEx2000- ’Split Billboard EditView(EV !
AdExOOOOOl 41
AdPart Numbers / Billboards
AdExOOOOOl 42
|AdEx200U - ISplit Billboard Edit View (EV
Puc. 10.11. Прослеживаемость от тестовых требований к дефектам
Adding anew column
AdEx2000-
AdEx2000-
Undo Billboard Split Edit Vie
iAd Links Row Browse View
410 Глава 10. Тестирование и управление изменениями
Electronic Logs tor Cinema & Outdoor
i AdExZOOO - Data Collection
|AdEx00000102
kdExoooooioT
|AdEx00000187
AdExbOGOOlU
AdEx00Q00t)56
pdbdboooitM
|AdEx00000250
Dual monitoring otthe same outlet log. I AdExZOOO- Data Collection
Collection Status attached to a Media Group _ ]AdEx2000 - Data Collection
Entering a years worth of On-saie Dates for a publication-AdExZOOO - Date Collection
Vertical & Horizontal Scroll Bars________ jAdExZOOO - Quality Control
Setting Merges to run atterhours AdExZOOO - Quality Control
Minjrnjge butjgn tgrthe AdLink Merge window i AdExZOOO - Quality Control
jgi Rational ClearQuest [AdEx. Clearquest database lor AdExZOOO system (All Enhonc... HS
. -f •: - r- ;iz2j'—
».< ..-L. -.2 .1-X '..,ь
Puc. 10.12. Усовершенствования
Резюме
В этой последней главе книги мы обратились к вопросам тестирования и управле-
ния изменениями. Деятельность по тестированию и управлению изменениями охва-
тывает весь ЖЦ разработки ПО, однако, наибольшее внимание ей уделяется ближе к
завершению проекта. Тестирование и управление изменениями предполагает суще-
ствование связей по прослеживаемости между системными артефактами, которые
надлежащим образом поддерживаются в течение всей разработки.
Тестирование подразделяется на тестирование системных услуг и тестирование
системных ограничений. Тестирование системных услуг может быть основано на вы-
полнении программы или проводиться без выполнения программы. Тестирование без
выполнения программы включает сквозной контроль и инспекции. Тестирование с прого
ном программы может быть тестированием по отношению к спецификации или тести-
рованием по отношению к программному код.
Тестирование системных ограничений включает широкий набор относительно само-
стоятельных тестов, которые относятся к таким вопросам, как пользовательский ин-
терфейс, базы данных, авторизация, производительность, утяжеленный режим, по-
ведение при отказах, конфигурация и инсталляция приложения. Некоторые из тестов
системных ограничений проводятся в параллель с тестированием системных услуг,
другие выполняются независимо.
Тестирование и управление изменениями требуют разработки специальной доку-
ментации, такой как документы по планированию тестов, документы по тестовым
прецедентам, документы по дефектам и усовершенствованиям. Тестовые требования
идентифицируются в документах по тестовым прецедентам и увязываются с документа-
ми по требованиям-прецедентам и прецедентам. Запрос на изменение обычно связан
с дефектом или усовершенствованием.
Средства управления изменениями позволяют отправлять запросы на изменения и
отслеживать их продвижение после обращения к ним разработчика. Важная часть
средств управления изменениями связана с установлением путей прослеживаемости
между запросами на изменения и другими системными артефактами, в частности,
тестовыми требованиями и требованиями-прецедентами.
Вопросы 411
И) Вопросы
В1. В чем отличие сквозного контроля от инспекции?
В2. В чем заключается роль группы обеспечения качества (SQA-группы) в организации?
ВЗ. Что такое база данных авторизации? Какова ее роль в разработке и тестировании системы?
В4. Какие виды тестирования системных ограничений тесно связаны с тестированием в утя-
желенном режиме? Поясните свой ответ.
В5. Какие виды тестирования системных ограничений тесно связаны с инсталляционным тес-
тированием? Поясните свой ответ.
В6. Какие действия возможны в ответ на отправленный запрос на изменения?
В7. Что такое “подозрительная траектория”? Приведите пример.
В8. Что такое точке верификации?
В9. Объясните различие между файлом базисных данных и фактическими данными.
412 Литература
Литература
1. Allen, Р. and Frost, S. Component-Based Development for Enterprise Systems. Applying the
SELECT Perspectives, Cambridge University Press, 1998, 462 pp.
2. Angell, I.O. and Smithson, S. Information Systems Management. Opportunities and Risks,
Macmillan, 1991, 248 pp.
3. Arthur, L.J. Rapid Evolutionary Development. Requirements, Prototyping and Software Crea-
tion, John Wiley&Sons, 1992, 222 pp.
4. Bahrami, A Object Oriented Systems Development, Irwin McGraw-Hill, 1999, 412 pp.
5. Bennett, S. McRobb, S. and Farmer, R. Object-Oriented Systems Analysis and Design Using
UML, McGraw-Hill, 516 pp., 1999
6. Bochenski, B. Implementing Production-Quality Client/Server Systems, John Wiley&Sons,
1994, 442 pp.
7. Bollinger, T.B. and McGowan, C. A Critical Look at Software Capability Evaluations, IEEE Soft-
ware, 4, 1991, pp. 25-41
8. Booch, G. Rumbaugh, J. and Jacobson, I. The UnilOed Modeling Language. User Guide, Addi-
son-Wesley, 1999, 482 pp.
9. Bourne, K.C. Testing Client/Server Systems, McGraw-Hill. 1997, 572 pp.
10. Brooks, F.P. No Silver Bullet: Essence and Accidents of Software Engineering, IEEE Software, 4,
1987, pp. 10-19; reprinted in: Software Project Management. Readings and Cases, ed. C.F. Ke-
merer, Irwin, 1997, pp. 2-14
11. Buschmann, F. Meunier, R. Rohnert, H. Sommerlad, P. and Stal, M. Pattern-Oriented Software Ar-
chitecture. A System of Patterns, John Wiley & Sons, 1996,458 pp.
12. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-
Wesley, 1995, 442 pp.
13. Coad, P. with North, D. and Mayfield, M. Object Models. Strategies, Patterns, and Applications,
Yourdon Press, 1995, 506 pp.
14. Collins, D. Designing Object-Oriented User Interfaces, Benjamin/Cummings Publ., 1995, 590 pp.
15. Conallen, J. Building Web Applications with UML, Addison-Wesley, 2000, 300 pp.
16. Constantine, L.L. and Lockwood, L.A.D. Software for Use. A Practical Guide to the Models and
Methods of Usage-Centered Design, Addison-Wesley, 1999, 579 pp.
17. Date, C.J. An Introduction to Database Systems, Addison-Wesley, 7th edn., 2000,938 pp.
18. Davenport. Т.Н.Process Innovation: Reengineering Work through Information Technology.
-Harvard Business School Press, 1993, 338 pp.
19. Davenport, Т.Н. and Short, J. The New Industrial Engineering. Information Technology and
Business Process Redesign. Sloan Management Review. Cambridge. Summer, 1990. pp. IL 17.
20. Eaglestone, B. and Ridley, M. Object Databases, McGraw-Hill, 1998, 380 pp.
21. Eisenberg, A. and Melton, J. SQL:1999, Formerly Known asSQL3, ACM SIGMOD Rec., 1, 1999,
pp. 131-138.
Литература 413
22. Elmasri, R. and Navathe, S.B. Fundamentals of Database Systems, 3rd edn, Addison-Wesley,
2000, 956 pp.
23. Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997, 358 pp.
24. Fowler, M. UML P Current Status for Version 1.3,
http://ourworld.compuserve.com/_homepages/Martin_Fowler/utnlst.htin, 1999, 2 pp.
25. Fowler, M. and Scott, K.UML Distilled. A Brief Guide to The Standard Object Modeling Lan-
guage, 2nd edn, Addison-Wesley, 2000, 186 pp.
26. Fowler, S.GUI Design Handbook, McGraw-Hill, 1998, 318 pp.
27. Galitz. W.O.The Essential Guide to User Interface Design. An Introduction to GUI Design Prin-
ciples and Techniques, John Wiley&Sons, 1996, 626 pp.
28. Gamma, E. Helm, R. Johnson, R. and Vlissides, J.Design Patterns. Elements of Reusable Object-
Oriented Software. Addison-Wesley, 1995, 396 pp.
29. Gray, N.A.B.Programming with Class, John Wiley&Sons, 1994, 624 pp.
30. Hammer, M.Reengineering Work: DonXt Automate, Obliterate, Harvard Business Review, Bos-
ton. Jul/Aug, 1990, p. 104.
31. Hammer, M. and Champy, J. Reengineering the Corporation: A Manifesto for Business Revolu-
tion, Allen&Unwin, 1993, 224 pp.
32. Hammer. M. and Champy, J.The Promise of Reengineering. Fortune. 9.1993. p. 94.
33. Hammer, M. and Stanton, S.How Process Enterprises Really Work, Harvard Business Review,
Boston, Nov/Dec, 1993, pp. 108-118.
34. Hannon, P. and Watson, M.Understanding UML: The Developer’s Guide. With a Web-Based
Application in Java, Morgan Kaufmann, 1998, 368 pp.
35. Hawryszkiewycz, I. Karagiannis, D. Maciaszek, L. and Teufel, B.RESPONSE P Requirements
Specific Object Model for Workgroup Computing, Int. J. of Intelligent & Cooperative Informa-
tion Systems, 3, 1994, pp. 293-318.
36. Henderson-Sellers, B.Object-Oriented Metrics. Measures of Complexity, Prentice Hall. 1996,
230 pp.
37. Hoffer, J.A. George, J.F. and Valacich, J.S.Modern Systems Analysis and Design, 2nd edn, Addi-
son-Wesley, 1999, 854 pp.
38. Horton, 1.Beginning Visual C++ 5, Wrox Press, 1997, 1054 pp.
.39. Jacobson, I.Object-Oriented Software Engineering. A Use Case Driven Approach, Addison-
Wesley, 1992, 524 pp.
40. Jordan, E.W. and Machesky, J.J.Systems Development. Requirements, Evaluation, Design, and
Implementation, PWS-KENT Publ. Company, 1990, 648 pp.
41. KhoshalOan, S. Chan, A. Wong, A. and Wong, H.K.T.A Guide to Developing Client/Server SQL
Applications, Morgan Kaufmann Publ., 1992, 634 pp.
42. Kimball, R.The Data Warehouse Toolkit. Practical Techniques for Building Dimensional Data
Warehouses, John Wiley&Sons, 1996, 388 pp.
43. Kirkwood, J.High Performance Relational Database Design, Ellis Horwood, 1992. 266 pp.
44. Koestler, A.The Ghost in the Machine, Hutchinson, 1967, 384 pp.
45. Koestler, A.Janus. A Summing Up, Hutchinson, 1978, 354 pp.
46. Kotonya, G. and Sommerville, I.Requirements Engineering. Processes and Techniques. John
Wiley&Sons, 1998, 282 pp.
414 Литература
47. Kruchten, P.The Rational Unified Process, Addison-Wesley, 1999, 256 pp.
48. Lakos, J.Large-Scale C++ Software Design, Addison-Wesley, 1996, 846 pp.
49. Lee, R.C. and Tepfenhart, W.M.UML and C++. A Practical Guide to Object-Oriented Develop-
ment, Prentice-Hall, 1997, 446 pp.
50. Lieberherr, K.J. and Holland, I.M.Assuring Good Style for Object-Oriented Programs, IEEE
Soft., 9, 1989, pp. 38-48.
51. Maciaszek, L.A.Database Design and Implementation, Prentice-Hall, 1990, 384 pp.
52. Maciaszek, L.A.Object Oriented Development of Business Information Systems P Approaches
and Misconceptions, Proc. 2nd Int. Conf, on Business Information Systems BISX98, Poznan, Po-
land, 1998, pp. 95-111.
53. Maciaszek, L.A.Process Model for Round-Trip Engineering with Relational Database, in: Chal-
lenges of Information Technology Management in the 21st Century, 2000 Information Re-
sources Management Association International Conference, Anchorage, Alaska, USA, Idea
Group Publishing, pp. 2000, 468-472.
54. Maciaszek, L.A. De Troyer, O.M.F GettaJ.R. and Bosdriesz, J.Generalizalion versus Aggregation
in Object Application Development P the ‘AD-HOC’ Approach, Proc. 7th Australasian Conf, on
Information Systems ACISX96, Vol. 2, Hobart, Tasmania, Australia, 1996, pp. 431-442.
55. Maciaszek, L.A. Getla, J.R. and Bosdriesz, J.Restraining Complexity in Object System Develop-
ment P the ‘AD-HOC’ Approach, Proc. 5th Int. Conf, on Information Systems Development
ISDX96, Gdansk, Poland, 1996, pp. 425-435.
56. Maciaszek, L.A. and Wong, K.S.UML Dialect for Designing Object-Relational Databases, in:
Challenges of Information Technology Management in the 21 st Century, 2000 Information Re-
sources Management Association International Conference, Anchorage, Alaska, USA, Idea
Group Publishing, 2000, pp. 473-477.
57. NEXTNext Generation Computing. Distributed Objects for Business, ed. P. Fingar, D. Read and
J. Stikeleather, SIGS Books&Multimedia, 1996, 306 pp.
58. ODMGThe Object Data Standard: ODMG 3.0, ed. R.G.G. Cattell, D.K. Barry, M. Berler, J.
Eastman, D. Jordan, C. Russell, O. Schadow, T. Stanienda and F. Velez, Morgan Kaufmann,
2000, 300 pp.
59. Olsen, D.R.Developing User Interfaces. Morgan Kaufmann Publ., 1998, 414 pp.
60. Page-Jones, M. Fundamentals of Object-Oriented Design in UML, Addison-Wesley, 2000, 458 pp.
61. ParadigmParadigm Plus. Round-trip Engineering with Microsoft Visual C++, Platinum Technol-
ogy, 1997, 36 pp.
62. Pfleeger, S.L.Software Engineering. Theory and Practice, Prentice-Hall, 1998, 576 pp.
63. Porter, M.Cotnpetitive Advantage: Creating and Sustaining Superior Performance, Free Press,
1985, 558 pp.
64. Porter, M.E. and Millar, V.E.How Information Gives You Competitive Advantage, Harvard
Business Review, Jul/Aug, 1985, pp. 149-161.
65. Pressman, r.S.Software Engineering. A Practitioner’s Approach, 4th edn, McGraw-Hill, 1997,
852 pp.
66. Quatrani, T.Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000, 256 pp.
67. Ramakrishnan, R. and Gehrke, J.Database Management Systems, McGraw-Hill, 2000, 906 pp.
68. RationalRalional Rose 98. Roundtrip Engineering with C++, Rational Software Corp., 1998, 454 pp.
Литература 415
69. RationalRational Solutions for Windows, OnLine Documentation April 2000 Edition, Rational
Software Corp., 2000.
70. Riel, AJ.Object-Oriented Design Heuristics, Addison-Wesley, 1996, 380 pp.
71. Robertson, J. and Robertson, S.Volere Requirements SpecilOcations Template, Edition 6.1, At-
lantic Systems Guild, http://www.atlsysguild.com, 2000, 52 pp.
72. Robson, W.Strategic Management and Information Systems. An Integrated Approach, Pitman
Publ., 1994, 570 pp.
73. Ruble, D.A.Practical Analysis and Design for Client/Server and GUI Systems, Yourdon Press,
1997, 516 pp.
74. Rumbaugh, J. Blaha, M. Premerlani. W. Eddy, F. and Lorensen, W.Object-Oriented Modeling
and Design, Prentice-Hall, 1991, 500 pp.
75. Rumbaugh, J.Getting Started. Using Use Cases to Capture Requirements, J. Object-Oriented
Prog., Sept., 1994, pp. 8-10, 12, 23.
76. Rumbaugh, J. Jacobson, I. and Booch, G.The UniKIed Modeling Language Reference Manual,
Addison-Wesley, 1999, 550 pp.
77. Schach, S.Classical and Object-Oriented Software Engineering, 3rd edn, Irwin, 1996, 604 pp.
78. Schmauch, C.H.ISO 9000 for Software Deevelopers, ASQC Quality Press, 1994,156 pp.
79. Silberschatz, A. Korth, H.F. and Sudershan, S.Database System Concepts, 3rd edn, McGraw-Hill,
1997, 864 pp.
80. Smith, J.M. and Smith, D.C.P.Database Abstractions: Aggregation and Generalization, ACM
Trans. Database Syst., 2, 1977, pp. 105-133.
81. Sommerville, I. and Sawyer, P.Requirements Engineering. A Good Practice Guide, John
Wiley&Sons, 1997, 392 pp.
82. Sowa, J.F. and Zachman, J.A.Extending and Formalizing the Framework for Information Sys-
tems Architecture, IBM Syst. J., 3, 1992, pp. 590-616.
83. SQL Database Language SQL P Part 2: Foundation (SQL/Foundation), ISO-ANSI Working
Draft, March 2000, 1170 pp.
84. Stein, L.A. Lieberman, H. Ungar, D.A Shared View of Sharing: The Treaty of Orlando, in: Ob-
ject-Oriented Concepts, Databases, and Applications, ed. W. Kim and F.H. Lochovsky, Addison-
Wesley, 1989, pp. 31-48.
85. Stevens, P. and Pooley, R.Using UML Software Engineering with Objects and Components, Ad-
dison-Wesley, 2000, 256 pp.
86. Stodder, D.Tlre Database Dozen, Database Prog, and Design, Industry in Focus Issue, Dec.,
1997, pp. 9-24.
87. Stonebraker, M. and Moore, D.Object-Relational DBMSs. The Next Great Wave, Morgan Kauf-
mann Publ., 1996, 216 pp.
88. Szyperski, C.Component Software. Beyond Object-Oriented Programming, Addison-Wesley.
1998,412 pp.
89. Treisman, H.How to Design a Good Interface Design, Software Magazine, Australia, August,
1994, pp. 32-36.
90. Umar, A.Object-Oriented Client/Server Internet Environments, Prentice Hall. 1997, 528 pp.
91. Whitten, J.L. and Bentley, L.D.Systems Analysis and Design Methods, 4th edn, Irwin McGraw-
Hill, 1998, 724 pp.
416 Литература
92. WindowsThe Windows Interface Guidelines for Software Design, MSDN Library, CDROM col-
lection. Microsoft, 2000
93. Wirfs-Brock, R. and Wilkerson, B.Object-Oriented Design: A Responsibility-Driven Approach,
in: OOPSLAX89 Proceedings, SIGPLAN Notices, No. 10, ACM, 1989, pp. 71-75.
94. Wirfs-Brock, R. Wilkerson, B. and Wiener, L.Designing Object-Oriented Software, Prentice-Hall,
1990, 342 pp.
95. Wood, J. and Silver, D.Joint Application Development, 2nd edn, John Wiley&Sons, 1995, 402 pp.
96. Yourdon, E.Object-Oriented Systems Design. An Integrated Approach. Yourdon Press. 1994,
400 pp.
97. Zachman, J.AA Framework for Information Systems Architecture, IBM Syst. J., 3,1987, pp. 276-292.
Предметный указатель 417
Предметный указатель
А
Actor. См. Субъект
ADO, 265
API, 49
ASP,265
В
ВСЕ. См. Подход ВСЕ
BPR, 40
С
CASE-репозиторий, 37
типичные функции, 38
CASE-средства, 37
CGI, 265
cookie, 264
CORBA, 32; 193
CRC. См. Подход CRC
CRUD-операции, 133; 183
D
DCOM, 32
DFD. См. Диаграмма потоков данных
DLL, 49; 236; 265
Е
EJB, 32
ERD, 56
ERP-системы, ПО
ER-диаграммы, 316
F
Friend. См. Дружественность
G
GUI-интерфейс
многодокументный, 303
однодокументный, 303
н
HTTP, 265
I
ISA, 40
ISAPI, 265
ISO 9000, 36
J
JAD. См. Метод совместной
разработки приложений
JDBC, 265
JSP, 265
м
MDI-интерфейс, 303
MDI-приложение
дочернее окно, 304
родительское окно, 304
N
NSAPI, 265
О
Object Management Group. См. OMG
ODBC, 265
ODMG, 318
OID. См. Идентификатор объекта
OLAP, 216
OMG, 38
OSQL, 319
R
RAD. См. Метод быстрой разработки
приложений
418 Предметныйуказатель
Rational Unified Process, 34; 38
RDO, 265
RPC, 49; 236
S
SDI-интерфейс, 303
SQA, 54
SQL
уровня 1, 369
уровня 2, 369
уровня 3, 370
уровня 4, 371
уровня 5, 371
SQL:1999, 331
SQL3, 331
SQL92, 332
Stakeholders. См. Участники проекта
SWOT, 40
и
UML
определение, 38
типы моделей, 39
Unified Modeling Language. См. UML
Use case. См. Прецедент
V
VCM, 40
W
Web-сервер, 268
Web-страница, 264; 295
X
XML, 265
A
Абстрактный класс, 78
обозначение в UML, 79
Автообъект, 253
Автосообщение, 181; 253
this, 253
Агрегация, 74; 163; 224
асимметрия, 74
в языке UML, 165
солоны, 230
как альтернатива обобщению, 227
обозначение в UML, 74; 165
ограничение типа, 225
по значению, 74
по ссылке, 74
типа
- безраздельно обладает, 163; 225
- включает, 164; 226
- обладает, 164; 226
- участник,164; 227
транзитивность, 74
Аномалия обновления, 351
Апплет, 265
Аргументы
входные, 99
входные-выходные, 99
выходные, 99
фактические, 99
формальные, 99
Архитектура
клиент/сервер, 235
системы распределенной обработки,
235
системы распределенных баз
данных, 236
толстого клиента, 236
тонкого клиента, 236
трехзвенная, 236
уровень постоянных объектов базы
данных, 316
Архитектура клиент/сервер
интегральная логика, 237
пользовательский интерфейс, 237
презентационная логика, 237
функции доступа к данным, 238
функции приложения, 237
Архитектурное проектирование, 49;
235
Ассоциативная связь, 73
Ассоциативный класс, 73
Ассоциация, 70
бинарная, 71
выявление, 161
Предметный указатель 419
единичная кратность, 72
именование, 161
квалифицированная, 204
коммутативность, 161
кратность, 71; 162
моделирование, 160
необязательная принадлежность
объекта, 72
нулевая кратность, 72
обозначение в UML, 70
объем,73
обязательная принадлежность
объекта, 72
порядок, 71
принадлежность объекта, 72
производная, 161; 203
рекурсивная, 161
связь с сообщениями, 102
тернарная, 161
унарная, 71
циклы,161
Атрибут, 67
значения, 67
обозначающий класс, 67
параметризованный тип, 74
производный, 203
с областью действия-класс, 79
спецификация, 154
статический, 79
тип, 67
элементарный тип, 67
Б
Бизнес-компоненты, 268
Бизнес-объекты, 91; 116
Бизнес-прецедент, 132
субъекты, 132
Бизнес-стратегия, 40
Броузер деревьев, 295
Броузер строк, 293
Быстрая разработка прототипа, 47
В
Версии ПО, 35
Взаимодействие, 99
Видение системы, 132
Видимость
атрибутов, 68
атрибутов (обозначение в UML), 69
атрибутов, закрытая, 68
защищенная, обозначение, 197
операций,68; 70
операций (обозначение в UML), 70
операций, закрытая, 70
операций, открытая, 68; 70
унаследованных свойств, 199
Виды деятельности, 88
переходы, 87
состояния, 87; 88
Временная связь, 66
Временные объекты, 64
Вторичное окно, 296
выпадающий список, 300
диалоговое окно, 297
модальное, 296
немодальное, 296
окно входа в систему, 296
папка со вкладками, 299
Выявление агрегаций и композиций,
164
Выявление ассоциаций, 161
Выявление видов деятельности, 178
Выявление классов, 145
комплексный подход, 148
правила, 149
с использованием именных групп,
145
с использованием общих шаблонов,
146
с использованием подхода CRC, 148
с использованием прецедентов, 147
Выявление обобщений, 167
Выявление операций классов, 182
Выявление прецедентов, 171
анализ источников, 171
Выявление состояний объектов, 185
Выявление требований, 116
JAD-метод, 122
420
ИА1>метод4122 ;
анкетирование, 119;
изучение документови j
программных систем, 120
интервью, 117
наблюдение, 119
неструктурированное интервью, 118
прототипирование, 121
современные методы, 120
структурированное интервью, 118
традиционные методы, Ц7
Г
Главное окно, 290
Голоны (holon), 230
Граф состояний, 185
Графический интерфейс
пользователя, 283
д
Декларативная семантика, 37
Делегирование, 228
моделирование наследования, 229
повторное использование. 229
Дескриптор, 195
Дескриптор объекта, 64; 250
Деструктор,250 .
Детализированное проектирование... .
49; 235 ,
Диаграмма
бизнес-прецедентов, 132
взаимодейстаиа,180 , ,
видов деятельности, 87; 89; 178
классов, 91 £
компонент, 243
контекстная, 124
кооперации, 248
коопераций^ Последовательностей,
сравнение,1255' : "
навигации по окнам, '307 •
пакетов., 212 •
пакетов, для поведения, 212
пакетов, для состояний, 212
последовательностей, 99 .
прецедентов, 85; 170
развертывания, 245
развертывания, обозначение узлов,
245
состояний, 104; 106; 185
Диаграмма потоков данных, 124
Диаграммы,
взаимодействий, 99
классов, 48
прецедентов, 48
Диалоговое окно, 297
Динамическая классификация, 78; 366
Документ, 302
Дочернее окно, 293; 304
Дочерний класс, 75
Дружественность, 201
Ж
Жизненный цикл ПО
определение, 46
этап анализа, 46 '
этап детализированного
проектирования,49
этап интеграции, 50
этап определения требований, 47
этап проектирования, 46
этап проектирования архитектуры,
49
этап реализации, 46; 50
этап сопровождения, 51
этап спецификации требований, 48
этапы, 46
3
Зависимость по существованию, 74
Заглушка, 51
Закон Деметра, 363
Замещение, 76; 217 .
метода, 251
при наследовании реализации, 222
свойств, 218
Замкнутое конструирование, 383
для баз данных, 384
клиентских приложений, 383
Запросы на изменение, 401
Предметныйуказатель 421
Значения атрибута, 67
И
Идентификатор объекта, 64
Изменчивость базового класса
при наследовании реализации, 221
Именование классов
рекомендации,153
Инкапсуляция, 216
Инспекция, 54
Инсталляция, 50
Интегральная логика, 237
Интерфейс, 215
объявление, через абстрактный
класс, 216
открытый, 182
пользователя, 237
Исполнительное действие, 258
К
Каркас, 241
Класс, 62; 67
абстрактный, 78; 167
архитектурный, 240
ассоциативный, 73; 206
базовый, 240
базовый, изменчивость, 221
в сравнении с атрибутом, 149
выделение, 93
выявление, 144
доминантный, 244
дочерний,75
дружественный, 201
единичный, 149
именование, 153
квалифицирующий, 205
материализованный, 206
моделирование, 144
мощность, 149
наследование, 75
обозначение в UML, 67
пограничный, 91; 213
потенциальный, 145
родительский, 75
связность, 362
со связностью смешанных
экземпляров, 366
спецификация, 153
спецификация атрибутов, 154
сущность, 91; 213
увязка, 362
управляющий, 91; 213
целевой, 205
Классификация
динамическая, 78
множественная, 77
Класс-подмножество, 74
Класс-супермножество, 74
Клиентский узел, 268
Коллекция,100; 252
Композиция, 74; 163; 224
обозначение в UML, 74; 165
Компонента, 242
обозначение,242
проектирование, 264
Конструктор, 102; 250
Концептуальная модель данных, 316
Кооперация,63; 248
обозначение,248
отношение реализации, 248
поведенческая сторона, 255
структурная сторона, 255
Кортеж, 73
Кратность ассоциации, 71
Л
Логическая модель данных, 316
м
Маркер итерации, 251
Метод, 69
формальные аргументы, 99
Метод быстрой разработки
приложений, 122
Метод совместной разработки
приложений, 122
Метод ценностных цепочек. См.
Подход VCM
422 Предметный указатель
Методология реинжиниринга бизнес-
процессов. См. Подход BPR
Методы открытия доступа, 863
Множественная классификация, 77
Множественное наследование, 76
Модели прецедентов, 170
Модели спецификации, 48
Моделирование взаимодействий, 98
Моделирование состояний объектов,
185
Модель
видов деятельности, 87
Модель СММ, 35
определение 2-го уровня зрелости,
35
уровни зрелости, 35
Модель бизнес-классов, 116; 133
Модель бизнес-прецедентов, 116; 132
Модель взаимодействия, 180 .
Модель видов деятельности, 178
Модель данных
внешняя схема, 316
концептуальная, 316
логическая схема, 316
объектная-база данных, 318
определение, 316 , ,
физическая схема, 316
Модель изменения состояний, 80
Модель классов, 91; 144
Модель ОБД, 318
API-интерфейс объектной памяти,
318
встроенные операции, 323
инверсия, 321
ключи, 321
наследование интерфейса, 322
наследование реализации, 322
отношение обобщения типа
EXTENDS, 322
отношение обобщения типа ISA, 322
реализация ассоциации, 821-
стандарт ODMG 3.0,318
типы литералов, 319 •
типы литералов, атомические, 319
типы литералов, коллекция, 320
типы литералов, пустой (null), 320
типы литералов,
структурированный, 320
типы объектов, 320
элементарные типы данных, 319
Модель ОРБД
множественное наследование
интерфейса, 332
наследование типа of, 336
наследование типа under, 835
объектная таблица, 333
особый тип данных, 332
ссылочный тип, 335
столбцы, поля и атрибуты, 335
строчный тип, 334
структурированный тип данных, 333
типы данных, определяемые
пользователями, 332
элементарные типы, 332
Модель поведения, 80
Модель прецедентов, 85; 170
Модель рамок системы, 130
внешние сущности, 130
потоки данных, 130
Модель РБД, 342
альтернативный ключ, 345
внешний ключ, 346
домены, 344
ключ, 345
нормальные формы, 350
первичный ключ, 345
перекрестная таблица, 348
реализация бизнес-правил, 348
реляционная таблица, 344
реляционное представление, 349
ссылочная целостность, 346
триггер, 348
элементарные типы, 342
Модель состояний, 80; 104
вид деятельности, 1'06
действие, 106
ограждающее условие, 106
переходы, 106
события, 106
составное состояние, 106
Предметный указатель 423
состояние, 104
Модель технологической зрелости.
См. Модель СММ
Модули архитектуры, 35
н
Наблюдатель, 363
Навигация по программе, 373
диаграммы, 374
стереотипы, 373
Наследование, 75; 76; 215; 216
интерфейса, 216
интерфейса, пример, 216
интерфейса, с использованием
отношения реализации, 217
множественное, 76
ограничивающее, 218
расширяющее, 218
реализации, 217
реализации, замещение, 222
реализации, множественное, 224
реализации, недостатки, 221
реализации, обратные вызовы, 223
реализации, по удобству, 220
реализации, посредством
ограничения, 218
реализации, посредством
расширения, 218
Нормализация, 350
О
ОБД. См. Объектная база данных
Область действия, 70
класса, 70
экземпляра, 70
Область действия экземпляра, 183
Область действия-класс, 183
обозначение в UML, 79
Обобщение, 75; 166
наследование, 166
обозначение в UML, 167
подкласс, 166
суперкласс, 166
Обобщение, 215
Обратные вызовы, 254
абонент, 254
получатель, 254
при наследовании реализации, 223
Объект, 62
временный, 64
дескриптор, 64
идентификатор, 64
коллекция,100
обозначение в UML, 63
постоянный, 64
программный, 56
состояние, 143
теория классификации, 146
Объект-класс, 79
Объектная база данных, 318
Объектная нотация, 63
Объектно-ориентированный подход,
57
Объектно-реляционная база данных,
331
стандарт SQL
1999, 331
стандарт SQL3, 331
Объектные модели, 169
Объем ассоциации, 73
Ограничение
дескриптор, 195
примечание, 195
производная информация, 202
стереотип, 194
Оконный интерфейс, 290
Web-страница, 295
вторичное окно,296
главное окно, 290
диаграмма навигации по окнам, 307
дочернее окно, 293
окно просмотра деревьев, 295
окно просмотра строк, 293
Операция, 63; 69
абстрактная, 78; 167
дружественная, 201
замещение, 76
конструктор, 102
полиморфизм, 76
424 Предагетиый указатель
реализация с помощью кооперации,
258
с областью действия-класс, 79
сигнатура, 69
статическая, 79
ОРБД. См. Объектно-реляционная
база данных
Осуществимость проекта, 52
по срокам, 52
практическая, 52
техническая, 52
экономическая, 52
Отношение зависимости, 201
Отношение реализации, 217
Отношения соединения, 246
Отображение UML-моделей в ОБД,
325
агрегации, 329
ассоциации,327
классы-сущности, 325
композиции, 329
обобщения, 329
Отображение UML-моделей в ОРБД,
336
агрегации, 339
ассоциации, 338
классы-сущности, 338
обобщения, 341
Отображение UML-моделей в РБД, 351
агрегации, 353
ассоциации,352
классы-сущности, 352
обощения, 355
п
Пакет, 243
классов, 260
прецедентов,260
Пакеты, 211
вложенные, 211
обозначение, 211
отношение зависимости, 211; 212
проектирование, 260
Параметризованный тип, 74
Перегрузка
метода, 251
ПО промежуточного уровня, 49
Повторное использование
делегирование, 229
инструментальные средства, 240
инструментальные средства,
архитектурные, 240
инструментальные средства,
базовые, 240
каркасы, 241
компонент, 241
программного кода, 217
программное обеспечение. 240
степени детализации, 240
стратегии, 240
шаблоны, 241
Подкласс, 75
Подставимости
принцип, 166; 215
Подход ВСЕ, 236
Подход BCED, 238
Подход BPR, 42
диаграммы потоков работ, 43
Подход CRC, 148
Подход ISA, 43
архитектурные модели, 44
ракурсы, 44
Подход SWOT, 40
сильные и слабые стороны
организации, 41
Подход VCM, 41
основные и вспомогательные виды
деятельности, 41
Подходы к планированию разработки
ИС, 40
BPR, 42
ISA, 43
SWOT, 40
VCM, 41
уровни управления, 44
Полиморфизм
принцип, 166
Пользователь, 32
реальный, 33
уполномоченный, 33
Предметный указатель 425
Пользовательский интерфейс, 237
проектирование, 49
Порядок ассоциации, 71
Постоянная связь, 65
Постоянные объекты, 64
Потенциальный класс, 145
нерелевантный, 145
нечеткий,145
релевантный, 145
Поток событий, 86
Потоки,89
параллельные, 89
разветвление и объединение, 89
разделение и слияние, 89
Правило 7±2, 209
Представление, 303
Презентационная логика, 237
Прецедент, 81; 82
альтернативные потоки событий, 86
детализированное описание, 86
документирование, 86
как компонент системы, 171
краткое описание, 86
основной поток событий, 86
подчиненные потоки событий, 86
постусловия, 86
поток событий, 86
предусловия, 86
проектная документация, 271
связь с субъектом, 171
уточнение, 269
Прецеденты, 170
реализация с помощью кооперации,
255
Приложение
Internet-магазин, 80
клиентская часть, 80
серверная часть, 80
Примечание, 195
Принципы построения GUI-
интерфейса, 286
индивидуализация и настройка, 288
обратная связь, 289
согласованность, 287
терпимость к ошибкам, 289
эстетичность и удобство, 289
Проектирование
архитектурное, 235
детализированное, 235
Проектирование GUI-интерфейса, 283
документ и его представление, 302
оконный интерфейс, 290
прототип,284
руководящие принципы, 286
участники, 284
Проектное планирование, 52
Производная информация, 202
Прослеживаемость, 54; 403
функций системы, 403
Прототип, 121
эволюционный, 121
Прототип, 121
Профили в UML, 193
Процесс
клиентский, 235
прикладной, 236
серверный, 235
Процесс разработки ПО, 34
итеративный, 34; 35
с пошаговым наращиванием
возможностей, 34
Р
Развертывание, 267
РБД. См. Реляционная база данных
Реализация, 50
Реинжиниринг, 386
Реляционная база данных, 342
Родительский класс, 75
Родительское окно, 304
Ролевое имя, 68; 249
Ролевые имена, 161
С
Самоассоциативные отношения, 161
Сворачивание, 51
Связность, 51
Сервер приложений, 268
426 Предметный указатель
Серверная страница, 265
Сигнатура, 69; 166
Системная спецификация, 132
Системное планирование, 52; 115
Системное состояние, 91
Системные ограничения, 137
Системы-прототипы, 229
Сквозной контроль, 54
Сложность объектных систем
иерархии, 210
классы-посредники, 211
межуровневые соединения, 210
сети,209
соединение, 209
Событие, 106
Сообщение, 63,101
автосообщение, 253
аргументы, 250
асинхронное, 253
возврат управления, 99
итеративное, 251
кооперативное, 251
обновления, 251
обозначение, 249
связь с ассоциацией, 102
синхронное, 253
структура, 250
тип, 250
фактические аргументы, 99
чтения, 251
Сопровождение, 51
адаптивное, 51
поддержка эксплуатации, 51
улучшающее, 51
Составное состояние, 106
Состояния вида деятельности, 88
Состояния действия, 88
Спецификации состояний, 154
Спецификация агрегаций и
композиций, 165
Спецификация ассоциаций, 161
пример, 162
Спецификация атрибутов классов, 154
Спецификация видов деятельности,
178
пример, 179
Спецификация изменения состояний,
184
Спецификация классов, 153
примеры,154
Спецификация обобщений, 167
Спецификация объектов, 169
пример, 169
Спецификация операций классов, 183
Спецификация поведения, 154; 170
Спецификация прецедентов, 172
ассоциации, 172
включения, 172
пример, 172
Спецификация сообщений, 180
вызов, 180
пример, 180
сигнал, 180
Спецификация состояний, 144
пример, 186
Спецификация состояний объектов,
185
Спецификация требований, 48
Стереотип, 193
включения, 173
встроенный, 193
обозначение, 193
расширения, 173
Стереотипы, 155
Структурный подход, 56
СУБД
типы, 239
Субъект, 81; 132
внешняя сущность, 132
внутренняя сущность, 132
Суперкласс, 75
Сценарий, 265
т
Тестирование, 54
GUI-интерфейса, 394
авторизации, 396
Предметный указатель 427
баз данных, 395
документация, 398
инспекция, 391
метод прозрачного ящика, 393
метод черного ящика, 392
методическое, 391
неформальное, 390
пилотное, 394
по програмному коду, 55; 393
по спецификаций, 55; 392
регрессионное, 55
сквозной контроль, 391
средства записи-воспроизведения,
55
сценарий, 392
транзакций, 395
Тест-прецеденты, 54
Тип атрибута, 67
Точка сохранения, 380
Транзакция, 376
автоматическое восстановление, 378
компенсирующая, 380
короткая, 377
программируемое восстановление,
380
уровни изолированности, 378
Требования
анализ рисков, 125
бизнес-модель, 129
виды рисков, 125
выявление, 116
документ описания, 135
запрос на изменение, 128
идентификация и классификация,
126
иерархия, 127
к безопасности, 138
к границам системы, 115; 124
К данным, 115
к интерфейсу, 137
матрица зависимостей, 124
назначение приоритетов, 125
перекрывающиеся, 125
политические и юридические, 138
прецедентные, 120
принципы спецификации, 142
прослеживаемость, 128
противоречивые, 125
согласование и проверка
обоснованности, 123
управление, 126
управление изменениями, 128
установление,47; 115
функциональные, 115
шаблон документа описания, 135
эксплуатационные, 138
Требования к данным, 115
Трехзвенная архитектура, 49; 214; 236
Триггер, 372
Триггерный откат, 380
Триггеры, 237
У
Увязка классов
виды, 363
Управление изменениями, 400
запросы на изменение, 400
Управление требованиями, 126
Участники проекта, 32
заказчики, 32
разработчики,32
Ф
Физическая модель данных, 316
Формальный пересмотр, 54
Формулировка ограничения, 47
Формулировка сути сервиса, 47
Формулировки ограничений,115
Формулировки сервисов. 115
Функции доступа к данным, 238
Функции приложения, 237
Функциональное требование, 83
Функциональные требования, 115
X
Хранимая процедура, 134; 237; 371
ц
Циклическая разработка, 46
428 Предметный указатель
ш событийный, 146
Шаблон, 241 анализа, 241 определение, 241 параметризованный тип, 252 проектирования, 241 Шаблоны для классов, 146 Шаблоны для классов (по Барами) класс, 146 местоположений, 146 организационный, 146 понятийный, 146 Шаблоны для классов (по Рамбау) бизнес-класс, 146 компьютерный, 146 логический, 146 поведенческий, 146 прикладной, 146 физический, 146 э Элементарный тип, 67 Элементы размещения, 246