Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
Анализ требований и проектирование систем
Разработка информационных систем с использованием 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 ■ Heading, 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 horn the English language edition published by Pearson Education Limited. Copyright © 2001
All rights reserved. No part of this book may be reproduced, stored in retrieval system or transinined in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without eithei the prior written permission о the Publisher.
Russian language edition published by Williams Publishing House according to the Agi cement with R&I Enterprises International, Copyright © 2002
ISBN 5-8459-0276-2 (pyc.)ISBN 0-20170944-9 (англ.)ISBN 5-8459-0276-2 (pyc.)ISBN 0-20170944-9 (англ.)© Издательский дом "Вильямс”, 2002
ISBN 5-8459-0276-2 (pyc.)
ISBN 0-20170944-9 (англ.)
ISBN 5-8459-0276-2 (pyc.)
ISBN 0-20170944-9 (англ.)
© Pearson Education Limited, 2001
Оглавление
Предисловие14
Диаграммы деятельности для книги21
Процесс разработки программного обеспечения30
Основания анализа требований61
Установление требований115
Спецификация требований142
Углубленный анализ192
Основания проектирования систем234
Проектирование пользовательского интерфейса283
Проектирование баз данных315
Проектирование программ и транзакций361
Тестирование и управление изменениями390
Литература412
Предметный указатель417
Содержание
Предисловие14
Краткое содержание книги14
Отличительные особенности книги15
Для кого предназначена эта книга16
Структура книги17
Вспомогательные материалы18
Благодарности19
Диаграммы деятельности для книги21
Internet-магазин (наставление)22
Запись на университетские курсы (разбор примера)24
Магазин видеопроката (разбор примера)26
Управление контактами с клиентами (разбор примера)27
Телемаркетинг (разбор примера)29
Глава 1. Процесс разработки программного обеспечения30
Характер процесса разработки ПО30
Инвариант разработки ПО31
Участники проекта32
Процесс34
Язык и средства моделирования37
Планирование разработки системы39
Подход SWOT40
Подход VCM41
Подход BPR42
Подход ISA43
Системы для трех уровней управления44
Этапы жизненного цикла программного обеспечения46
Этап установления требований47
Этап спецификации требований48
Этап проектирования архитектуры48
Этап детализированного проектирования49
Этап реализации50
Этап интеграции50
Этап сопровождения51
Планирование проекта в течение жизненного цикла ПО52
Измерения в течение жизненного цикла ПО53
Тестирование в течение жизненного цикла ПО, 54
Подходы к разработке программного обеспечения55
Структурный подход56
Объектно-ориентированный подход57
Резюме59
Вопросы60
Глава 2. Основания анализа требований61
Основы объектной технологии61
Объект-экземпляр62
Класс67
Ассоциации70
Агрегация и композиция74
Обобщение75
Объект-класс79
Наставление по моделированию анализа80
Internet-магазин80
Моделирование прецедентов81
Моделирование видов деятельности87
Моделирование классов91
Моделирование взаимодействий98
Моделирование состояний104
2-3. Постановки задач для исследуемых примеров108
Запись на университетские курсы108
Магазин видеопроката109
Управление контактами с клиентамиПО
Телемаркетинг111
Резюме111
Вопросы112
Упражнения113
Глава 3. Установление требований115
Принципы установления требований115
Выявление требований116
Традиционные методы выявления требований117
Современные методы выявления требований120
Согласование и проверка обоснованности требований123
Требования, выходящие за рамки проекта124
Матрица зависимости требований124
Риски и приоритеты требований125
Управление требованиями126
Идентификация и классификация требований126
Иерархии требований127
Управление изменениями128
Прослеживаемость требований128
Бизнес-модель требований129
Модель рамок системы130
Модель бизнес-прецедентов132
Модель бизнес-классов133
Документ описания требований135
Шаблоны документа135
Предварительные замечания к проекту135
Системные сервисы137
Системные ограничения137
Проектные вопросы138
Приложения139
Резюме139
Вопросы140
Упражнения140
Глава 4. Спецификация требований142
Принципы спецификации требований142
Спецификации состояний143
Моделирование классов114
Моделирование ассоциаций160
Моделирование отношений агрегации и композиции163
Моделирование отношений обобщения166
Моделирование объектов169
Спецификация поведения170
Моделирование прецедентов1 70
Моделирование видов деятельности178
Моделирование взаимодействий180
Моделирование открытых интерфейсов182
Спецификация изменения состояний184
Моделирование состояний объектов185
Резюме187
Вопросы187
Упражнения188
Глава 5. Углубленный анализ192
Углубленное моделирование классов192
Стереотипы193
Ограничения194
Примечания и дескрипторы195
Видимость и инкапсуляция197
Производная информация202
Квалифицированная ассоциация204
Ассоциативный класс или материализованный класс206
Иерархия классов209
Сложность сетевых структур209
Сложность иерархических структур210
Пакеты211
Подход ВСЕ213
Углубленное моделирование обобщения и наследования215
Обобщение и подставимость215
Наследование или инкапсуляция216
Наследование интерфейса216
Наследование реализации217
Углубленное моделирование агрегации и делегирования224
Расширение семантики агрегации225
Агрегация как альтернатива обобщению227
Агрегация и голоны — интеллектуальное орудие230
Резюме231
Вопросы232
Упражнения233
Глава 6. Основания проектирования систем234
Архитектура программного обеспечения234
Распределенная архитектура235
Трехзвенная архитектура236
Программирование баз данных237
Стратегия повторного использования240
Компоненты242
Развертывание245
Кооперация247
Обозначение кооперации248
Диаграмма кооперации248
Диаграммы последовательностей и диаграммы кооперации 255
Реализация прецедентов255
Реализация операций258
Наставление по проектному моделированию259
Проектирование пакетов260
Проектирование компонент264
Проект развертывания -267
Проектирование кооперативных взаимодействий269
Резюме278
Вопросы279
Упражнения280
Глава 7. Проектирование пользовательского интерфейса283
Проектирование интерфейса как междисциплинарная деятельность283
Интерфейс: от прототипа к реализации284
Руководящие принципы проектирования интерфейса, ориентированного на пользователя286
Контроль — на стороне пользователя286
Согласованность287
Индивидуализация и настройка288
Терпимость к ошибкам289
Обратная связь289
Эстетичность и удобство289
Оконный интерфейс290
Главное окно290
Вторичное окно296
Зависимость между окнами302
Документ и его представление302
Однодокументный интерфейс303
Многодокументный интерфейс303
Навигация по окнам304
Введение навигационных стереотипов в диаграмму видов деятельности305
Диаграмма навигации по окнам307
Резюме311
Вопросы312
Упражнения312
Глава 8. Проектирование баз данных315
Уровень постоянных объектов базы данных315
Модели данных316
Отображение объектов в базу данных317
Модель объектной базы данных318
Элементарные типы модели О БД319
Отображение в ОБД325
Объектно-реляционная модель базы данных331
Элементарные типы модели ОРБД332
Отображение в ОРБД336
Модель реляционной базы данных342
Элементарные типы модели РБД342
Отображение в РБД351
Резюме359
Вопросы359
Упражнения360
Глава 9. Проектирование программ и транзакций361
Проектирование программы361
Связность и увязка классов362
Проектирование клиент-серверных кооперативных взаимодействий369
Навигация по программе373
Стереотипы диаграммы видов деятельности для навигации по программе373
Диаграмма навигации по программе374
Проектирование транзакций•376
Короткие транзакции377
Длинные транзакции382
Замкнутое конструирование383
Замкнутое конструирование для клиентских программ383
Замкнутое конструирование для баз данных384
Реинжиниринг реляционных баз данных в объектно- реляционные386
Резюме388
Вопросы389
Упражнения389
Глава 10. Тестирование и управление изменениями390
Тестирование системных сервисов390
Сквозной контроль391
Инспекция391
Тестирование по отношению к спецификации392
Тестирование по отношению к программному коду393
Тестирование системных ограничений393
Тестирование пользовательского интерфейса394
Тестирование баз данных395
Тестирование авторизации396
Тестирование других ограничений398
Документация по тестированию и управлению изменениями398
Управление изменениями400
Отправка запроса на изменение401
Отслеживание запросов на изменение402
Прослеживаемость403
Прослеживаемость от системных возможностей к прецедентам и прецедентным требованиям403
Прослеживаемость от тест-плана к тест-прецедентам
и тестовым требованиям405
Прослеживаемость от UML-диаграмм к документам
и требованиям406
Прослеживаемость от требований-прецедентов к тестовым требованиям407
Прослеживаемость от требований к дефектам408
Прослежива мость от требований-прецедентов к усовершенствованиям409
Резюме410
Вопросы411
Литература412
Предметный указатель417
Моей матери.
В память о моем отце.
Моей семье.
Предисловие
Краткое содержание книги
Разработка информационной системы (ИС) — от становления идеи до первой версии, передаваемой заказчикам, — состоит из трех этапов: анализа, проектирования и реализации, в результате итеративного выполнения которых происходит пошаговое “наращивание" системы. В этой книге представлены методы и средства, используемые на первых двух этапах. Вопросы реализации затрагиваются только в той мере, в которой они необходимы при рассмотрении этапа проектирования. Тестированию и управлению изменениями посвящена последняя глава.
Центрачьной темой книги являются вопросы объектно-ориентированной разработки программного обеспечения (ПО). Для описания артефактов при моделировании используется язык UML (Unified Modeling Language — унифицированный язык моделирования). Основное внимание уделяется разработке ИС с помощью метода последовательного уточнения, при этом упомянутый язык моделирования (UML) используется на протяжении всего жизненного цикла разработки. Аналитики, разработчики и программисты “говорят” на одном языке, хотя иногда в своих профессиональных интересах и могут пользоваться диалектами (профилями) языка.
Поначалу объектная технология применялась для разработки графических интерфейсов пользователя (GUI — graphical user interface) и была в основном направлена на ускорение разработки новых систем и ускорение выполнения программ. В этой книге основной упор сделан на применение объектной технологии к разработке ИС. На этом пути необходимо преодолеть такие трудности, как большие объемы и сложные структуры данных, совместный доступ к информации со стороны многих пользователей, обработка транзакций, изменяющиеся требования и т.д. Основным преимуществом применения объектной технологии в среде ИС является то, что она облегчает решение проблем, связанных с сопровождением и масштабируемостью.
Разработка информационной системы может служить синонимом анализа и проектирования “в большом”. Проект ИС не может быть успешным при несоблюдении строго определенного процесса разработки, а также в отсутствии понимания лежащей в основе системы архитектуры ПО. Подобную разработку можно охарактеризовать как крупномасштабную, объектно-ориентированную, итеративную и наращиваемую. Архитектура ПО основана на решениях клиент/сервер, где клиент представляет собой рабочею станцию с GUI, а на сервере хранится база данных. Программы клиента и сервера выполняются в рамках отдельных процессов и взаимодействуют через обмен сообщениями между объектами. База данных сервера может быть реляционной, объектнореляционной или чисто объектно-ориентированной.
В книге предложен детализированный подход к анализу и проектированию информационных систем с использованием UML, и определены способы решения следующих задач.
Преодоление сложности моделей больших систем.
Усовершенствование архитектуры ПО.
Повышение уровня понятности, удобства сопровождения и масштабируемости.
Обеспечение многоуровневой структуризации объектов.
Управление интеграцией компонент.
Усовершенствование модели взаимодействия между GUI и перманентными объектами базы данных и т.д.
Отличительные особенности книги
Книге присущи некоторые отличительные черты, сочетание которых делает ее просто уникальной. Изложение ведется с позиций подхода, который можно назвать “обучением на примерах”. В основу рассмотрения положены примеры, а также наставление по анализу и проектированию. Примеры независимы друг от друга и относятся к пяти проблемным областям: Запись на университетские курсы (University Enrollment), Магазин видеопроката (Video Store), Управление контактами с клиентами (Contact Management), Телемаркетинг (Telemarketing) и Internet-магазин (Online Shopping. Примеры построены в виде разбора конкретных ситуаций, которые можно расширить или модифицировать с помощью вопросов, приведенных в конце большей части глав в разделе “Упражнения”. В некоторых из упражнений используется шестая проблемная область — Оценка расходов на рекламу (AdvertisingExpenditure Measurement).
Чтобы облегчить самостоятельное изучение материала, наставление (Internet- магазин) и анализ примеров излагаются в форме вопросов и ответов. В начале книги помещен специальный раздел, “Диаграммы видов деятельности для книги", содержащий диаграммы, которые связывают шаги “вопрос/ответ”, используемые в наставлении и при разборе ситуаций. Диаграммы видов деятельности могут служить в качестве альтернативного “оглавления” для примеров, разбросанных по книге.
В данном пособии рассматриваются принципы, методы и приемы, способные обеспечить надлежащий анализ и надлежащее проектирование. Особое внимание уделяется этапу проектирования, трактовка которого далека от его понимания как простого преобразования результатов анализа. При этом в книге находит подтверждение факт существования трудностей и сложностей на пути разработки крупномасштабных объектноориентированных систем клиент/сервер. Во многих отношениях книга содержит свежий взгляд на проектирование “в большом”, итеративную пошаговую разработку больших систем, а также на возможности и ограничения, присущие средствам и методам, которые применяются при создании крупных программных изделий.
Своим уникальным характером книга обязана в первую очередь гармоничному сочетанию практического акцента в объяснении материала с проникновением в его теоретическую суть. В качестве основной предпосылки является стремление избежать ненужной сложности, не утратив необходимой строгости. Книга написана с позиций опыта. Вопросы, не имеющие прямого отношения К индустрии ПО либо представляющие сегодня чисто научный интерес, не вошли в книгу.
Книга отражает последние достижения в сфере информационной технологии; использует самый последний стандарт в области моделирования систем — язык UML и обращается к новейшим разработкам в технологии баз данных, включая объектнореляционные базы данных. В этом контексте в книге не могло не найти отражения такое явление, как возврат от “толстого клиента” (т.е. мощного настольного компьютера)
к серверным вычислениям, происходящий под влиянием развития Internet. Рассматриваемые в книге принципы анализа и проектирования в равной мере применимы как в случае решений, основанных на архитектуре клиент/сервер, так и современных распределенных приложений, построенных с использованием компонентного подхода.
Разработка ПО не сводится к однозначным решениям типа “черное-белое", “истина-ложь”, “нуль-один". Источником эффективных программных решений служат идеи толковых бизнес-аналитиков, системных проектировщиков и программистов, а не безоглядное применение алгоритмов. Здесь проводится линия, направленная на то, чтобы предупреждать читателя о потенциальных трудностях, которые не могут быть полностью разрешены в рамках предлагаемого подхода. Благодаря этому можно надеяться, что читатели станут применять приобретенные знания обдуманно и не будут рассчитывать на то, что использование предлагаемого подхода не потребует от них усилий, в противном случае они рискуют обмануться в своих ожиданиях.
Подводя итог, можно отметить следующие отличительные черты, свойственные книге.
Книга устанавливает связь теории с действительностью — в виде практических проблем и ограничений, на которые следует обращать внимание, применяя пред лагаемый подход на деле.
Особое внимание в книге уделяется этапу проектирования. Проектирование нт рассматривается как простое преобразование результатов анализа, при этом внимание читателей обращается на трудности и сложности, присущие разработке крупномасштабных систем клиент/сервер.
Книга изобилует нетривиальными примерами и упражнениями, которые приводятся вместе со всеми необходимыми решениями и пояснениями.
Для кого предназначена эта книга
Это пособие предназначено как для студентов, так и для практиков, что полностью отвечает растущей потребности в университетских курсах, более приближенных к отраслевой практике. Его подготовка была непростой задачей, но есть основания надеяться, что ее удалось успешно решить. Чтобы полученные знания оставались актуальными в течение более продолжительного времени, относящиеся к разработке ПО аспекты реализации рассматриваются безотносительно к специфике тех или иных конкретных программных продуктов, представленных сегодня на рынке (хотя коммерческие GASE- средства используются в иллюстративных целях и в качестве примеров решений).
Книга призвана служить в качестве учебного курса по теории вычислительных систем и информационным системам. Поскольку она содержит как “высокоуровневые” темы, относящиеся к системному моделированию, так и “низкоуровневые” вопросы проектирования пользовательского интерфейса и баз данных, книга может оказаться полезной для курсов по системному анализу, проектированию систем, программной инженерии, базам данных, объектной технологии, а также курсов по программным проектам, которые требуют от студентов разработки системы в соответствии с жизненным циклом разработки: начиная с определения требований и заканчивая реализацией GUI и баз данных. Настоящее пособие задумано как односеместровый курс, однако потенциально может быть использовано при чтении двух односеместровых курсов — одного по анализу требований, а другого по проектированию систем.
Для той части читателей, которые относятся к специалистам-практикам, представленные теории увязываются с реальными проблемами. Источником большинства постановок задач, примеров и упражнений послужил опыт работы автора в качестве консультанта. Мы предупреждаем читателя о потенциальных трудностях и ограничениях, связанных с предлагаемым подходом. По нашему мнению, наибольшую пользу от книги могут получить следующие категории специалистов-практиков: бизнес- аналитики и системные аналитики, проектировщики, программисты, системные архитекторы, руководители и менеджеры проектов, специалисты по анализу решений, тестированию и подготовке технической документации, инструкторы производственного обучения.
Структура книги
Книга полностью охватывает вопросы объектно-ориентированного анализа и проектирования информационных систем. Материал представлен в порядке, соответствующем современным процессам разработки. Пособие состоит из десяти глав. Охват материала равномерно распределен между анализом и проектированием. Первые пять глав касаются вопросов анализа, а вторые пять — проектирования и связанных с ним сведений.
Читатели с различным базовым уровнем подготовки должны иметь возможность по-разному работать с книгой применительно к своим потребностям. Две главы книги посвящены объяснению оснований анализа и проектирования. Оставшиеся главы предполагают понимание этих оснований. Читателям предоставляется выбор: изучать главы, посвященные “основаниям” досконально, или же использовать их только в качестве обзора.
Чтобы сделать изложение более ясным и нарушить его однообразие, в книге используется несколько приемов, перечисленных ниже.
Разделы сделаны небольшими по объему.
Примеры и постановки задач помещены в рамки, чтобы выделить их из остального текста. Графические пиктограммы (см. ниже) на полях страниц также отмечают начало каждого примера.
В книге используются пиктограммы, которые служат указателями примеров в тексте, а также вопросов и упражнений, заключающих главы. Пиктограммы будут представлены в следующем виде.
10ИВ110ИВ1ПИКТОГРАММА
10ИВ1
10ИВ1
Примеры
Вопросы
Упражнения
Вспомогательные материалы
На Web-узлах, дополняющих книгу, в распоряжение читателей предоставляется обширный комплект вспомогательных материалов. К большей части Web-документов читатели имеют свободный доступ, но некоторые материалы защищены паролем в интересах преподавателей, которые станут применять пособие в учебном процессе. Информационные страницы по книге одновременно поддерживаются на следующих Web-узлах
http:// www.booksites.net/maciaszek
http://www.comp.mq.edu.au/books/maciaszek
Комплект вспомогательных материалов включает следующие Web-документы.
Instructor’s Manual (Руководство преподавателя), содержащее нижеприведенные материалы.
Lecture Slicks (Лекционные слайды) в форматах Power Point и Acrobat Read (.pdf).
Answers and, Solutions (Ответы и решения). Руководство, содержащее аннотированные ответы и решения для всех вопросов и упражнений, помещенных в конце каждой главы. Организация руководства соответствует структуре учебника. Вопросы из учебника повторяются в руководстве. Ответы и решения следуют за вопросами.
Student's Resources (Материалы для студентов), пригодные для печатания лекционных слайдов в формате Acrobat Read.
Self-education Resources (Материалы для самообразования) — файлы моделей, представленных средствами Rational Rose (.mdl) и PowerDesigner (.pdm). содержащие решения задач из наставления, анализ ситуаций и все прочие примеры моделирования из учебника.
Errata (Список опечаток) — страница, предназначенная для исправления ошибок и описок, встретившихся в книге.
For More Information (Дальнейшие сведения) — страница, указывающая читателям на последние идеи и тенденции, относящиеся к предмету книги. Также служит указателем на курсы, построенные на основе книги, которые подготовлены для совместного использования другими читателями с помощью WWW.
Ваши комментарии, исправления, предложения по улучшению и приглашения к сотрудничеству будут приняты с большой благодарностью. Пожалуйста, направляйте вашу корреспонденцию автору
Leszek A. Maciaszek
Department of Computing
Macquarie University
Sydney
NSW 2109
Australia
ksz£k@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
Благодарности
Написание этой книги было бы невозможно без общения с моими друзьями, коллегами, студентами, ведущими специалистами отрасли и многими другими людьми, которые сознательно или нет оказали влияние на формирование моих знаний о проблемной области. Я действительно в большом долгу перед ними. Попытка перечислить всех могла бы показаться неблагоразумной и невыполнимой, поэтому — большое спасибо всем. Однако, даже при отсутствии достаточного места для благодарностей некоторых “товарищей” следует упомянуть особо.
Кейт Менсфилд (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 воспроизводится с разрешения Маккуарийского университета.
Web-узел, дополняющий книгу Лешека А. Мацяшека Анализ требований и разработка систем.
Посетите Web-узел, дополняющий книгу Анализ требований и разработка систем. расположенный по адресу
http://www.booksItes.net/maciaszek
Здесь вы найдете ценные материалы, необходимые для преподавания, обучения
Для преподавателей:
лекционные слайды в формате PowerPoint или Acrobat;
руководство, содержащее аннотированные ответы и решения для всех вопросов и упражнений, помещенных в конце каждой главы.
Для студентов и преподавателей:
файлы моделей, представленных средствами Rational Rose и PowerDesignei, содержащие решения задач из наставления, анализ ситуаций и все прочие примеры моделирования из учебника;
обновленную страницу, содержащую ссылки на последние тенденции и работы других специалистов, работающих в этой проблемной области.
Диаграммы деятельности для книги
Знания в области анализа требований и проектирования систем носят прикладной характер. Поэтому их нельзя по-настоящему усвоить, только читая учебники. Единственный эффективный способ овладеть ими — пробовать применять на практике, совершая ошибки, анализируя эти ошибки и стремясь избежать их при выполнении следующих заданий. Данный учебник был написан с учетом этого наблюдения.
Книга насыщена примерами, включая наставление и разбор четырех конкретных случаев. Однако, примеры сформулированы таким образом, чтобы дать возможность читателю заниматься самостоятельно, экспериментировать, совершать ошибки и находить альтернативные решения. Читателю всегда предлагается найти собственное решение прежде, чем заглянуть в ответ. Как сказал Джим Хорнинг (Jim Horning): "Верные решения вырабатываются на основе опыта. Опыт вырабатывается на основе ошибочных решений".
Диаграммы деятельности для книги предоставляют в распоряжение читателей “карту'”, которая связывает между собой все примеры. При построении этих диаграмм использовался метод формального моделирования (диаграммы деятельности языка UML), однако, для использования данных диаграмм какого-либо знания метода не требуется. Каждый прямоугольник с закругленными углами (состояние в UML) соответствует разделу книги с примером. Некоторые стрелки, которые (прямо или косвенно) указывают на прямоугольник, исходят из других прямоугольников. Все такие прямоугольники соответствуют примерам, выполнение которых является предусловием для данного примера. Обозначения на стрелках определяют все действия, которые должны быть завершены до того, как приступить к рассмотрению примера.
Разнообразие способов применения диаграмм деятельности для книги ограничено только воображением читателя. Вот некоторые из возможных применений диаграмм.
Объединение примеров в наставлении или при разборе примеров в связный модуль, который можно использовать как логичную и непрерывную учебную работу'.
Быстрый поиск предшествующих примеров и решений, необходимых для того, чтобы приступить к следующему заданию.
Выбор некоторых видов деятельности по моделированию и пропуск остальных с целью индивидуализации обучения.
Разработка заданий для студентов и т.д.
В конце каждой главы диаграммы деятельности для книги объединены с упражнениями. Упражнения развивают идеи, заключенные в примерах. Лучший способ найти примеры, относящиеся к упражнению, и понять, какие знания требуются для решения задачи, сформулированной в упражнении, состоит в том, чтобы просмотреть соответствующую диаграмму вида деятельности.
Internet-магазин (наставление)
10.1.3 (Рис. 10.3)
Запись на университетские курсы (разбор примера)
Магазин видеопроката (разбор примера)
Управление контактами с клиентами (разбор примера)
Управление контактами с клиентами — Анализ
28 Управление контактами с клиентами (разбор примера)
Телемаркетинг (разбор примера)
Процесс разработки
программного обеспечения
Данная глава посвящена изложению — на уровне обзора — некоторых стратегических вопросов, касающихся процесса разработки ПО. Поскольку предлагаемые темы рассматриваются лишь на общем уровне, а некоторые из вопросов носят спорный характер, читателям вовсе не обязательно соглашаться с автором, чтобы извлечь пользу из оставшейся части книги (а, может быть, и переменить свое мнение по завершении чтения книги).
Образовательное значение данной главы состоит в том, чтобы ввести читателя в процессы и подходы, которые лежат в основе современной разработки ПО. Многие идеи и вопросы, рассматриваемые в данной главе, могут быть уже знакомы читателям из опыта, повседневного использования компьютеров или соответствующей литературы. При желании такие читатели могут просто бегло просмотреть данную главу и перейти к главе 2.
Характер процесса разработки ПО
Литература по управлению информационными системами (ИС) изобилует примерами провалившихся проектов, превышения сроков и бюджетов, ошибочных решений, систем, не пригодных для сопровождения и т.д. В исследовательском отчете организации Standish Group за 1998 год по проекту CHAOS (который так любят цитировать!) утверждается, что три из четырех программных проектов терпят неудачу в одной из приведенных выше областей. В свете подобных утверждений уместно задаться вопросами: “В чем причина подобных провалов? Какие симптомы свидетельствуют о возникновении проблем в проекте и как их можно нейтрализовать?"
Прежде, чем обратиться к этим вопросам, необходимо понять характер процесса разработки ПО. В своей ставшей уже классической статье [10] Брукс (Brooks) определяет как сущность, так и случайные свойства, характерные для программной инженерии (software engineering). Сущность программной инженерии кроется в собственных свойствах программного обеспечения, которые вызывают трудности при его создании. Эти трудности можно только осознать — их нельзя ни преодолеть за счет какого- либо технологического прорыва, ни сразить “серебряной пулей". Согласно Бруксу
сущность программной инженерии проистекает из таких свойств ПО, как сложность, податливость, изменчивость и неосязаемость.
Четыре “существенных трудности” создания ПО определяют инвариант или неизменную составляющую процесса его разработки. Инвариант просто констатирует тот факт, что ПО является продуктом творческого акта разработки — ремесла или искусства в том смысле, что эта деятельность совершается скорее ремесленником, чем художником. При обычном положении дел ПО не является результатом повторяющегося акта производства.
После того, как мы разобрались, что собой представляет инвариант разработки ПО, можно обратиться к понятию случайных свойств программной инженерии. Эти свойства не присущи ПО изначально, они скорее привнесены извне и обусловлены вмешательством “человеческого фактора” в практику создания ПО. Свойства программной инженерии, которые носят случайный характер, также порождают определенные трудности при создании ПО. В свою очередь мы разделяем эти “случайные трудности” на три категории.
Участники проекта.
Процесс.
Язык и средства моделирования.
Инвариант разработки ПО
Как мы уже отмечали, ПО скорее разрабатывается, а не производится [65]. Конечно, никто не может отрицать, что достижения программной инженерии привнесли в практику разработки большую определенность, однако (в отличие от традиционных инженерных дисциплин), успех программного проекта гарантировать нельзя.
Алгоритмы, библиотеки программ, повторно используемые классы, программные компоненты и т.д. представляют собой неполные, фрагментарные решения для того, что нам требуется описать при разработке информационных систем. Проблема состоит в том, чтобы собрать воедино небольшие фрагменты проблемы в виде гармоничной корпоративной системы, которая удовлетворяет требования сложных бизнес-процессов.
Практика создания ПО способствует разработке систем из настраиваемых программных пакетов — решений на основе COTS-продуктов (commerciaboftheshelfsottvw.re — готовое к использованию ПО) или ERP-систем (Enterprise Resource Planning System— система планирования корпоративных ресурсов). Программный пакет может обеспечить функции стандартного бухгалтерского учета, производственной системы или системы управления кадрами. Акцент смещается от разработки “с чистого листа” к “настройке” ПО, однако, процесс производства все равно занимает значительное место.
Для всякой системы, разрабатываемой “с чистого листа”, необходимо сначала создать концептуальные конструкции (модели) для конечного решения, которые бы удовлетворяли специфические потребности организации. После их создания функциональные возможности программного пакета настраиваются в соответствии с концептуальными конструкциями. Задачи программирования могут быть разными, но характер деятельности по анализу требований и системному проектированию, связанной с этими конструкциями, при разработке “с нуля” аналогичен. В общем, концептуальная конструкция (модель) сохраняется, несмотря на всевозможные изменения ее представления (реализации).
Что еще более важно, маловероятно, чтобы организация могла найти программный пакет для автоматизации ее ключевых бизнес-процессов. Ключевым бизнеопроцессом для телефонной компании выступает телефония, а не управление кадрами или бухгалтерский учет. То, что заставляет компанию работать (и конкурировать), должно разрабатываться “с нуля” (или переделываться из унаследованной системы). Как верно было подмечено Шиперским (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], у нас нет даже “запасных частей”, чтобы заменить отказавшие по ходу дела компоненты системы.
Участники проекта
Участниками проекта (stakeholders) мы называем людей, которые заинтересованы в программном проекте. Любой человек, интересы которого так или иначе затрагиваются системой либо сам оказывающий влияние па разработку системы, является участником проекта. (Проект здесь понимается в широком смысле, как некая деловая активность, предприятие, в нашем случае — это программный проект. Прим, ред.) Участники проекта делятся на две основные группы.
Заказчики (пользователи и владельцы системы).
Разработчики (аналитики, проектировщики, программисты и т.д.).
Мы предпочитаем использовать термин заказчик (customer), а нс пользователь (user). Это различение особенно безусловно обоснованно с точки зрения разработки системы. Во-первых, заказчик — это лицо, которое платит за разработку и отвечает за принятие решений. Во-вторых, даже если заказчик не во всем прав, требования заказчика не могут быть произвольным образом изменены или отвергнуты разработчиками — любое противоречивое, невыполнимое или неправомерное требование должно быть оговорено с заказчиками.
В свете последнего утверждения мы отдаем себе отчет в том, что термин тюгеьаователъ (в значении заказчик) значительно более распространен и мы не будем в дальнейшем избегать его. Однако, мы будем воздерживаться от использования неудобного термина конечный пользователь (end-user), под которым исторически подразумевался уполномоченный паизователъ, выбранный для общения с разработчиками (вместо реального пользователя).
Информационные системы — системы социальные. Они разрабатываются людьми (разработчиками) для людей (заказчиков). Успех программного проекта определяется социальными факторами — роль технологии второстепенна. Есть немало примеров технически отсталых систем, которые работают и полезны заказчикам. Обратное, как правило, неверно. От системы, не приносящей пользы (ожидаемой или реальной), заказчик рано или поздно откажется независимо от того, насколько блестящей она является в техническом отношении.
В типичной ситуации основные причины провала программных проектов могут быть отнесены на счет участников проекта. Если рассматривать проблему провала проектов со стороны заказчиков, то эти причины выглядят следующим образом [62]:
потребности заказчиков не поняты или не полностью зафиксированы;
требования заказчиков изменяются слишком часто;
заказчики не готовы выделить достаточно ресурсов под проект,
заказчики не стремятся к сотрудничеству с разработчиками;
ожидания заказчиков нереалистичны;
система оказывается бесполезной для заказчиков.
Проекты также заканчиваются неудачей потому, что разработчики оказываются не па высоте поставленных задач. В связи с увеличением сложности ПО растет понимание того, что критическим фактором разработки становятся опыт и знания разработчиков. Хорошие разработчики могут дать решение. Высококлассные разработчики могут дать значительно лучшее решение, намного быстрее и дешевле. На эту тему существует довольно известная шутка Брукса: “Великие проекты — удел великих разработчиков” [10].
Мастерство и ответственность разработчиков являются факторами, вклад которых в достижение качества и продуктивности ПО трудно переоценить. Чтобы гарантировать успешную поставку ПО заказчику и, что более важно, обеспечить выгоды от его использования, организация-поставщик ПО должна в отношении разработчиков следовать некоторым простым правилам [10], [96]. Итак, организация-разработчик ПО должна добиваться следующего.
Нанимать лучших разработчиков.
Обеспечивать непрерывное обучение и повышать уровень образования своих разработчиков.
Поощрять обмен информацией и общение между разработчиками так, чтобы они взаимно стимулировали друг друга.
Стимулировать разработчиков, устраняя препятствия и направляя их усилия на продуктивную работу.
Создавать исключительно благоприятную рабочую атмосферу (зачастую это оказывается намного более важным, чем редкие прибавки к жалованью).
Увязывать личные цели разработчиков со стратегией и задачами организации.
Придавать особое значение коллективной работе.
Процесс
Процесс разработки ПО определяет действия и организационные процедуры, па правленные на усиление совместной работы в бригаде разработчиков с целью поставки заказчикам высококачественных программных продуктов. На модель процесса возлагаются следующие функции.
Установление порядка выполнения действий.
Определение состава и времени поставки артефактов, создаваемых в процессе разработки.
Закрепление действий и артефактов за разработчиками.
Введение критериев отслеживания хода проекта, измерение результатов и планирование будущих проектов.
Процесс разработки невозможно стандартизировать или систематизировать та ким образом, чтобы любая организация могла использовать его автоматически. Каждая организация должна разработать свою собственную модель процесса или ирис пособить некоторый настраиваемый шаблон процесса под свои нужды. К последним относится шаблон, предлагаемый компанией Rational Software Corporation, известный как Rational Unified Process [47].
Процесс, который берет на вооружение организация, должен быть увязай с ее раз витием, культурой, социальной динамикой, знаниями и опытом разработчиков, практи кой руководства, ожиданиями заказчиков, масштабами проектов и даже характером проблемных областей. Поскольку все перечисленные факторы подвержены измснени ям, организации может потребоваться ввести разнообразие в ее модель процесса и предусмотреть варианты модели для каждого отдельного программного проекта. Например, в зависимости от того, насколько разработчики хорошо знакомы с методами и средствами моделирования, в процесс может потребоваться включить специальные курсы обучения. Наверное самое большое влияние на процесс оказывает маемпшб про екта. Для небольших проектов (порядка десяти, или около того, разработчиков) формальный процесс может вообще не потребоваться. Такая небольшая бригада скорее всего способна общаться и реагировать на изменения неформально. Для более крупных проектов неформальной коммуникативной сети может оказаться недостаточно, в этом случае требуется строго определенный процесс для управляемой разработки.
Итеративный процесс разработки с пошаговым наращиванием возможностей
Современные процессы разработки ПО непременно являются итеративными (iterative) процессами с пошаговым наращиванием возможностей (incremental) системы.
Модели системы уточняются и преобразуются на этапах анализа, проектирования и реализации — в результате успешных итераций добавляются новые детали, при необходимости вводятся изменения и усовершенствования, а выпуски программных модулей с наращенными возможностями поддерживают высокий уровень удовлетворенности пользователей и обеспечивают обратную связь, необходимую для п)юдолження разработки модулей.
Одно из положений методологии Rational Unified Process звучит следующим образом: “Итеративный процесс — это процесс, направленный на управление потоком исполняемых версий ПО. Процесс с наращиванием возможностей — это процесс, направленный на непрерывную интеграцию системной архитектуры для производства этих версий, при этом каждая новая версия заключает в себе усовершенствованные возможности в сравнении с предыдущими” [8].
Успех итеративного процесса с наращиванием возможностей основывается на раннем выявлении архитектурных модулей системы. Модули должны быть примерно одинаковыми по размерам, обладать сильной внутренней связностью и иметь минимум взаимных пересечений (внешних связей). Важен также порядок реализации модулей. Некоторые модули невозможно реализовать в виде исполняемой версии, если они зависят от информации или результатов вычислений, производимых другими модулями, которые еще должны быть разработаны. Если только в основе итеративной наращиваемой разработки не лежит планирование и контроль, то в отсутствие контроля реального хода проекта процесс может превратиться в “хакерство”.
Модель технологической зрелости
Главной проблемой для любой организации, занятой производством программного обеспечения, является усовершенствование процесса разработки. Вполне естественно, что, для того, чтобы ввести в процесс усовершенствования, организация должна знать, какие проблемы связаны с существующим процессом. Одним из наиболее известных методов оценки и усовершенствования процессов является так называемая модель технологической зрелости (Capability Maturity Model— СММ) [12].
Модель СММ была разработана Институтом программной инженерии (Software Engineering Institute (SEI)) при Питтсбургском университете Карнеги-Меллона (Carnegie Mellon University) в США. Первоначально эта модель использовалась Министерством обороны США для оценки возможностей организаций в области ИТ, которые участвовали в конкурсах на получение оборонных заказов, сегодня она находит широкое применение в ИТ-индустрии как в Америке, так и за ее пределами.
По существу СММ — это анкета, которую заполняет организация, работающая в области ИТ. После анкетирования следует верификация и аттестация процесса, в результате которых организацию относят к одному из пяти уровней модели СММ. Чем выше уровень, тем более зрелым является процесс разработки ПО в организации.
Па рис. 1.1 определены уровни, даны краткие описания основных особенностей каждого из уровней и приведены основные сферы улучшения процесса, необходимые для достижения организацией более высокого уровня технологической зрелости.
Артур (Arthur) [3] называет уровни зрелости “лестницей, ведущей к совершенству в области ПО”. Пять ступенек на этой лестнице соответствуют хаосу, управляемому проекту, применению методов и средств организации процесса, измерению процесса и непрерывному повышению качества.
Как показывает опыт, па переход с одного уровня шкалы технологической зрелости на другой уходит несколько лет. Большинство организаций находятся на уровне 1, некоторые — па уровне 2; известно очень немного организаций, находящихся на 5-м уровне. Приводимые ниже вопросы показывают, насколько трудновыполнима эта задача. Организация, которая стремится достичь 2-го уровня, должна добиться положительных ответов па все приведенные ниже вопросы (а также на некоторые другие) [62].
Непредсказуемый и неупорядоченный процесс, зависящий от текущих исполнителей
Рис. 1.1. Уровни зрелости процесса по модели СММ
Имеется ли в организации канал управления и отчетности по функции обеспечения качества ПО, отдельный от управления проектами по разработке ПО?
Введена ли для каждого проекта функция конфигурационного управления ПО, которая затрагивает его разработку?
Использует ли руководство формальный процесс для анализа каждой программной разработки прежде, чем взять на себя договорные обязательства?
Используется ли для составления календарного плана разработки ПО формальная процедура?
Применяются ли формальные процедуры для оценки затрат на разработку ПО?
Собирается ли статистика в отношении программного кода и ошибок, выявленных при тестировании?
Имеется ли в распоряжении высшего руководства механизм для регулярного анализа состояния проектов по разработке ПО?
Используется ли определенный механизм для контроля изменений требований к ПО?
1.1.3.3. Стандарт ISO 9000
Помимо СММ существуют и другие модели усовершенствования процесса созда ния ПО. Особый интерес представляет серия стандартов по качеству ISO 9000, разработанная Международной организацией по стандартизации (International Organization for Standardization). Стандарты ISO этой серии применяются для управления кп чеством и определения процесса производства качественной продукции. Стандарты
носят общий характер — они применимы для любой отрасли и всех видов бизнеса, включая разработку ПО.
В основе серии стандартов ISO 9000 лежит предположение о том, что если процесс организован надлежащим образом, то и результат процесса (товар или услуга) также будет обладать надлежащим качеством. “Цель управления качеством заключается в производстве качественных товаров за счет того, чтобы сделать качество неотъемлемым свойством товара, а не проверки того, насколько оно присуще товару” [78].
Возвращаясь к нашему предыдущему рассмотрению особенностей процесса разработки ПО, заметим, что стандарты ISO не навязывают конкретного процесса и не уточняют его характеристик. Стандарты дают модель того, что должно быть достигнуто, однако не говорят о том, как именно должна осуществляться та или иная деятельность. Организация, которая стремится получить сертификат ISO (это также называется регистрацией) должна рассказать, что она делает; доказать, что слова у нее не расходятся с делом; и показать, чего она уже достигла [78].
Своеобразной “лакмусовой бумагой”, позволяющей проверить, насколько организация заслуживает сертификата ISO, может служить ее способность создать качественный товар или обеспечить качественное обслуживание даже в том случае, если заменить весь персонал. С этой целью необходимо оформить документально и зафиксировать все виды своей деятельности. Для каждого вида деятельности должна быть определена письменная процедура, включая действия, которые необходимо выполнить в случае нарушения процесса или жалоб клиента.
Так же, как в случае модели СММ, сертификат ISO может быть официально предоставлен только после аудита, проведенного на месте регистрационным бюро ISO. По- лобные аудиты затем повторяются через определенное время на регулярной основе. Организации вынуждены проходить через подобную систему из-за давления конкурентных факторов, обусловленных требованиями со стороны потребителей, чтобы поставщики товаров и услуг были сертифицированы.
1.1.4. Язык и средства моделирования
Участники проекта и процесс составляют два элемента “треугольника", обеспечивающего успех программного проекта. Третий элемент состоит из языка и средств моделирования. Подлежащие моделированию артефакты необходимо выразить (язык) и документально зафиксировать (средства).
Разработчикам необходим язык для построения как визуальных моделей, так и моделей других типов, и обсуждения их с заказчиками и коллегами. Язык должен позволять строить модели на различных уровнях абстракции для представления предлагаемых решений на различных уровнях детализации.
Язык должен обладать мощной визуальной составляющей согласно известной поговорке о том, что “лучше один раз увидеть, чем сто раз услышать”. Язык моделирования должен также обладать мощной декларативной семантикой, т.е. должен позволять «фиксировать “процедурное” значение в форме “декларативного” предложения. Иначе говоря, мы должны иметь возможность сказать, “что” именно необходимо сделать, а не распространяться о том, “как ” это должно делаться.
Кроме того, разработчикам необходимы средства для автоматизированного проектирования и создания программ или так называемые CASE-средства (Computer- Assisred Software Engineering — CASE). CASE-средства позволяют хранить и получать доступ к моделям через центральный репозиторий, а также манипулировать этими
моделями на экране компьютера в графическом и текстовом ртжимах. В идеале репозиторий должен обеспечивать одновременный доступ многих пользователей (многих разработчиков) к моделям. Ниже приводится перечень типичных функций GASE- репозитория.
Координация доступа к моделям.
Помощь в организации взаимодействия между разработчиками.
Хранение нескольких версий моделей.
Идентификация различий между версиями.
Возможность совместного использования одних и тех же концептов в различных моделях.
Проверка непротиворечивости и целостности моделей.
Генерация проектных отчетов и документов.
Генерация структур данных и программного кода (конструирование ПО).
Генерация моделей по существующей реализации (реконструкция ПО) и т.д.
Следует заметить, что зачастую программа, сгенерированная с помощью CASE средств, представляет собой на самом деле всего лишь скелет программы — вычисли тельный алгоритм, который необходимо дорабатывать программисту как при обыч ном программировании.
UML
“UML (Unified Modeling Language — унифицированный язык моделирования) — э го визуальный язык моделирования общего назначения, который используется для спецификации, визуализации, конструирования и документирования артефактов программ ной системы" [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 позволяют моделировать статику (структуру) и динамике (поведение) системы. Система представляется в виде взаимодействующих объектов (программных модулей), которые реагируют на внешние события. Действия объектов позволяют выполнить определенные задачи или получить клиентам (пользователям)
системы некоторый полезный результат. Отдельные модели отображают определенные стороны системы и пренебрегают другими сторонами, которые охватывают другие модели. Взятые в комплексе модели обеспечивают полное описание системы.
Модели, создаваемые с помощью языка UML, можно разделить на три группы.
Статические модели (описывают статические структуры данных).
Модели поведения (описывают взаимодействие объектов).
Модели изменения состояний (описывают допустимые состояния системы, которые она принимает с течением времени).
UML также содержит несколько архитектурных конструкций, которые позволяют придать системе модульную структуру, используемую в процессе итеративной и наращиваемой разработки.
CASE-средства и совершенствование процесса
Совершенствование процесса — это нечто большее, чем просто введение новых методов и средств. В действительности, введение новых методов и средств в организации, находящейся на низком уровне зрелости процесса разработки, может принести больше вреда, чем пользы.
Подходящий пример — CASE-технологии. Интегрированные CASE-средства позволяют нескольким разработчикам взаимодействовать и совместно использовать проектную информацию для выработки новых проектных артефактов. Чтобы воспользоваться преимуществами этой технологии, бригада разработчиков должна подчиняться определенным правилам, поскольку CASE-средства налагают на процессы некоторые ограничения. Но если бригада разработчиков не настолько квалифицированна, чтобы усовершенствовать процесс разработки, чрезвычайно маловероятно, чтобы она смогла воспринять процесс, диктуемый CASE-средствами. В результате потенциальные возможности роста продуктивности и качества, которые обещает новая технология, так и не будут реализованы.
Рассмотренные выше особенности применения CASE-средств не должны натолк- н\ть вас на мысль, что CASE-технология — “рискованное дело". Она может и не дать вам ожидаемых выгод, если вы пытаетесь использовать ее для того, чтобы направлять работу всей бригады разработчиков, а бригада не готова следовать нужному процессу. Однако, те же методы и CASE-средства безусловно могут обеспечить повышение личной продуктивности и качества работы отдельных разработчиков, которые используют технологию на своих локальных рабочих станциях. Моделировать программные артеЦ>акты с помощью карандаша и бумаги уместно только в аудитории, но никак ни при работе над реальным проектом.
Планирование разработки системы
Проекты по разработке информационных систем (ИС) должны быть заранее спланированы. ИС необходимо идентифицировать, классифицировать, ранжировать и выбирать для первоначальной разработки, для усовершенствования или, возможно, для ликвидации. Вопрос состоит в следующем: “Какие технологии ИС и приложения принесут наибольшие деловые выгоды?” В идеале решение, которому необходимо следовать, должно базироваться на бизнес-стратегии и тщательном и методичном пла- ппроваиии [5],[37], [51].
Бизнес-стратегию можно определить посредством различных процессов, известных как стратегическое тигкирооание^ бизнес-моделирование, реинжиниринг бизнес-процессов, стратегическое увязывание, управление информационными ресурсами и т.п. Мы не ставим целью пояснять различия между названными подходами. Достаточно сказать, что все эти подходы связаны с изучением фундаментальных бизнес-процессов в организации, целью которых является определение долгосрочного видения бизнеса с последующим назначением приоритетов различным проблемам ведения бизнеса, которые могут быть разрешены с помощью информационной технологии (ИТ).
При этом существует немало организаций — в особенности это относится к небольшим организациям, которые не имеют отчетливой стратегии ведения бизнеса. Подобные организации скорее всего принимают решение о развитии ИС. просто выявляя наиболее насущные деловые проблемы, которые требуют немедленного решения. При изменении внешней бизнес-среды или внутренних условий ведения бизнеса существующая ИС снова подлежит модификации. Хотя этот подход обладает очевидными недостатками, он позволяет небольшим организациям быстро перестроиться в соответствии с текущей ситуацией либо извлечь выгоду из представившихся возможностей, либо дать отпор новым угрозам.
Крупные организации не могут позволить себе постоянные изменения в направлении ведения бизнеса. В действительности они зачастую диктуют направление деятельности другим организациям, работающим в той же сфере бизнеса, а также в определенной мере могут формировать среду для своих повседневных нужд. Однако, крупные организации должны внимательно вглядываться в будущее: использовать плановый подход при выборе проектов, связанных с разработкой. Как правило, э i о масштабные проекты, на выполнение которых требуется много времени. Они слишком громоздки, чтобы их можно было легко изменить или заменить, и должны быть способны адаптироваться или даже быть устремлены навстречу будущим возможностям и угрозам.
Существует много способов планирования разработки систем. Один из традиционных подходов получил название SWOT (Strengths, Weaknesses, Opportunities, Threats - сильные стороны, слабые стороны, благоприятные возможности, угрозы). Еще одна популярная стратегия базируется на модели VCM (Value Chain Model — модель цепочек ценности). Более современные варианты подходов к разработке бизнес-стратегий известны как BPR (Business Process Reengineering— реинжиниринг бизнес-процессов). Информацию, необходимую для деятельности организации, также оценивают с использованием так называемых проектных шаблонов для ISA (Information System Architecture — архитектура информационных систем). Подобные проектные шаблоны можно получить по аналогии из описательных схем, успешно зарекомендовавших себя в дисциплинах, отличных от ИТ (например, в строительной промышленности).
Все подходы к планированию разработки систем обладают одним общим знамена телем — они направлены скорее на достижение эффективности (делать то, что нужно), чем продуктивности (делать так, как нужно). Наиболее рациональное решение неверной проблемы немногого стоит!
Подход SWOT
Подход SWOT позволяет идентифицировать, классифицировать, ранжировать и выбирать проекты по разработке ИС таким образом, чтобы они были увязаны с силь-
ными и слабыми сторонами организации, а также возможностями и угрозами. Это подход сверху-вниз, применение которого начинается с определения миссии организации.
Формулировка миссии фиксирует уникальный характер организации и определяет ее видение того, где она хотела бы оказаться в будущем. Верно сформулированная миссия отводит главное место потребностям клиентов, а не товарам или услугам, которые предоставляет организация.
Формулировка миссии и разрабатываемая на ее основе бизнес-стратегия учитывают то, какими внутренними сильными и слабыми сторонами обладает компания в таких областях, как управление, производство, кадровое обеспечение, финансы, маркетинг, исследования и разработка и т.д. Эти сильные и слабые стороны должны быть детально обсуждены и согласованы, после чего им назначаются приоритеты. Преуспевающие организации способны в любой момент идентифицировать текущий набор сильных и слабых сторон, которые направляют разработку их бизнес-стратегий.
Выявление внутренних сильных и слабых сторон компании — необходимое, но недостаточное условие для успешного делового планирования. Организация функционирует не в вакууме — ее деятельность зависит от внешних экономических, социальных, политических и технологических факторов. Она должна знать о внешних благоприятных возможностях, из которых необходимо извлечь выгоду, а также о внешних угрозах, которых следует избегать. Этими факторами организация не в состоянии управлять, однако осведомленность в отношении их играет существенную роль при определении целей и задач организации.
На любом заданном отрезке времени организация преследует одну или очень небольшое количество целей Цели обычно имеют долговременный характер (три-пять лет), а иногда относятся к “вечным проблемам". К типичным примерам целей относятся повышение уровня удовлетворенности потребителей, введение новых видов услуг. преодоление конкурентных угроз, усиление контроля над поставщиками и тд. Каждая стратегическая цель должна быть связана с определенными задачами, которые обычно принимают форму годовых заданий. Например, цель “повысить уровень удовлетворенности потребителей” может поддерживаться задачей более быстрого выполнения заказов клиентов — скажем, в течение двух недель.
Цели и задачи требуют выработки стратегий управления и определенной политики в отношении реализации этой стратегии. Подобные методы управления позволяют привести в соответствие организационные структуры, распределить ресурсы и определить проекты, связанные с разработкой, в том числе, информационных систем.
Подход VCM
Метод ценностных цепочек —■ VCM — позволяет оценить конкурентные преимущества с помощью анализа всей цепочки видов деятельности в организации, начиная от получения сырья до конечной продукции, продаваемой и доставляемой потребителям. Метафора цепочки усиливает то положение, что единственное слабое звено приводит к разрыву всей цепи.
Модель служит цели уяснения того, какая конфигурация цепочки ценности сулит наибольшие конкурентные преимущества. Проекты по разработке ИС могут впоследствии указать на те сегменты, операции, каналы распределения, маркетинговые подходы и т.д., которые позволяют завоевать наибольшее конкурентное преимущество.
В первоначальном варианте метода VCM [63] организационные функции были разделены на основные виды деятельности и вспомогательные виды деятельности. Основ-
ные виды деятельности создают или добавляют ценность конечному продукту. Они разделяются на пять последовательных этапов: (1) входящее снабжение, (2) обработка, (3) исходящее снабжение, (4) сбыт и маркетинг, (5) обслуживание.
Поддерживающие виды деятельности не добавляют ценности, по крайней мере, прямо. Они также играют существенную роль, но не “обогащают” продукт. Поддер живающие виды деятельности включают. (1) администрацию и инфраструктуру (2) управление кадрами, (3) исследования и разработку и — наверное, это не удивителн,- но — разработку ИС.
Хотя модель VCM представляет собой полезный инструмент для планирования разработки ИС, вездесущая компьютеризация может способствовать переменам в способах ведения бизнеса, что, в свою очередь, создает конкурентные преимущества. Другими словами, ИТ может преобразовать ценностные цепочки организации. Таким образом, межде ИТ и моделью VCM может быть установлена положительная обратная связь.
Портер (Porter) и Миллар (Millar) [64] выделяют пять шагов, которые должна пред принять организация, чтобы воспользоваться преимуществами, предоставляемыми ИТ.
Оценить информационную емкость продуктов и процессов.
Оценить роль ИТ в отраслевой структуре.
Выявить и ранжировать способы, с помощью которых ИТ создает конкурен т ное преимущество.
Рассмотреть, каким образом ИТ может создать новое направление в бизнесе.
Разработать план, направленный на извлечение выгод от использования ИТ.
Подход BPR
Подход к планированию разработки ИС с использованием методов реинжипирип га бизнес-процессов (BPR-методов) основан на допущении, что современные организации должны реконструировать себя и отказаться от функциональной декомпозиции, иерархических структур и принципов приоритетности повседневных нужд, которые они сегодня используют.
Рассматриваемая концепция была введена в 1990 году Хаммером (Hainmei) и Девенпортом (Davenport) [30], и Шортом (Short) [19] и сразу обратила па себя внимание, вызвав полемику. Расширенное описание метода BPR можно найти в книгах его основателей [32], [18].
Сегодня большинство организаций имеют структуру с вертикальным подчинением подразделений, сосредоточенных на функциях, товарах или регионах. Эти структуры и методы работы прослеживаются вплоть до восемнадцатого века и берут свое начало в принципе разделения труда и последующей фрагментации работы, сформулированном еще Адамом Смитом. Никто из работников или подразделений не отвечает за бизнес-процесс, который определяется как “...совокупность видов деятельности, получающих на входе один или несколько типов ресурсов и создающих на выходе продукцию, представляющую ценность для потребителя” [32].
Методология реинжиниринга бизнес-процессов ставит под сомнение индустриальные принципы Смита разделения труда, иерархического управления и экономии на масштабах. В современном мире организация должна быть способна адаптироваться к быстрым изменениям рынка, новым технологиям, конкурентным факторам, требованиям потребителей и т.д.
Жесткие организационные структуры, в которых бизнес-процессы разорваны между многими подразделениями, устарели. Организации должны сосредоточиваться на бизпес-процессах. а не на отдельных задачах, заданиях, специалистах и функциях подразделений. Эти процессы разделены по горизонтали между видами деятельности и завершаются в точках контакта с потребителями. “Наиболее видимое различие между предприятием, ориентированным на бизнес-процессы, и традиционной организацией состоит в существовании у каждого из процессов “хозяина” [33].
Основная цель реинжиниринга бизнес-процессов состоит в радикальной реконструкции бизнес-процессов в организации (поэтому подход BPR зачастую называется реконструкцией или перепроектированием процессов). Бизнес-процессы необходимо идентифицировать, хорошо наладить и усовершенствовать. Поведение процессов фиксируется в виде диаграмм понижав работ ^uuorkjlou) diagrams) и изучается в рамках дисциплины “Анализ потоков работ". Потоки работ охватывают потоки событий, документов и информации в рамках бизнес-процессов и могут использоваться для подсчета времени, ресурсов и финансовых средств, необходимых для этих видов деятельности.
Основное препятствие на пути реализации BPR-подхода в организации лежит в необходимости внедрения горизонтального процесса в традиционную вертикальную с труктуру управления Серьезная инициатива по внедрению BPR-подхода требует переключения организации на проектные бригады как основные организационные единицы. Эти бригады отвечают за один или более сквозных бизнес-процессов.
Иногда радикальные изменения неприемлемы. Традиционные структуры не могут бы та изменены в одночасье. Радикальные шаги могут встретить сопротивление, и по- тенцпальпые выгоды от внедрения BPR-подхода могут быть подвергнуты риску. В данных обстоятельствах организация все же может выиграть от моделирования биз- пег-процессов и попыток просто усовершенствовать их, а не подвергать полной переделке. Гермин “усовершенствование бизнес-процессов” (Business Process Improvement -*- BPI) используется для характеристики подобного начинания [1].
После того, как бизнес-процесс определен, “хозяева" процесса могут потребовать поддержки со стороны ИТ с целью дальнейшего повышения продуктивности этих процессов. Результирующий проект по разработке ИС должен сосредоточиваться на реализации выявленных потоков работ. Сочетание эффективности, получаемой от применения BPR-подхода, с продуктивностью, являющейся результатом применения ИТ. может привести к поразительному улучшению всех современных показателей деятельности организации, таких как уровень качества и обслуживания, скорость, затраты, цена, конкурентные преимущества, гибкость и т.д.
Подход ISA
В отличие от уже описанных подходов подход с использованием унифицирован- пой схемы для архитектуры информационных систем (Information Systems Architecture — ISA) опюваи на проектировании снизу-вверх. Этот подход предлагает нейтральную архитектурную концептуальную схему для проектных решений по созданию ИС., ко торая может подходить для различных бизнес-стратегий. По существу, подход с использованием ISA не включает методологии планирования разработки систем. Он просто предлагает схему, которая может служить в качестве рычага для достижения це лей большинства бизнес-стратегий.
Подход на основе схемы ISA был впервые введен Захманом (Zachman) в его плодотворной статье [97] и впоследствии расширен Сова (Sowa) и Захманом [82]. Незначительно видоизмененный вариант оригинальной статьи вновь был опубликован Захманом 1981.
Схема ISA представляет собой таблицу из тридцати ячеек, организованных в виде пяти строк (помеченных от 1 до 5) и шести столбцов (помеченных от А до F). Строки представляют различные точки зрения (или ракурсы}, используемые при конструировании сложных инженерных продуктов, таких как информационные системы. Эти точки зрения принадлежат пяти основным “игрокам" — пяти участникам разработки ИС.
Планировщик (определяет границы системы).
Владелец (определяет концептуальную модель предприятия).
Проектировщик (задает физическую модель системы).
Конструктор (обеспечивает детализированное технологическое решение).
Субподрядчик (поставляет компоненты системы).
Шесть столбцов представляют шесть различных описаний или архитектурных моде лей, с которыми “играет” каждый участник. Подобно точкам зрения описания значи тельно отличаются между собой, но в то же время они внутренне связаны между собой. Описания призваны дать ответ на шесть вопросов в отношении моделируемых сущностей, которыми задается каждый из участников.
А. Что составляет сущность (т.е., в случае ИС, данные).
Как сущность функционирует (т.е. бизнес-процессы).
/Эс сущность расположена (т.е. расположение обрабатывающих компонентов).
Кто работает с сущностью (т.е. пользователи).
Когда с сущностью что-то происходит (т.е. распределения событий и состояний во времени).
Почему сущность существует (т.е. мотивация предприятия).
Комбинация точек зрения и описаний, представленных в тридцати ячейках таблицы Захмана, представляет собой мощную систематизацию, на основе которой мож но выстроить полную архитектуру для разработки ИС. Расположенные по вертикали ракурсы могут отличаться степенью детализации, но, что более важно, они отличают ся по существу и используют различные представления модели. Различные модели отражают различные взгляды участников. Аналогично расположенные по горизон тали описания подготовлены, исходя из различных соображений. Каждое из этих описаний призвано ответить на один из шести вопросов.
Наиболее привлекательной стороной подхода ISA является то, что он предлагает схему, которая, вполне вероятно, может оказаться достаточно гибкой для адаптации к будущим изменениям в условиях ведения бизнеса и в ресурсах, которыми располагает предприятие. Это является следствием того, что решения на основе ISA не базируют ся на какой-либо определенной бизнес-стратегии. Это просто схема для полного они сания ИС. Сама схема получена на основании опыта, накопленного более устоявшимися дисциплинами, некоторые из них насчитывают тысячи лет (например, класси ческая архитектура).
1.2.5. Системы для трех уровней управления
Планирование разработки системы связано с представлением о наличии в организации трех уровней управления.
Стратегического.
Тактического.
Оперативного.
Эти три уровня организационного управления характеризуются собственным уровнем принимаемых решений, различным набором необходимых приложений ИС и специфическими требованиями к поддержке со стороны ИТ-подразделений. Одна из задач, возникающих при планировании разработки системы, состоит в определении комплекса приложений ИС и ИТ-решений, который является наиболее эффективным для организации в определенный момент времени. В табл. 1.1 определены связанные с установлением соответствия приложений ИС и ИТ-решений уровню принимаемых решений [40], [72].
Таблица 1.1. Поддержка различных уровней принятия решений со стороны ИС и ИТ
Уровень принятия решений
Направленность принимаемых решений
Типичные приложения ИС
Типичные ИТ-решения
Стратегический
Стратегии, под- де ржи вающ ие долгосрочные цели организации
Анализ рынка и сбыта; планирование разработки товаров; оценка эффективности
Добыча данных;
управление знаниями
Тактический
Стратегии, поддерживающие краткосрочные задачи и распределение ресурсов
Анализ бюджета; прогнозирование фонда зарплаты; планирование запасов; обслуживание потребителей
Хранилища данных; анализ данных; электронные таблицы
Оперативный
Поддержка повседневной детальности персонала и производство
Выплата жалованья;
выписка счетов; закупки; бухгалтерский учет
Базы данных; обработка транзакций; генераторы приложений
Реализуемые ИС-приложения и ИТ-решения, которые способны обеспечить наибольшие выгоды организации, относятся к стратегическому уровню. Однако эти решения наиболее трудно реализовать— они используют “пограничные” технологии и требуют очень квалифицированного и специализированного проектирования. Тем не менее, именно эти системы способны обеспечить организации конкурентное преимущество на рынке.
11а противоположном конце шкалы располагаются системы, поддерживающие оперативный уровень управления. Эти системы отличаются однообразием действий и процедур, используют традиционные технологии баз данных и зачастую собираются из готовых к применению пакетных программных решений. Данные системы неперспективны с точки зрения обеспечения конкурентного преимущества, однако без них opt аиизация не способна функционировать надлежащим образом.
Любая современная организация имеет в своем распоряжении полный комплект систем оперативного управления, но только организации, которые достигли больших высот в искусстве управления, обладают интегрированным набором приложений ИС стратегического уровня. Основная технология, которая используется для хранения и обработки данных в процессе принятия высокоуровневых стратегических и тактических решений, известна как технология хранилищ, данных [47].
Этапы жизненного цикла программного обеспечения
Разработка программного обеспечения подчиняется определенному жизненному циклу (lifecycle). Жизненный цикл (ЖЦ) — это упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке ПО. Процессы и методы — это механизмы реализации жизненного цикла. Жизненный цикл определяет этапы, так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сворачивания.
Жизненный цикл разработки ПО может быть представлен с различной степенью детализации этапов. На укрупненном уровне ЖЦ может включать только три этапа.
Анализ.
Проектирование.
Реализация.
Этап анализа (analysis phase) концентрируется на системных требованиях. Требования определяются и специфицируются. Осуществляется разработка и интеграция функциональных моделей и моделей данных для системы. Кроме того, фиксируются нефункциональные требования и другие системные ограничения.
Этап проектирования (design phase) разделяется на два основных подэтапа: архитектурное и детализированное проектирование. В частности, проводится уточнение конструкции программы для архитектуры клиент/сервер, которая интегрирует объекты пользовательского интерфейса и базы данных. Поднимаются и фиксируютс я вопросы проектирования, которые влияют на понятность, приспособленность к сопровождению и масштабируемость системы.
Этап реализации (implementation phase) включает написание программ клиентских приложений и серверов баз данных. Акцент делается на итеративных процесс ах реализации с наращиванием возможностей системы. Успех поставки программного продукта не в последнюю очередь определяется циклической разработкой. Циклическая разработка (round-trip engineering) характеризуется периодическим возвратом от реализации клиентских приложений и серверов баз данных к проектным моделям и обратно.
Коротко говоря, анализ указывает на то, что делать, проектирование — на то, как с помощью имеющейся технологии сделать это “что”, а реализация воплощает задуманное на предыдущих этапах в виде осязаемого программного продукта, поставляемого заказчику.
На детализированном уровне ЖЦ можно разделить на следующие семь этапов.
Установление требований.
Спецификация требований.
Проектирование архитектуры.
Детализированное проектирование.
Реализация.
Интеграция.
Сопровождение (и окончательное сворачивание).
Некоторые авторы также рассматривают в качестве двух дополнительных этапов планирование п тестирование. По нашему мнению, эти два важных вида деятельности не являются отдельными этапами ЖЦ, поскольку охватывают весь ЖЦ в целом. План управления проектом по разработке ПО составляется в самом начале процесса, существенно уточняется после этапа спецификации и продолжает развиваться в течение всего оставшегося ЖЦ. Аналогично тестирование отличается наивысшей интенсивностью после этапа реализации, однако оно также применимо к программным артефактам, вырабатываемым на всех остальных этапах.
Этап установления требований
Котонья (Kotonya) и Соммервилль (Sommerville) [46] определяют требование (requirement) как “формулировку сути системного сервиса или ограничения’’. Формулировка сути сервиса характеризует поведение системы по отношению к отдельным пользователям или ко всему контингенту пользователей. В последнем случае описание сервиса фактически служит определением бизнес-правгиш, которое должно выполняться всегда (например, “двухнедельная зарплата выплачивается в среду'”). Формулировка сути сервиса может быть связана с некоторым вычислением, которое должна произвести система (например, “вычислить комиссионные продавца на основе объема продаж па прошлую среду' с использованием конкретной формулы’’).
Формулировка ограничения выражает ограничивающее условие на поведение системы или на разработку' системы. Примером первого ограничения может быть ограничение на безопасность: “только непосредственные руководители могут обращаться к информации о зарплате их персонала”. Примером последнего типа может быть формулировка: “мы должны использовать средства разработки компании Sybase.”
Обратите внимание, что иногда различие между формулировкой ограничения на поведение системы и формулировкой услуги на основе бизнес-правила размыто. Это не составляет проблемы в том случае, если все требования идентифицированы и дублирование исключено.
Задачей этапа определения требований является определение, анализ и обсуждение требований с заказчиками. На этом этапе применяются различные методы сбора информации от заказчиков. Это и исследование концепции с помощью структурированных и неструктурированных интервью пользователей, анкеты, изучение документов и форм. видеозаписи и т.д. Последним методом, применяемым на этапе определения требований. является быстрая разработка прототипа (rapid prototyping) решения, так что требования, вызывающие затруднения, могут быть прояснены, что позволяет Iобежать недоразумений.
Анализ требований включает переговоры между разработчиками и заказчиками. Этот шаг необходим для исключения противоречивых и дублирующихся требований, а также согласования проектного бюджета и сроков.
Результатом этапа установления требований является документ, содержащий изложение требовтгий (requirements document). Это большей частью текстовый документ с некоторыми неформальными диаграммами и таблицами. В этот документ, как правило, не
включаются формальные модели за исключением, может быть, некоторых простых и широко известных видов нотации, которые легко могут быть восприняты заказчиками 11 могут облегчить взаимопонимание между разработчиками и заказчиками.
Этап спецификации требований
Этап спецификации требований начинается с того момента, когда разработчики приступают к моделированию требований с использованием определенного метода (например, такого как UML). CASE-средства используются для ввода, анализа и документирования модели. В результате документ описания требований дополняется графическими моделями и отчетами, сгенерированными с помощью CASE-средств. По существу, документ, излагающий требования, заменяется документом, содержащим спецификацию требований (specifications document, иногда он обозначается жаргонным словечком specs).
В рамках объектно-ориентированного анализа в качестве основных методов спеин фикации требований используются два типа диаграмм: диаграммы классов (class diagrams) и диаграммы прецедентов (use case diagrams). Эти методы позволяют разрабатывать спецификации данных и функций. Обычно документ, содержащий спецификацию требований, включает также описание других видов требований. Среди атрибутов системы, требования к которым могут быть приведены в спецификации, относятся, например, производительность, пригодность к использованию (или практичность), пригодность к сопровождению, безопасность, политические и юридические требования, и даже “впечатления и ощущения от использования программы” (“look and feel”).
Модели спецификации могут и должны перекрываться. Это позволяет рассмофегь предлагаемое решение под разными углами, выделяя и анализируя различные аспекты решения. Кроме того, это дает возможность проверить непротиворечивость и полнота требований.
В идеале модели спецификаций должны быть независимы от программной и аппаратной платформ, на которых должна разворачиваться система. Учет особенностей программной и аппаратной платформ накладывает жесткие ограничения на словарь (а следовательно — и на выразительность) языка моделирования. Более того, словарь может быть труден для понимания заказчиками и, таким образом, препятствовал, общению разработчиков и заказчиков.
Тем не менее, некоторые формулировки ограничений могут фактически навязывать разработчикам необходимость рассмотрения особенностей программного и аппаратного обеспечения. Более того, сами заказчики могут быть выразителями требований относительно определенной технологии или даже требовать применения определенной технологии. Отсюда вывод: при возможности следует избегать рассмотрения особенностей программного и аппаратного обеспечения на этапе составления спецификации системы.
Этап проектирования архитектуры
Документально оформленная спецификация похожа на контракт между разработчиками и заказчиками на поставку программного продукта. В ней перечисляются все требования, которым должен удовлетворять программный продукт. Теперь спецификации передаются в руки системных архитекторов и проектировщиков для разрабол ки детализированных моделей системной архитектуры и ее внутренних механизмов.
Проект выполняется в терминах программных и аппаратных платформ, на которых предстоит реализовать систему.
Описание системы в терминах составляющих ее модулей называется архитектурным проектированием (architectural design). Проект архитектуры включает выбор стратегических решений по клиентской и серверной частям системы.
Описание внутренних механизмов каждого модуля (прецедентов) называется детализированным проектированием (detailed design). Детализированный проект включает подробные алгоритмы и структуры данных для каждого модуля. Такие алгоритмы и структуры данных приспосабливаются ко всем ограничениям, связанным с базовой платформой реализации. Эти ограничения могут как усиливать основную архитектурную концепцию, так и препятствовать ее воплощению.
Архитектурное проектирование связано с выбором стратегии решения и разбивкой системы на модули. Стратегия решения (solution strategy) требует разрешения вопросов, касающихся клиентской (пользовательский интерфейс) и серверной (база данных) частей системы, а также всевозможного ПО промежуточного уровня (middleware), необходимого для связывания клиента и сервера. Выбор основных строительных блоков (модулей) относительно независим от стратегии решения, однако детализированный проект модулей должен соответствовать выбранному решению по архитектуре клиент/сервер.
Зачастую модели архитектуры клиент/сервер расширяются до так называемой трехзвенной архитектуры (three-tier architecture), в которой логика приложения составляет отдельный слой. Среднее звено представляет собой слой логики и в этом качестве может поддерживаться или не поддерживаться отдельным аппаратным обеспечением. Логика приложения — это процесс, который может выполняться на клиентской машине или на сервере, т.е. он скомпилирован в виде клиентского или серверного процесса и реализован как библиотека DLL (Dynamic Link Library — динамически подключаемая библиотека), интерфейс API (Application Programming Interface — интерфейс прикладного программирования), RPC-вызовов (Remote Procedure Calls— удаленный вызов процедуры) ит.д. [57].
Этап детализированного проектирования
Архитектурный проект описывает программный продукт с точки зрения составляющих его модулей. Детализированный проект описывает каждый модуль. При разработке типичной ИС модули реализуются либо в виде клиентской компоненты, либо серверной компоненты. За первые отвечают проектировщики прикладной части, вторую должны разрабатывать проектировщики баз данных.
Проект пользовательского интерфейса (клиентского приложения) должен соответствовать принципам проектирования GUI-интерфейса, установленным разработчиком конкретного GUI-интерфейса (Windows, Motif, Macintosh). Подобные принципы обычно доступны в WWW как часть электронной документации GUI- интерфейса (см. например, [92]).
Основной принцип объектно-ориентированного проектирования GUI-интерфейс а состоит в том, что управление приложением является прерогативой пользователя, а пе программы. Программа реагирует на случайные события, источником которых является пользователь, и предоставляет необходимый программный сервис. Остальные принципы проектирования GUI-интерфейса являются следствием этого факта. (Конечно, принцип “контроль является прерогативой пользователя” не следует при-
нимать буквально—программа по-прежнему может проверять права пользователя н запретить некоторые пользовательские действия.)
Проект базы данных определяет объекты сервера базы данных — скорее всего, реляционной (или, возможно, объектно-реляционной). Часть этих объектов представляет собой контейнеры данных (таблицы, взгляды и т.д.). Другие объекты являются процедурами (хранимые процедуры, триггеры и т.д.)
Этап реализации
Реализация информационной системы включает инсталляцию приобретенного ПО и программирование ПО, разрабатываемого под заказ. Кроме того, реализация подразумевает осуществление некоторых других важных мероприятий, таких как загрузка тестовых и производственных баз данных, тестирование, обучение пользователей, вопросы, связанные с аппаратным обеспечением, и т.д.
Типичная организация бригады по реализации проекта ПО предполагает разделение программистов на две группы: одну, ответственную за программирование клиентских приложений, и другую, которая должна отвечать за программирование сервера баз данных. Клиентские программы реализуют оконный интерфейс, логику приложений и при необходимости вызывают программы баз данных (хранимые процедуры). Ответственность за непротиворечивость баз данных и корректность транзакций лежит на серверных программах.
Как раз в духе итеративной и наращиваемой разработки проект пользовательских интерфейсов иногда подвергается значительным изменениям на этапе реализации. Прикладные программисты могут предпочитать — в зависимости от вида реализуемых диалоговых окон — следовать принципам разработки, предлагаемым поставщиком GUI-интерфейса, продвигать программирование или повышать продуктивность работы пользователей.
Аналогично реализация сервера баз данных может вызвать изменения в проектных документах. Непредвиденные проблемы, связанные с базами данных, трудности при программировании хранимых процедур и триггеров, вопросы параллелизма, интеграция с клиентскими процессами, настройка производительности и т.д. — вот перечень только некоторых причин, которые могут повлечь за собой необходимость модификации проекта.
Этап интеграции
Наращиваемая разработка предполагает наращиваемую интеграцию программных модулей. Эта задача не так проста, как может показаться на первый взгляд. Для больших систем интеграция отдельных модулей может потребовать больше времени и усилий, чем любой из более ранних этапов ЖЦ, включая реализацию. Еще Аристотель заметил, что целое больше простой суммы частей.
Интеграция модулей должна быть тщательно спланирована в самом начале жизненного цикла ПО. Программные компоненты, подлежащие отдельной реализации, должны быть идентифицированы на ранних стадиях анализа системы. К этому вопросу необходимо постоянно возвращаться, уточняя детали во время архитектурного проектирования. Порядок реализации должен позволять как можно более плавную наращиваемую интеграцию.
Основная трудность, связанная с наращиваемой интеграцией, заключается в существовании взаимных обратных зависимостей между модулями. Хороший проек т сис-
темы отличается минимальной связностью (coupling) модулей. Тем не менее, время от времени два модуля оказываются зависимы друг от друга, так что ни один из них не может функционировать изолированно.
Что делать, если необходимо поставить один из модулей еще до того, как другой готов к применению? Ответ состоит в написании специальной программы для временного “заполнения бреши” так, чтобы все модули оказались интегрированными. Программная процедура, предназначенная для имитации работы отсутствующего модуля, называется заглушкой (stubs).
В отличие от традиционных программных систем, основанных на понятии главной программы, в современных объектно-ориентированных системах, управляемых событиями, отсутствует центральная интеллектуальная (главная) программа. Более того, в современных системах отсутствует четко определенная интеграционная структура. Традиционные стратегии интегрирования сверху-вниз или снизу-вверх не применимы к современным системам.
Объектно-ориентированные системы должны быть спроектированы под интеграцию. Каждый модуль должен быть как можно более независимым. Зависимости между модулями необходимо идентифицировать и минимизировать на этапах анализа и проектирования. В идеале, каждый модуль должен образовывать один поток обработки, который запускается в ответ на определенное требование клиента. Использования заглушек как операций замещения следует, по возможности, избегать. Если система спроектирована недостаточно качественно, этап интеграции приведет к хаосу и поставит под угрозу весь проект по разработке системы.
Этап сопровождения
Этап сопровождения наступает после успешной передачи заказчику каждого последующего программного модуля и, в конечном счете, всего программного продукта. Сопровождение — не только неотъемлемая часть жизненного цикла ПО; оно составляет его большую часть, если речь идет о времени и усилиях персонала ИТ- подразделений, приходящихся на сопровождение. Скеч (Schach) приводит оценку, по которой 67% времени ЖЦ приходится на сопровождение ПО [77].
Сопровождение состоит из трех различных стадий [51].
Поддержка эксплуатации.
Адаптивное сопровождение.
Улучшающее сопровождение.
Поддержка эксплуатации (housekeeping) связана с рутинными задачами сопровождения, необходимыми для поддержания системы в состоянии готовности к применению пользователями и эксплуатационным персоналом. Адаптивное сопровождение (adaptive maintenance) связано с отслеживанием и анализом работы системы, настройкой ее функциональных возможностей применительно к изменениям внешней среды п адаптацией системы для достижения заданной производительности и пропускной способности. Под улучшающим сопровождением (perfective maintenance) понимают перепроектирование и модификацию системы для удовлетворения новых или существенно изменившихся требований.
В конечном итоге продолжение сопровождения системы становится нецелесооб- [зазным, и ее следует свернуть. Сворачивание (phasing out) обычно осуществляется по причинам, которые имеют мало общего с утратой ПО своей полезности', оно, возможно, по-
прежнему остается вполне пригодным для использования, однако становится непригодным для сопровождения. Скеч приводит четыре причины сворачивания ПО [77].
Предлагаемые изменения выходят далеко за рамки ближайших возможностей улучшающего сопровождения.
Система выходит из-под контроля служб сопровождения, и последствия изменений невозможно предвидеть.
Расширение ПО в будущем невозможно из-за отсутствия надлежащей документации.
Аппаратная и/или программная платформы, на которых реализована система, подлежат замене, а видимых путей для миграции нет.
.3.8. Планирование проекта в течение жизненного цикла ПО
Известное изречение гласит: то, что нельзя спланировать, нельзя и осуществить. Планирование охватывает весь жизненный цикл программного проекта. Оно начинается после того, как в результате работ по системному планированию определена бизнес-стратегия организации, и программный проект обозначен. Проектное планирование— это деятельность, направленная на оценку комплекта поставки, затрат, рисков, этапов и требуемых ресурсов. Оно 1акже включает выбор методов разработки, процессов, средств, стандартов, бригадной организации и т.д.
Проектные планы подобны ускользающей цели. Они меньше всего напоминают что-то раз навсегда заданное и неизменное. Проектные планы подвержены изменениям на протяжении всего ЖЦ. При этом данные изменения не выходят за рамки, устанавливаемые несколькими постоянньими ограничениями.
В качестве типичных ограничений выступают время и деньги— каждый проект имеет четкий конечный срок и строго ограниченный бюджет. Одна из первых задач проектного планирования состоит в оценке осуществимости проекта в условиях временных, бюджетных и прочих ограничений. Если проект осуществим, то ограничения фиксируются документально и могут быть изменены только в рамках формальной процедуры утверждения.
Осуществимость проекта оценивается с учетом нескольких факторов [37], [91].
Практическая осуществимость связана с возвратом к вопросам, впервые поднятым при системном планировании, когда проект был обозначен; она связана с изучением того, как предлагаемая система повлияет на организационные структуры, процедуры и людей.
Экономическая осуществимость связана с оценкой затрат на проект и приносимых им выгод (известной также как анализ затрат и результатов).
Техническая осуществимость связана с оценке»* практичности предлагаемых технических решений и наличия необходимых навыков, опыта и ресурсов.
Осуществимость по срокам связана с оценкой обоснованности план-графика выполнения проекта.
Не все ограничения известны или могут быть оценены во время открытия проекта. На этапе выработки требований выявляются дополнительные ограничения, которые должны подвергаться изучению с точки зрения их влияния на осуществимость проекта. К подобным ограничениям можно отнести юридические, договорные, политические ограничения и ограничения, связанные с безопасностью.
С учетом оценки осуществимости составляется «фоекясмый «йен, и устанавливаются правила управления проектом и процессом. В проектном плане находят отражение следующие вопросы [91].
а Рамки проекта.
Проектные задания.
а Управление и контроль проекта.
Управление качеством.
и Метрики и измерения.
а План-график проекта.
а Распределение ресурсов (людских, материальных, инструментальных).
а Руководство людьми.
Измерения в течение жизненного цикла ПО ■
Измерение времени и усилий, затраченных на проект, а также принятие на вооружение других метрик (metrics) для проектных артефактов в действительности является важной частью управления проектам и процессом. Несмотря на важность, в организациях с низким уровнем технологической зрелости этой частью часто пренебрегают. Цена здесь высока. Не “измеряя” прошлого, организация не в состоянии точно планировать будущее.
Метрики обычно рассматриваются в контексте качества и сложности ПО — они применяются в отношении качества и сложности программного продукта [36], [65]. Используются для измерения таких характеристик качества, как корректность, надежность, продуктивность, целостность, практичность, пригодность к сопровождению, гибкость и тестопригодность. Например, надежность ПО можно оценйть с помощью измерения частоты и серьезности отказов, среднего времени между отказами, точности выходных результатов, восстанавливаемости после отказов и т.д.
Другим важным применением метрик является измерение моделей разработки (продуктов разработки) на различных этапах ЖЦ ПО. Затем метрики используются для оценки эффективности процесса и повышения качества работы на различных этапах ЖЦ.
К типичным метрикам, которые применяются в отношении процесса создания ПО и могут быть приняты к использованию на различных этапах ЖЦ, относятся следующие метрики.
Изменчивость требований (процент требований, которые претерпевают изменения до завершения этапа спецификации требований). Эта метрика может отражать трудность получения требований от заказчиков.
Изменчивость требований после этапа спецификации требований. Эта метрика может указывать на низкое качество документального оформления требований.
Прогнозирование “мест перегрева” и "узкого горла” в системе (частота, с которой пользователи пытаются выполнить различные функции на прототипе программного продукта).
Объем документов, содержащих спецификации, которые генерируются CASE- средствами, и другие более детализированные метрики, взятые из репозитория CASE-системы, например, такие как количество классов в модели классов. Если их
применить к нескольким прошлым проектам, затраты и время выполнения которых ■ известны, эти метрики способны обеспечить идеальную плановую “базу данных” для прогнозирования времени и усилий, необходимых для будущих проектов.
Фиксирование статистики отказов, времени их появления, обнаружения и устранения. Подобная статистика может отражать доскональности системы обеспечения качества, процессов пересмотра и деятельности по тестированию ПО.
Среднее число тестов, после проведения которых тестируемая компонента считается готовой для интеграции поставки заказчику. Эта метрика может отражать уровень процедур отладки, используемых программистами.
Тестирование в течение жизненного цикла ПО
Подобно проектному планированию или измерению характеристик ПО, тестирование (.testing) — это деятельность, охватывающая весь жизненный цикл ПО. Тестирование —■ это не просто отдельный этап ЖЦ, следующий за реализацией. После того, как дело зашло уже довольно далеко и программный продукт реализован, приступать к тестированию слишком поздно. Исправление ошибок, допущенных на ранних этапах ЖЦ, обходится безмерно дорого [77].
Действия по тестированию должны быть тщательно спланированы. Планирование процесса тестирования начинается с установления перечня тестовых прецедентов или тест-прецедентов (test case). Тест-прецеденты (или тест-планы) определяют шаги тестирования, которые необходимо предпринять, чтобы попытаться “сломать" программную модель или продукт.
Тест-прецеденты должны быть определены для каждого функционального модуля (прецедента), описанного в виде документально оформленных требований. Соотнесение тест-прецедентов с прецедентами устанавливает траекторию прослеживаемости (traceability) между тестами и требованиями пользователей. Тестопригодность программного артефакта определяется, в частности, его прослеживаемостью.
Вполне естественно, что каждый разработчик тестирует продукт своего труда. Однако у разработчиков-авторов программных артефактов их “детище” всегда на нервом месте, так что от них трудно ожидать непредвзятого отношения к результатам своей работы.
Для более эффективного тестирования требуется привлечение независимых (по крайней мере— относительно) тестировщиков, которые могут провести методическое тестирование. Эту задачу можно поручить SQA-группе организации (Software Quality Assurance- обеспечение качества ПО). Группа должна включать лучших разработчиков организации. Их задача заключается в тестировании, а не в разработке. Затем на SQA-группу (но не на разработчиков-авторов) возлагается ответственность за качество программного продукта.
Чем больший объем тестирования выполнен на ранних этапах разработки, тем больше отдача. Требования, спецификации и любые другие документы (включая тексты программ) должны быть протестированы с использованием формалъных пересмотров (formal reuieiv) (так называемого сквозного контроля (walkthrough и инспекции (inspection')).
Формальные пересмотры — это тщательно подготовленные заседания, целью которых является анализ определенной части документации или системы. Специально назначенный рецензент заранее изучает документ и формулирует различные вопросы. Заседание решает, действительно ли поднятый вопрос вскрыл недочет, но не де-
лает при этом никаких попыток предложить немедленное решение проблемы. Позже разработчик-автор обращается к выявленному дефекту. При условии, что заседание проходит в дружественном духе, а участники избегают “указывать пальцем" на виновников ошибок, совместные усилия приводят к раннему обнаружению и исправлению многих ошибок.
После того, как программные прототипы и первые версии программного продукта становятся доступны, предпринимается тестирование, основанное на выполнении программы {execution-based testing). Существует два основных вида тестирования, основанного на прогонах.
Тестирование по спецификации (тестирование по методу “черного ящика”).
Тестирование по программному коду (тестирование по методу “прозрачного ящика”).
При тестирование по спецификации {testing to specification) сама программа рассматривается как “черный ящик”, о котором ничего не известно, за исключением того, что он получает некоторую информацию на входе и вырабатывает некоторую информацию на выходе. На вход программы подаются некоторые входные данные, а результирующие данные анализируются на предмет наличия ошибок. Тестирование по спецификации особенно полезно для выявления некорректных или упущенных требований.
При тестировании по программному коду {testing to code) программная логика подвергается “сквозному просмотр/’ с целью установить, какие данные необходимо подать на вход, чтобы испытать различные выполняемые ветви программы. Тестирование по коду дополняет тестирование по спецификации — эти два вида тестирования направлены на выявление различных категорий ошибок.
Наращиваемая разработка предполагает не только наращиваемую интеграцию программных модулей, но и наращиваемое или регрессионное тестирование {regression testing). Регрессионное тестирование представляет собой повторное выполнение предыдущих тест-прецедентов на том же базисном наборе данных {baseline data set) после расширения — за счет наращивания возможностей — ранее выпущенных программных модулей. Тестирование проводится в предположении, что прежние функциональные возможности должны остаться неизменными и не должны быть нарушены за счет расширения.
Неплохим инструментом поддержки регрессионного тестирования могут служить средства записи-воспроизведения (captureplayback tools), которые позволяют зафиксировать взаимодействие пользователя с программой, а затем воспроизвести их без дальнейшего вмешательства пользователя. Основная трудность регрессионного тестирования заключается в нестабильности базисного набора данных. Дело в том, что наращиваемая разработка не только расширяет процедурную логику программы, но также расширяет и (модифицирует) основные структуры данных. Программный продукт с расширенными возможностями может заставить изменить базисный набор данных, таким образом лишая смысла сравнение результатов.
1.4. Подходы к разработке программного обеспечения
“Революция в программном обеспечении” вызвала ряд значительных изменений в способах работы программных продуктов. В частности, значительно увеличились интерактивные возможности программ. Задачи, выполняемые программами, и их поведение могут динамически адаптироваться к запросам пользователей.
Процедурная логика программ, написанных в пренилом на языках подобных языку COBOL, не отличалась гибкостью и не очень-то откликалась на неожиданные события. После запуска программа выполнялась до завершения в более или менее детерминированном режиме. Иногда программа могла запрашивать некоторую информацию от пользователя и следовать по различным выполняемым ветвям. Однако, в общем случае взаимодействие с пользователем было ограничено, а количество различных выполняемых ветвей заранее фиксировано. Контроль оставался за программой, а не пользователем.
С появлением современного графического пользовательского интерфейса (GUI) все кардинально изменилось. Программы на основе GUI-интерфейса управляются событиями, ход их выполнения носит случайный и непредсказуемый характер и диктуется инициируемыми пользователем событиями, источником которых являются клавиатура, мышь и другие устройства ввода.
В среде СШинтерфейса пользователь контролирует (по большей части) выполнение программы, а не наоборот. За каждым событием стоит программный объект, который знает, как обслужить данное событие при текущем состоянии хода выполнения программы. После завершения обслуживания управление вновь возвращается к пользователю.
Различные стили программирования требуют разных подходов к разработке ПО. При разработке традиционного ПО хоровтую службу сослужил структурный подход. Современные системы на основе GUI-интерфейса требуют объектного программирования, и объектный подход является наилучшим способом проектирования таких систем.
Структурный подход
Структурный подход (structured approach к разработке систем получил широкое распространение (и был признан стандартом де-факто) в 1980-х годах. Этот подход основан на двух методах: диаграммах потоков данных ( (data flow diagrams — DFD) для моделирования процессов и диаграммах сущность-связь (entity relationship diagrams — ERD) для моделирования данных.
Структурный подход является функушишжыюорнентировамным и рассматривает DFD-диаграммы в качестве д вижущей силы разработки ПО. Позднее, в качестве одного из непосредственных результатов широкого распространения моделей реляционных баз данных, значение DFD-диаграмм в структурной разработке снизилось, и подход стал более ареененвроеанмым. на данные, и, соответственно, акцент в разработке сместился на ERD-диаграммы.
Сочетание DFD- и ERD-диаграмм дает относительно полные модели анализа, которые фиксируют все функции и данные системы на требуемом уровне абстракции независимо от особенностей аппаратного и программного обеспечения. Затем модель анализа преобразуется в проектную модель, которая обычно выражается в понятиях реляционных баз данных. После этого следует этап реализации.
Структурный подход к анализу и проектированию отличается рядом особенностей, некоторые из них не очень хороню увязываются с современными методами конструирования ПО.
Этот подход скорее является носдедоватеяъным и трансформационным, чем итеративным подходом с наращиванием возможностей (т.е. этот подход не способствует непрерывному процессу разработки, осуществляемому посредством итеративной детализации и пошаговой поставки ПО с наращенными возможностями).
Этот подход направлен на поставку негибких решений, которые способны удовлетворить набор определенных бизнес-функций, но которые может быть трудно масштабировать и расширять в будущем.
Этот подход предполагает разработку “с чистого листа” и не поддерживает повторное использование уже существующих компонент.
Трансформационный характер структурного подхода является источником погашенного риска неправильно истолковать исходные требования пользователей по ходу разработки. Такой риск усиливается за счет необходимости постепенной замены относительно декларативной семантики моделей анализа на процедурные решения для проектных моделей и программного кода реализации (это является следствием того, что модели анализа семантически богаче, чем базовые проектные и реализационные модели)..
Объектно-ориентированный подход
Обыктжмфиештфоеапный подход ^obgecUmenied «фргоосА) к разработке систем получил распространение в 1990-х годах. Ассоциация производителей ПО Object Management Group утвердила в качестве стандартного средства моделирования для этого подхода язык UML (Unified Modeling Language—Унифицированный язык моделирования).
По сравнению со структурным подходом объектноориентированный подход в большей степени «фшняпфоеая на данные— он развивается вокруг моделей классов. На этапе анализа для классов не требуется определять операции — только атрибуты. Возрастающее значение использования в языке UML прецедентов способствует незначительному смещению акцентов от данных к функциям.
Существует понимание того, что разработчики используют объектный подход вследствие технических преимуществ объектной парадигмы, таких как абстракция, инкапсуляция, повторное использование, наследование, передача сообщений, полиморфизм и т.д, Эти технические свойства могут привести к более высокому уровню повторного использования программного кода и данных, сокращению времени разработки, росту продуктивности труда программистов, повышению качества ПО, большей понятности программ и т.д.
При всей свой привлекательности данные преимущества объектной технологии до сих пор не нашли своего практического воплощения. Тем не мсвсе мы продолжаем использовать сегодня объекты и будем использовать их завтра. Одной из причин этого является возможность работы с новым стилем программирования — программированием, управляемым событиями, (event-driven),— который поддерживается современными GUI-интерфейсами.
Другой причиной популярности объектного подхода является возможность удовлетворить требования вновь eoentocaioigwc типов приложений и находить наилучшие спосо бы борьбы с ростом количества невыполненных заказов на приложения. К двум наиболее важным новым категориям приложений, для которых требуется объектная технология, относятся вычислительная обработка для рабочих групп н системы мультимедиа. Идея остановить рост числа невыполненных заказов посредством концепции “помещения объектов в оболочку” доказала как свою привлекательность, так и работоспособность.
Объектный подход к разработке систем следует итеративному процессу с наращиванием возможностей. Единая модель (и один проектный документ) конкретизируется на этапах анализа, проектирования и реализации — в результате успешных итераций
добавляются новые детали, при необходимости вводятся изменения и усовершенствования, а выпуски программных модулей с наращенными возможностями поддерживают высокий уровень удовлетворенности пользователей и обеспечивают обратную связь, необходимую для продолжения разработки модулей.
Разработка с помощью последовательной детализации становится возможной благодаря том)*, что все создаваемые в ходе разработки модели (анализа, проектирования и реализации) обладают семантическим богатством и базируются на одном и том же “языке’’ — базовый словарь этих моделей существенно не отличается (классы, атрибуты, методы, наследование, полиморфизм и т.'д.). Следует, однако, заметить, что если в основу реализации положена реляционная база данных, необходимость в сложной и связанной с риском трансформации по-прежнему сохраняется (поскольку базовая семантика реляционной модели сравнительно беднее).
Объектный подход устраняет большинство из наиболее значительных недостатков структурного подхода, однако, служит источником некоторых новых проблем.
Этап анализа проводится на еще более высоком уровне абстракции, и — если серверная часть решения по реализации предполагает использование реляционной базы данных— семантический разрыв между концепцией и ее реализацией может быть значительным. Хотя анализ и проектирование могут проводиться итеративно с наращиванием возможностей, в конце концов разработка достигает этапа реализации, которая требует трансформации решения применительно к реляционной базе данных. Если в качестве платформы реализации используется объектная или объектно-реляционная база данных, трансформация проекта проходит значительно легче.
Управление проектом сложно осуществлять. Менеджеры измеряют степень продвижения разработки с помощью четко определенной декомпозиции работ, элементов комплекта поставки и ключевых этапов. При объектной разработке с помощью “детализации” не существует четких границ между этапами, а проектная документация непрерывно развивается. Приемлемое решение в такой ситуации лежит ■ в делении проекта на небольшие модули и управлении ходом разработки за счет частого выпуска выполняемых версий этих модулей (некоторые из этих выпусков могут быть для внутреннего применения, а другие — поставляться заказчику).
Еще одна большая проблема применения объектного подхода связана с возрастающей сложностью решения, что, в свою очередь, сказывается на таких характеристиках ПО, как приспособленность к сопровождению и масштабируемость.
Сложности, связанные с объектным подходом, не влияют на тот факт, что по словам Артура Кларка “будущее нельзя повернуть вспять”. Возврата к вызывающему ностальгию процедурному стилю пакетных приложений на языке COBOL нет. Все участники проектов по созданию ИС хорошо знакомы с Internet, электронной коммерцией, компьютерными играми и другими интерактивными приложениями.
Новые программные приложения отличаются значительно большей сложностью построения, и структурный подход совершенно не соответствует этой задаче. На сегодняшний день объектно-ориентированный подход — единственный известный метод, позволяющий совладать с разработкой нового управляемого событиями отличающегося высоким уровнем интерактивности ПО.
Резюме
В этой главе мы рассмотрели стратегические вопросы, касающиеся процесса разработки программного обеспечения. Для некоторых читателей содержимое этой главы значит не больше “родительской” нотации. Читателям, обладающим некоторым опытом в области разработки ПО, эта глава могла дать дополнительный интеллектуальный заряд. По отношению ко всем читателям данная глава была задумана как введение к предстоящему более всестороннему обсуждению.
По своей природе разработка ПО ближе к ремеслу или даже искусству. Результаты программного проекта нельзя полностью предвидеть при его начале- Основная нс- предсказуемая трудность при разработке ПО связана с участниками проекта— программный продукт должен дать участникам проекта ощутимые выгоды; в противном случае его ждет провал. В “треугольник” факторов, обеспечивающий успех проекта, помимо человеческого фактора входят стабильный процесс и поддержка языка и средств моделирования.
Цель разработки ПО — предоставить заказчику продуктивную систему. Разработке ПО предшествует системное планирование, в ходе которого определяется, какие про1 дукты будут наиболее эффективными для организации. Существуют разные способы осуществить системное планирование. В данной главе были рассмотрены четыре известных подхода: SWOT, VCM, BPR и ISA. Системы, поддерживающие стратегический уровень принятия решений, приносят наибольшую выгоду. Эти же системы создают наибольшие проблемы для разработчиков.
Разработка программного обеспечения подчиняется определенному жизненному циклу. В этой книге наибольшее внимание уделяется двум этапам жизненного цикла: анализу и проектированию. Другие этапы включают реализацию, интеграцию и сопровождение. Разработку ПО составляют и некоторые другие виды Деятельности, такие как проектное планирование, сбор данных измерений, тестирование и управление изменениями. Мы не относим эти виды деятельности к отдельным этапам, поскольку они регулярно повторяются на протяжении всего ЖЦ.
В прошлом программные продукты отличались процедурным характером — запрограммированная процедура выполняла свою задачу более-менее последовательным и предсказуемым образом, после чего завершалась. Структурный подход к разработке успешно использовался для производства подобных систем.
Современные программные продукты являются обьектноариентированными— программа состоит из программных объектов, которые выполняются случайным, непредсказуемым образом, и программа не завершается до tex пор, пока пользователь не прекратит ее выполнение. Объекты “бездействуют”, ожидая наступления инициированного пользователем события, чтобы начать вычисление; для выполнения задачи они могут запросить от других объектов предоставить им услуги, после чего снова впадают в “спячку”, но сразу “поднимаются по тревоге” — стоит только пользователю инициировать другое событие. Современные клиент/серверные приложения ИС, разработанные с использованием GUI-интерфейса, являются объектно-ориентированными, и объектно-ориентированный подход к разработке наилучшим образом пригоден для производства таких приложений. Оставшаяся часть книги посвящена объектно-ориентированному подходу.
Щ Вопросы
Исход » Из своего опыта в отношении программных продуктов, как бы вы могли проинтерпретировать замечание Фреда Брукса о том, что сущность программной инженерии проистекает из таких свойств ПО, как сложность, податливость, изменчивость и неосязаемость? Какое объяснение вы могли бы дать этим четырем факторам? В чем программная инженерия отличается от традиционных инженерных дисциплин, таких как строительство или машиностроение?
Мы пытались доказать, что производство ЛО — это искусство или ремесло. В качестве подтверждения этого тезиса можно привести высказывание о том, что “Искусство — это союз между Богом и художником, и чем меньше вклад ывает в него художник, тем лучше" (Андре Жид). Какой урок м^гугвынрр^иузтого высказывания разработчики ПО? Согласны ли вы с ним?
Объясните разницу между программными пакетами и компонентами. Какое будущее, по- вашему, ожидает эти две технологии?
Вспомните опред еление участника предприятия. Относятся ли продавец ПО и специалист по технической поддержке к участникам предприятия? Объясните свою точку зрения.
>
В5. Какой уровень технологической зрелости требуется д ля организации, чтобы овладеть кризисной ситуацией? Объясните свою точку зрения.
Вб. В ходе объяснения SWOT-подхода к системному планированию мы заметили, что “верно сформулированная миссия отводит главное место потребностям клиентов, а не товарам или услугам, которые предоставляет организация". Пожалуйста, объясните и проиллюстрируйте, каким обрезом нацеливание формулировки миссии на определенные товары или услуги может привести к утрете, основной цели системного планирования — достижения эффективности.
Реинжиниринг бизнес-процессов (ВРЯ) проводит ясное различие между бизнес- процессом и бизнес-функцией. В чем заключается это различие? Приведите пример бизнес-процесса, который разорван по горизонтали по всей организации.
Сравните концепции цепочек ценности и бизнес-процесса.
Почему понимание метода /S* (архитектура информационной системы) важно для системной разработки?
Назовите три уровня управления организацией. Рассмотрите банковское приложение, которое предназначено для отслеживания стереотипов поведения владельцев кредитных карточек, чтобы автоматически блокировать карточку, если банк заподозрит злоупотребление (кража, подделка и т.д.). Какой уровень управления поддерживает подобное приложение? Обоснуйте свое заключение.
Объясните разницу между этапами определения требований и разработки спецификации.
Объясните взаимосвязь двух этапов проектирования (архитектурное проектирование и детализированное проектирование} с первыми двумя этапами жизненного цикла — этапом определения требований и этапом разработки спецификации.
Что вы понимав^ под соглашением, объектно-ориентированные системы должны проектироваться под интеграцию"?
Системное планирование и измерения ПО существенно связаны. Объясните этот тезис.
Объясните взаимосвязь между прослеживаемостью и тестопригодностью.
Касой основной метод моделирования применяется при структурном подход е к разработке?
Каковы основные причины сдвига от структурного подхода к проектированию объектноориентированному?
Основания анализа требований
В качестве основного метода создания ПО в данной книге принят объектноориентированный подход. Этот подход не дается легко, поскольку объектноориентированная разработка требует хорошего знания объектной технологии. Без глубокого понимания тонкостей объектной технологии разработчик не сможет правильно применять язык UML в качестве универсального и привычного средства моделирования.
Основная трудность изучения объектной технологии связана с отсутствием очевидной отправной точки и ясного направления исследования. Это не хорошо известные нам подходы к изучению систем “сверху-вниз” или “снизу-вверх”. По существу, рассматриваемый подход представляет собой что-то наподобие “все время со средины”. Не зависимо от того, насколько мы продвинулись в процессе изучения, кажется, что мы всегда находимся посередине этого процесса (поскольку все время возникают новые вопросы). Можно считать, что в процессе изучения достигнут первый успех, когда читатель осознает глубинный смысл того факта, что в объектно-ориентированной системе “все есть объект”.
Данная глава направлена на то, чтобы дать читателю необходимый базовый уровень знаний об изучаемом предмете прежде, чем приступить к его более глубокому изучению. В этой главе разъясняется, выполнение каких предварительных условий необходимо для анализа требований, при этом одновременно используются два способа подачи материала. Во-первых, здесь объясняются основы объектной технологии. Во-вторых, проводится “обучение на примерах” и дается наставление по моделированию анализа с использованием приложения Iirternet-магазин, относящегося к известной прикладной области — “Электронная торговля”.
Основы объектной технологии
Для объяснения сути объектной ориентации информационных систем воспользуемся аналогией с объектами реального мира. Окружающий мир состоит из объектов (object), пребывающих в состоянии (state), которое определяется текущими значениями атрибутов объекта. ■
Например, кружка на моем столе находится в состоянии filled (наполнена), поскольку она приспособлена для хранения жидкостей и в ней все еще есть кофе. Когда в ней нет больше кофе, состояние кружки можно определить как empty (пуста). Если она упадет на пол и разобьется, она перейдет в состояние broken (разбита).
Моя кофейная чашка, конечно, пассивна — она не обладает собственным поведением {behavior). Однако, этого нельзя сказать о моей собаке или эвкалиптовом дереве за моим окном. Моя собака лает, дерево растет и т.д. Итак, некоторые объекты реального мира обладают поведением.
Все объекты реального мира обладают также идентичностью {identity)— постоянным свойством, с помощью которого мы отличаем один объект от другого. Если на моем столе стоят две чашки из одного набора, я могу сказать, что они одинаковые, но не идентичные. Чашки одинаковые, потому что значения их свойств совпадают (они одинакового размера и формы, черного цвета и пустые). Однако, на объектно-ориентированном языке они не идентичны, поскольку их две, и у меня есть выбор, которую из них использовать.
Реальные объекты, обладающие тремя свойствами (состояние, поведение, идентичность), образуют системы с естественным поведением. Естественные системы безусловно являются самыми сложными системами из всех известных. Никакая компьютерная система не может сравниться по сложности с животным или заводом.
Несмотря на сложность, естественные системы способны работать: они демонстрируют интересное поведение, могут приспосабливаться к внешним и внутренним изменениям, могут эволюционировать со временем и т.д. Вывод очевиден. Наверное, мы должны конструировать искусственные системы с помощью моделирования структуры и поведения естественных систем (сравн. [55]).
Искусственные системы являются моделью реальности. Кофейная чашка на экране моего компьютера всего лишь модель реальной “сущности” так же, как собака или эвкалиптовое дерево на моем экране. Кофейная чашка может быть, таким образом, смоделирована с помощью поведенческих свойств. Она может, к примеру, упасть на пол, если ее уронить. Действие “падения” можно смоделировать как поведенческую операцию {operation) чашки. Еще одним логическим “действием” чашки может быть операция “разбиться” при ударе об пол. Большинство, если не все, объекты в компьютерной системе “оживают” — они обладают поведением.
Объект-экземпляр
Объект — это экземпляр {instance) некоей "сущности”. Он может быть одним из множества экземпляров одной и той же “сущности”. Моя Чашка — экземпляр множества всевозможных чашек.
Общее описание “сущности” называется классом {class). Поэтому объект является экземпляром класса. Однако, как мы увидим в разделе 2.1.6, класс также может нуждаться в конкретизации — он может быть объектом. Поэтому нам необходимо различать объект-экземпляр {instance object) и объект-класс {class object).
Для краткости объект-экземпляр часто называют объектом или экземпляром. Название “экземпляр объекта” сбивает с толку. Объектно-ориентированная система состоит из взаимодействующих объектов. В объектно-ориентированной системе нет ничего, кроме объектов, будь-то объект экземпляра {объект-экземпляр) или объект класса {объект-класс).
В качестве отступления и в продолжение темы заметим, что мы не настаиваем на использовании термина “класс объекта". Конечно, класс представляет собой шаблон для объектов с аналогичными атрибутами и операциями, но сам класс также может быть конкретизирован в виде.объекта (и мы не хотим называть такое образование “объект класса объекта").
Объектная нотация
В языке UML объект обозначается прямоугольником с двумя отделениями. Верхнее отделение содержит имя объекта и имя класса, которому принадлежит объект. Синтаксис этой конструкции выглядит так:'
obiectname: classname.
Нижнее отделение содержит список имен атрибутов и значений. С помощью этого, синтаксиса можно также показать типы атрибутов:
attributename: type = value.
На рис. 2.1 показан объект Course (Дисциплина) с именем cl. Объект обладает двумя атрибутами. Типы атрибутов не показаны — они заданы в определении класса.
cl: Course
course_number= СОМР227
course_name = R equirements Analysis and System Design
Fur. 2.1. Объект-экземпляр
Важно иметь в виду, что объектная нотация не предусматривает в обозначении объекта особого “отделения" для перечня операций, которые может выполнять объект-экземпляр. Это связано с тем, что операции, выполняемые всеми объектами- экземплярами, идентичны, и поэтому хранить их в каждом объекте-экземпляре было бы накладно. Операции можно хранить в объекте-классе или же можно связать их с объектами-экземплярами другими средствами (реализованными в ПО базовой объектно-ориентированной системы).
Как объекты кооперируются
Количество объектов определенного класса может быть очень большим. Показать большое количество объектов на диаграмме нереально, а иногда просто невозможно. Объекты изображаются только для того, чтобы привести пример системы в определенный момент времени или проиллюстрировать, каким образом они кооперируются (collaborate) с течением времени при выполнении определенных задач. Например, чтобы упорядочить товары, может потребоваться установить кооперацию между объектом Stock (Склад) и объектом Purchase (Покупка).
Системные задачи выполняются объектами, которые активизируют операции (поведение) друг друга. Мы говорим, что они обмениваются сообщениями (message). Сообщения запускают операции на объектах, которые могут приводить к изменению состояний объектов и вызывать другие операции.
Рис. 2.2 иллюстрирует поток сообщений между четырьмя объектами. Скобки после имени сообщения указывают на то, что сообщение может принимать параметры (аналогично вызову функции в традиционном программировании). Объект Order (Заказ) предписывает объекту Shipment (Поставка) доставить заказ. Для этого объект Shipment инструктирует объект Stock о необходимости вычесть соответствующее количество товаров. Затем объект Stock анализирует новый уровень запаса и, если он оказывается ниже определенного значения, предписывает объекту Purchase сделать повторный заказ дополнительного объема товаров.
Хотя приведенное объяснение кооперации объектов выглядит как последовательность видов деятельности, а сообщения даже пронумерованы, в общем случае на порядок, в котором активируются объекты, не накладывается строгих ограничений. Например, сообщения analyzeStockLevels (проанализировать уровни запаса) и reorderProducts (повторить заказ товара) могут выполняться в любой последовательности, возможно, независимо от сообщений shipOrder (доставить заказ) и subtractProduct (уменьшить количество товара). Поэтому в дальнейшем при рассмотрении кооперации объектов на уровне реализации мы откажемся от нумерации сообщений (раздел 6.2).
Рис. 2.2. Кооперация объектов
Как объекты идентифицируют друг друга
Вопрос состоит в том, каким образом объект узнает об идентичности другого объекта, которому требуется отправить сообщение. Каким образом объект Order узнает свой объект Shipment так, чтобы сообщение shipOrder попало к своему адресату?
Ответ заключается в том, что каждому объекту при создании присваивается идентификатор объекта (object identifier— OID). Идентификатор объекта (OID) представляет собой дескриптор (handle) объекта — уникальный номер, который остается с объектом на протяжении всего времени его существования. Если объекту X необходимо отправить сообщение объекту Y, объект X каким-либо образом должен узнать OID объекта Y.
На практике для установления связи по OID между объектами существует два подхода, каждому из которых соответствует определенный тип связи.
Постоянная связь по OID.
Временная связь по OID.
Различие между этими видами связи определяется продолжительностью существования объекта. Время жизни некоторых объектов не превышает времени выполнения программы — они создаются программой и уничтожаются во время выполнения программы или по ее завершении. Это так называемые временные объекты (transient object). Другие объекты “переживают” выполнение программы — после завершения программы они запоминаются в долговременной дисковой памяти и доступны при следующем выполнении программы. Это так называемые постоянные объекты (persistent object).
(Временные объекты называют также короткоживущими, а постоянные— долгоживущими, постоянного хранения или энергонезависимыми. Последнее название связано с тем, что объекты этого типа не исчезают при отключении питания компьютера, сохраняясь в энергонезависимой памяти, как правило, на дисковых устройствах. Прим, ред.)
Постоянная связь
Постоянная связь (persistent link) — это ссылка на объект (или множество ссылок на объекты), принадлежащая одному из объектов, хранимых в долговременной памяти, которая связывает этот объект с другим объектом в долговременной памяти (или со множеством других объектов). Поэтому, для установления постоянной связи объекта Course (Курс) с его объектом Teacher (Преподаватель) объект Course должен содержать атрибут связи, значение которого равно OID объекта Teacher. Описанная связь постоянна, поскольку OID физически хранится в объекте Course, как показано на рис. 2.3.
Ref&*)(
cl: Course
course_number= COMP227
course_name= Requirements Analysis and System Designteacher identity= Ref@#$%
Рис. 2.3. Реализация постоянной связи
OID объекта cl помечен здесь как Ref &*) (. Объект содержит атрибут связи под именем teacher. Данный атрибут принадлежит типу Identity. Его значение равно магическому числу Ref #$ % —адресу дисковой памяти, где постояннохранитсяобъектТеасЬег.
После того, как объекты Course и Teacher перемещаются в память программы, значение атрибута teacher будет “втянуто” в указатель памяти, в результате устанавливается кооперация между объектами на уровне памяти. (Выражение “втягивать” (swizzling, по англ. букв, “тянуть коктейль”) — это не термин языка UML, он используется в объектных базах данных (см. раздел 6.2), где перемещение объектов между' долговременной и оперативной памятью довольно частое явление.)
На рис. 2.3 показана типичная реализация постоянной связи. Однако, связи между объектами для случая моделирования с помощью языка UML показаны на рис. 2.4. Связи представляются как экземпляры ассоциации (instances oj association) между объектами Course и Teacher.
Обычно кооперативные связи допускают передвижение (navigation) в обоих направлениях. Каждый объект Course связан со своим объектом Teacher, а объект Teacher может привести к объектам Course. Изредка допускается передвижение только в одном направлении.
После того как объект связан с другим объектом на постоянной основе, он может отправить по этой связи сообщение, чтобы запросить у другого объекта сервис (service). Это значит, что объект вызывает операцию на другом объекте за счет отправки ему сообщения. При типичном сценарии для указания объекта отправитель использует программную переменную, содержащую значение связи (значение OID) этого объекта.
Например, сообщение, отправленное объектом Teacher для того, чтобы определить имя объекта Course, может иметь следующий вид:
crs-ref.getCourseName(out crs_name)
В приведенном примере определенный объект класса Course, который будет выполнять операцию getCourseName, указывается текущим значением переменной связи crs_ref. Результирующий (out) аргумент (crs_name) представляет собой переменную, значение которой инициализируется с помощью значения, возвращаемого операцией getCourseName, реализованной в классе Course.
Рис. 2.4. Постоянные связи в объектной UML-модели
Временная связь
Что если мы не определили постоянные связи между объектами Course и Teacher, но нам по-прежнему требуется отправить сообщение от объекта tl к объекту cl для вызова операции getCourseName? Прикладная программа должна обладать другими средствами для установления идентичности объекта cl и создать временную связь от объекта 11 к объекту cl [70].
К счастью, в распоряжении программиста имеется много средств, способных обеспечить инициализацию переменной crs_name с помощью OID объекта cl, резидентно находящегося в памяти. Для начала заметим, что, возможно, связь между объектами с! и tl была установлена в программе раньше, и переменная crs_name хранит правильный OID. Например, программа выполнила операцию поиска с использованием атрибута занятости преподавателя tl и расписания курсов и определила, что преподаватель tl должен вести курс cl.
Альтернативная возможность состоит в том, что программа имеет доступ к постоянно хранимой таблице, которая отображает номера курсов на имена преподавателей. Затем программа может выполнить поиск на объектах Course, чтобы отыскать все курсы, читаемые преподавателем tl, и попросить пользователя определить курс (т.е. объект Course), которому должно быть отправлено сообщение getCourseName.
Возможно также, что задача программы как раз и состоит в создании объектов для курсов и преподавателей перед тем, как запомнить их в базе данных. Между соответствующими объектами нет постоянных связей, но пользователь вводит информацию таким образом, что каждый курс четко определяет ответственного за него преподавателя. Затем программа может запомнить временную связь в программной переменной (такой как crs-ref), а эту переменную можно позднее использовать (во время выполнения этой же программы) для отправки сообщений между объектами Teacher и Course.
Короче говоря, существуют как программные, так И управляемые пользователем методы установления временных связей между объектами, которые не связаны постоянно с помощью ассоциации между соответствующими классами. Временные связи— это программные переменные, которые содержат значения OID, объектов, находящихся в текущий момент в оперативной памяти. Отображение (“втягивание") между временными и постоянными OID должно быть прерогативой базовой программной среды, например, такой как система управления объектной базой данных.
Класс
Класс (class) — это дескриптор множества объектов, обладающих одинаковым набором атрибутов и операций. Он служит в качестве шаблона (template) для создания объектов. Каждый объект, созданный по шаблону, содержит значения атрибута, соответствующие типу атрибута, определенному в классе, и может вызвать операции, определенные в классе.
Графически класс представляется в виде прямоугольника с тремя отделениями, разделенными горизонтальными линиями, как показано на рис. 2.5. Верхнее отделение хранит имя класса. Среднее отделение содержит объявления всех атрибутов класса. Нижнее отделение содержит определения операций.
Атрибуты
Атрибут представляет собой пару тип-значение. Класс определяет типы атрибутов. Объекты содержат значения атрибутов. Рис. 2.6 иллюстрирует два класса с определениями имен и типов принадлежащих им атрибутов. 1
Тип атрибута может быть встроенным элементарным типом (primitive type) или другим классом. Элементарный тип — это непосредственно распознаваемый и поддерживаемый базовой объектно-ориентированной средой тип данных. Все типы атрибутов, показанных на рис. 2.6, обозначают элементарные типы.
Class name "
Attributes
Operations ()>
Рис. 2.5. “Отделения* в представлении класса
Course course_number: String course name: StringCourse course_number: String course name: StringOrder order_number: Integer orderjdate: Date order value: CurrencyOrder order_number: Integer orderjdate: Date order value: Currency
Course course_number: String course name: String
Course course_number: String course name: String
Order order_number: Integer orderjdate: Date order value: Currency
Order order_number: Integer orderjdate: Date order value: Currency
Puc. 2.6. Атрибуты
Тип атрибута, обозначающий класс
Тип атрибута также может обозначать класс. Применительно к конкретному объекту' некоторого класса подобный атрибут содержит значение идентификатора объекта (OID), указывающее на объект другого класса. В UML-моделях анализа атрибуты.
типы которых обозначают классы, не приводятся в среднем “отделении" представления класса (в отличие от примитивных типов). Вместо этого они представляются с помощью ассои.иаи.гси (association) между классами. На рис. 2.7 показана подобная ассоциация между двумя классами.
Два имени на ассоциативной линии (the shipment ([конкретная] поставка) и the_order ([конкретный] заказ)) представляют так называемые ролевые имена. Ролевое имя (токпате) определяет значение для одного из концов ассоциации и используется для перемещения к объекту другого класса в ассоциации.
В реализованной системе ролевое имя (на противоположном конце ассоциации) становится атрибутом класса, тип которого является классом, на который указывает ролевое имя. На рис. 2.8 показано, как выглядят два класса с рис. 2.7 после того, как они были реализованы.
Рис. 2.7. Ролевые имена, обозначающие классы (модель анализа)Рис. 2.7. Ролевые имена, обозначающие классы (модель анализа)
Рис. 2.7. Ролевые имена, обозначающие классы (модель анализа)
Рис. 2.7. Ролевые имена, обозначающие классы (модель анализа)
Shipment the_order: Order shipQrderQShipment the_order: Order shipQrderQOrder order_number: Integer order_date: Date ordervalue: Currency the shipment: Shipment
Shipment the_order: Order shipQrderQ
Shipment the_order: Order shipQrderQ
Puc. 2.8. Атрибуты, обозначающие классы (модель реализации)
2-1.2Л .2. Видимость атрибутов
Как отмечалось в разделе 2.1.1.2, объекты взаимодействуют с помощью отправки друг другу сообщений. Сообщение вызывает операцию класса. Операция обслуживает запрос вызывающего объекта с помощью доступа к значениям атрибутов в своем собственном объекте. Чтобы подобный сценарий стал возможен, операции должны быть видимы (visible) внешним объектам (сообщения должны “увидеть” операции). Говорят, что подобные операции обладают открытой видимостью (public visibility).
В чисто объектно-ориентированной системе (примером которой может служить среда программирования языка Smalltalk) большинство операций относится к открытым (public), а большинство атрибутов— к закрытым (private). Значения атрибутов скрыты от других классов. Объекты одного класса могут только затребовать услугу (операцию), опубликованную в открытом интерфейсе другого класса. Им не разрешается непосредственно манипулировать атрибутами другого объекта.
Мы говорим, что операции инкапсулируют (encapsulate) атрибуты. Заметим, однако, что инкапсуляция применима к классам. Один объект не может скрыть (инкапсулировать) ничего, кроме другого объекта того же класса.
Видимость обычно обозначается с помощью символов плюс и минус:
+ для открытой видимости;
- для закрытой видимости.
В некоторых CASE-средствах эти символы заменены на графические пиктограммы. На рис. 2.9 продемонстрировано два графических представления для обозначения видимости атрибутов.
Purchase
О
purchase_number: String purchase_date: Date purchase_value: Currency
и reorderProducts()
Purchase
-purchase_number: String
-purchase_dEte: Date
-purdiase value: Currency +reorderProducts()
Puc. 2.9. Закрытые атрибуты и открытые операции
Операции
Объект содержит данные (атрибуты) и алгоритмы (операции) для работы с этими данными. Операция объявляется в классе. Процедура, реализующая операцию, называется методом (method).
Операция (или метод, если быть точным) вызывается с помощью отправленного ей сообщения. Имя сообщения и имя операции совпадают. Операция может содержать список параметров, которым в вызове сообщения могут быть присвоены определенные значения, и может возвращать значение вызывающему объекту.
Имя операции вместе со списком типов формальных аргументов называется сигнатурой (signature) операции. Сигнатура в пределах класса должна быть уникальной. Это значит, что класс может обладать множеством операций с одним и тем же именем, при условии, что списки типов параметров этих операций отличаются.
Операции — основа совместной работы объектов
Объектно-ориентированная программа выполняется, реагируя на случайные события, которые инициирует пользователь. Источником событий выступает клавиатура, щелчки мышью, пункты меню, кнопки действий и любые другие входные устройства. Инициированное пользователем событие преобразуется в сообщение, отправляемое обеек- ту. Для выполнения задания многим объектам требуется действовать совместно. Объекты “сотрудничают" с помощью вызова операций других объектов (см. разд. 2.1.1.2).
На рис. 2.10 показаны операции классов, необходимые для поддержки совместных действий объектов, приведенных на рис. 2.2. Каждое сообщение на рис. 2.2 запрашивает операцию класса, обозначенного как адресат сообщения. В данном простом примере у класса Order операции отсутствуют. Объект класса Order инициирует совместную работу объектов. Объект Order (Заказ) предписывает объекту Shipment (Поставка) осуществить его “поставку”. В результате поставки (т.е. выполнения заказа за счет товаров со склада) может потребоваться пополнение запаса новыми товарами.
OrderOrderShipmentHshlpOrder()ShipmentHshlpOrder()
Order
Order
Shipment
HshlpOrder()
Shipment
HshlpOrder()
Stock Purchase
■ subtractProducts() В reorderProducts() I analyzeSi&ckLevels()
' Puc. 2.10. Операции служат основой совместных действий объектов
Видимость операций
Принципы видимости операций не отличаются от принципов видимости атрибутов (см. разд. 2.1.2.1.2). Видимость операции определяет, является ли операция видимой объектам классов, отличных от класса, который определяет операцию. Если она видима, то ее видимость является открытой. В противном случае она будет закрытой. Пиктограммы перед именами операций на рис. 2.10 обозначают открытую видимость.
Как правило, большинство операций объектно-ориентированной системы обладают открытой видимостью. Чтобы объект мог предоставить сервис внешнему миру, операция “обслуживания” должна быть видима. Однако, большинство объектов имеют также несколько внутренних операций “местного” значения. Видимость этих операций должна быть закрыта. Они доступны только объектам класса, в котором они определены.
Следует различать видимость операции и область действия (scope) операции. Операцию можно вызвать на объекте-экземпляре (см. разд. 2.1.1) или же на объекте- классе (см. разд. 2.1.6). В первом случае говорят, что операция обладает областью действия экземпляра. Во втором случае — областью действия класса. Например, операция, предназначенная для отыскания возраста работника, обладает областью действия экземпляра, а операция вычисления среднего возраста всех работников обладает областью действия класса.
Ассоциации
Ассоциация (association) представляет собой один из видов отношений между классами. Помимо ассоциации существуют такие виды отношений, как обобщение (generalization), агрегация (aggregation), зависимость (dependency) и некоторые другие.
Отношение ассоциации устанавливает связь между объектами данных классов. Объекты, которым требуется взаимодействовать друг с другом, могут использовать установленную связь. Обычно сообщения между объектами отправляются по ассоциативной связи.
На рис. 2.11 показано отношение между классами Order и Shipment под именем OrdShip. Это отношение дает возможность “отправить” (или связать) объект Order (Заказ) более, чем одному объекту Shipment (Поставка) (обозначенному звездочкой *). Также и объект Shipment может осуществить операцию “поставки” (быть связанным с) более, чем одного объекта Order.
Рис. 2.11. Пример ассоциацииРис. 2.11. Пример ассоциации
Рис. 2.11. Пример ассоциации
Рис. 2.11. Пример ассоциации
Порядок ассоциации
Порядок ассоциации (association degree) определяет количество классов, соединенных с помощью ассоциации. Наиболее часто встречаются ассоциации второго порядка. Такая ассоциация называется бинарной ассоциацией. Ассоциация, показанная на рис. 2.11, является бинарной.
Ее можно также определить на единственном классе. Тогда она называется унарной (unary) (или сингулярной (singular)) ассоциацией [51]. Унарная ассоциация устанавливает связь между объектами одного класса.
На рис. 2.12 показан типичный пример унарной ассоциации. Этот пример фиксирует иерархическую организационную структуру. Объект Employee (Сотрудник) “работает" “под руководством” (managed_by) другого объекта Employee или в отсутствие руководства с чьей-либо стороны (это может быть, к примеру, генеральный директор, которым никто не руководит). Объект Employee “является руководителем” (manager_of) для других сотрудников до тех пор, пока не оказывается в самом низу служебной лестницы и никем не “руководит”.
Возможны также ассоциации третьего порядка (тернарные (ternary) ассоциации), хотя их применение не рекомендуется [51].
manager_ofmanager_ofmanaged_byI0-1Employeq
manager_of
manager_of
0..*
Рис. 2.12. Пример унарной ассоциации
Кратность ассоциации •
Кратности ассоциации (association multiplicity) определяет, сколько объектов могут занимать позицию, указанную ролевым именем. Кратность говорит о том, сколько объектов целевого класса (указываемых ролевым именем) может быть ассоциировано с одним объектом исходного класса.
Кратность обозначается в виде диапазона целых чисел nl.. п2. Число nl определяет минимальное количество связываемых объектов, а п2 — максимальное количество (если мы не знаем точного максимального целочисленного значения, то вместо максимального количества может быть подставлена звездочка *). Если точное минимальное количество заранее неизвестно, но мы зиаем, что в отношении может участвовать несколько объектов, этот параметр можно вообще не указывать (подобно тому, как показано на рис.2.11).
Наиболее часто встречаются следующие значения кратности:
0. .1
0. .*
.1
1.
На рис. 2.13 показаны две ассоциации на объектах классов Teacher (Преподаватель) и Courseoffering (Предлагаемый курс). Одна из ассоциаций фиксирует закрепление преподавателей за текущими учебными курсами. Другая определяет, кто из преподавателей отвечает за учебный курс. Преподаватель может вести несколько учебных курсов или не вести ни одного (например, если преподаватель в отъезде). Учебный курс ведут один или несколько преподавателей. Один из этих преподавателей отвечает за курс. В общем случае преподаватель может отвечать за несколько курсов или не отвечать вовсе. Один и только один преподаватель руководит учебным курсом.
Рис. 2.13. Кратность ассоциации
В языке UML термин "кратность" является очень емким. Минимальная кратность, равная “нулю” или “единице”, может рассматриваться как еще одно семантическое понятие, называемое принадлежностью (membership) или участием (participation) [51]. “Нулевая" минимальная кратность означает необязательную принадлежность объекта ассоциации. “Единичная" кратность означает обязательную принадлежность. Например, предлагаемый курс обучения (объект Courseoffering) должен проводиться под руководством преподавателя (объект Teacher).
Свойство принадлежности само по себе обладает любопытными семантическими особенностями. Например, данная обязательная принадлежность может дополнительно означать, что принадлежность является фиксированной, т.е. если объект связан с целевым объектом в ассоциации, он не может быть повторно связан с другим целевым объектом в той же ассоциации.
2.L3.3. Ассоциативная связь и объем ассоциации
Ассоциативная связь представляет собой экземпляр ассоциации. Это кортеж (tuple) ссылок на объекты. Кортеж может быть набором (set) ссылок или списком (list) (упорядоченным множеством) ссылок. В общем случае кортеж может содержать только одну ссылку. Как рассматривалось выше, связь также представляет ролевое имя. Объем (extent) ассоциации — это количество связей в наборе.
На рис. 2.14 представлена конкретная реализация ассоциации OrdShip, показанной на рис. 2.11. На рис. 2.14 представлено пять связей. Следовательно, объем ассоциации равен пяти.
Понимание сущности ассоциативной связи и объема ассоциации важно для общего представления об ассоциации, однако, ассоциативные связи и объемы ассоциаций не предназначены для моделирования, их нельзя получить во время выполнения программы или каким-либо образом получить к ним явный доступ.
Рис. 2.14. Кратность ассоциации
.3.4. Ассоциативный класс
Иногда ассоциация обладает своими собственными атрибутами (и/или операциями). В качестве модели подобной ассоциации необходимо использовать класс, поскольку атрибуты могут быть определены только в классе. Каждый объект ассоциативного класса обладает значениями атрибутов и связями с ассоциированными классами. Поскольку ассоциативный класс является классом, он может быть ассоциирован с другими классами модели обычным способом.
На рис. 2.15 показан ассоциативный класс Assessment (Оценка). Объект класса Assessment хранит список баллов, общий балл и оценку, полученную студентом (Student) по предлагаемому курсу (Courseoffering).
Атрибут mark (балл) имеет тип List (Number). Это так называемый параметризованный тайп (parameterized type). Number представляет собой параметр класса List, где List (Список) определяет упорядоченное множество значений. Атрибут mark содержит список всех баллов, полученных студентом по данному курсу. То есть, если студент “Фрэд” проходит курс обучения по дисциплине “СОМР227”, со временем заполняется список (упорядоченное множество) баллов, полученных им в ходе обучения по этому курсу. Этот список баллов запоминается в объекте Assessment, который представляет собой ассоциацию между объектами “Фрэд” и “СОМР227”.
Л. Агрегация и композиция
: Агрегация {aggregation) — это отношение вида часть-целое между классом, который представляет собрание компонент (класс-супермножество (superset class')), и классами, представляющими компоненты (классы-подмножества (subset class)). Класс-супермножество содержит один или более классов-подмножеств. Свойство включения может быть сильным (агрегация по значению (aggregation by value)) или слабым (агрегация по ссылке (aggregation by reference)). В языке UML агрегация по значению называется композицией (composition), а агрегация по ссылке называется просто агрегацией.
С точки зрения системного моделирования агрегация представляет собой особый случай ассоциации, обладающей дополнительной семантикой. В частности, агрегация обладает свойствами транзитивности и асимметрии. Транзитивность означает, что если класс А содержит класс В, а класс В содержит класс С, то класс А содержит класс С. Асимметрия означает, что если А содержит В, то В не может содержать А.
Композиция обладает дополнительным свойством зависимость по существованию (existence dependency). Объект класса-подмножества не может существовать в отсутствие связи с объектом класса-супермножества. Отсюда следует, что если объект супермножества удален (уничтожен), объекты его подмножеств также удаляются.
Композиция обозначается заполненным ромбовидным “украшением” на конце ассоциативной связи, присоединенной к классу-супермножеству. Агрегация, не являющаяся композицией, помечается незаполненным ромбом. Заметим, однако, что пустой ромб можно также использовать, если в ходе моделирования вопрос о том, является ли агрегация композицией или нет, следует оставить открытым.
Рис. 2.16. Композиция и агрегация
На рис. 2.16 слева показана композиция, а справа — обычная агрегация. Всякий объект Book (Книга) является композицией объектов Chapter (Глава), а всякая глава (объект Book) — композицией разделов (объектов Section). Объект Chapter не обладает собственной независимой жизнью; он существует только в пределах объекта Book. Этого же нельзя сказать об объектах BeerBottle (Пивная бутылка). Объект может существовать вне контейнера — объекта Crate (Ящик).
Обобщение .
Обобщение (generalization) представляет собой видовое отношение между более общим классом (суперкласс или родительский класс) и боЛее Специфическим ‘видом’ класса (подкласс или дочерний класс). Подкласс является видом суперкласса. Там, где допустимо использование суперкласса, может использоваться и объект подкласса.
Обобщение делает невозможным переопределение уже заданных свойств. Атрибуты и операции, уже определенные для суперкласса, могут повторно использоваться в подклассе. Говорят, что подкласс наследует (inherit) атрибуты и методы его родительского класса. Обобщение способствует пошаговой спецификации, использованию общих свойств разными классами и лучшей локализации изменений.
Обобщение изображается в виде незаполненного треугольника на конце линии отношения, присоединенной к родительскому классу. На рис. 2.17 Person (Личность) является суперклассом, a Employee (Сотрудник) — подклассом. Класс Employee наследует все атрибуты и операции класса Person. Наследуемые свойства явно не показаны в прямоугольнике, обозначающем подкласс, — отношение обобщения отодвигает наследование на задний план. .
Обратите внимание, что наследование применимо к классам, а не объектам. Оно применимо по отношению к типам, а не значениям. Класс Employee наследует определения атрибутов full_name (полное имя) и date_of_birth (дата рождения). Объект класса Employee может быть позже реализован с использованием значений этих атрибутов (поскольку атрибуты существуют в объекте наряду с четырьмя другими атрибутами: date_hired (дата приема на работу), salary (зарплата), leave_entitlement (положенный отпуск) и leave_taken (использованный отпуск)). .
Полиморфизм
Зачастую метод, унаследованный подклассом, напрямую используется этим подклассом. Операция аде () (возраст) работает аналогично в объектах классов 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).
Наследование
В отсутствие наследования полиморфизм находит лишь ограниченное применение. Наследование (inheritance) открывает возможности для определения подкласса методом последовательного наращивания с использованием и последующим расширением описаний суперкласса. Вполне возможно, операция Manager. remainingLeave () реализована с помощью обращения к функциональным возможностям метода Employee. remainingLeave () с последующим добавлением к значению, возвращаемому этим методом, величины leave__supplement.
Несколько классов в рамках одной иерархии наследования могут объявлять одну и туже операцию. Подобная операция имеет несколько реализаций (методов), но одну и ту же сигнатуру — имя, а также количество и типы параметров, если, конечно, они определены для операции. Полиморфное поведение зависит от наследования.
Множественное наследование
Подкласс может наследовать более, чем одному суперклассу. Множественное на следование может стать источником конфликтов наследования, которые должны явно разрешаться программистом.
На рис. 2.19 класс Tutor (Наставник) наследует классам Teacher (Преподаватель) и Postgraduatestudent (Аспирант). Класс Teacher в свою очередь наследует классу Person точно так же, как класс Postgraduatestudent (через класс Student). В результате класс Tutor дважды унаследует атрибуты и операции класса Person, если только программист не укажет программной среде на необходимость однократного наследования за счет использования левого либо правого "пути” наследования (или если программная среда не применит некоторое правило умолчания, приемлемое для программиста, которое ликвидирует двойное наследование).
Множественная классификация
В большинстве современных объектно-ориентированных программных сред объект может принадлежать только одному классу. Это жесткое ограничение, поскольку в реальности объект может принадлежать одновременно нескольким классам.
Множественная классификация отличается от множественного наследования. При множественной классификации объект одновременно является экземпляром двух или более классов. При множественном наследовании класс может иметь множество суперклассов, но для каждого объекта должен быть определен единственный класс.
В примере множественного наследования на рис. 2.19 каждый объект Person (такой, как Мери или Питер) принадлежит одному классу (наиболее конкретизированному, который к нему применим). Если Мери — аспирантка (Postgraduatestudent), но не наставник (Tutor), то Мери принадлежит классу Postgraduatestudent.
Рис. 2.19. Множественное наследование
Проблема возникает при попытке уточнить значение объекта Person для нескольких ортогональных иерархий. Например, личность (Person) может быть со-
трудником (Employee) или студентом (Student), мужчиной (Male) или женщиной (Female), ребенком (Child) иди взрослым (Adult) и т.д. При отсутствии возможности множественной классификации нам необходимо определить классы для каждой разрешенной комбинации иерархий, чтобы получить, к примеру, объект Person, который является ребенком (Child), женщиной (Female) и студентом (Student) (т.е. класс, который можно было бы назвать ChildFemaleStuden) [25].
Динамическая классификация
В большинстве современных объектно-ориентированных программных сред объект не может сменить класс после того, как он реализован (создан). Это еще одно жесткое ограничение, поскольку в реальности объекты могут динамически изменять класс.
Динамическая классификация является прямым следствием множественной классификации. Объект может не только принадлежать нескольким классам, но также может в процессе своего жизненного цикла приобретать или утрачивать принадлежность к классу.
В случае схемы динамической классификации объект Person в один день может быть просто сотрудником, а в другой — менеджером (и сотрудником). В отсутствие динамической классификации деловые перемены, такие как продвижение сотрудников, трудно (или даже невозможно) декларативно моделировать в диаграмме классов. Их необходимо моделировать процедурно в диаграмме состояний или с помощью аналогичного метода моделирования.
К сожалению, язык UML не поддерживает моделирования динамической или множественной классификации. Это ставит его по отсутствию поддержки вровень с программными средами. Следовательно, наши пояснения и примеры не обогащены графическими моделями динамической и множественной классификации.
Абстрактный класс
Абстрактный класс (abstract class') — важная концепция моделирования, которая логически вытекает из понятия наследования. Абстрактный класс — это родительский класс, который не имеет непосредственных объектов-экземпляров. Только подклассы абстрактного родительского класса'могут быть материализованы как экземпляры.
• В типичном случае Класс становится абстрактным, если, по меньшей мере, одна из его операций является абстрактной. Абстрактная операция обладает сигнатурой (именем и Списком формальных аргументов), определенной в абстрактном родительском классе, однако реализации операции (метод) отличаются для конкретных дочерних классов.
Причина, по которой абстрактный класс не может порождать объекты-экземпляры, заключается в том, чТо он обладает, по меньшей мере, одной абстрактной операцией. Если допустить, что абстрактный класс создает объекты, то сообщение абстрактной операции этого объекта приведет к ошибке при выполнении программы (поскольку для абстрактной операции В классе этого объекта отсутствовала бы реализация).
’ Класс может быть абстрактным только в Том случае, если он является суперклассом, который полностью подразделяется1 На подклассы. Разделение называется полным, если подклассы содержат все возможные объекты, которые порождены в рамках наследственной иерархии. В этом случае не существует никаких “отбившихся" объектов [60]. Класс Person на рис. 2.19 не является абстрактным, нам может потребоваться реализовать объекты класса Person, которые не являются преподавателями (Teacher) и студентами (Student). Возможно также, что нам может потребоваться добавить в будущем к классу Person другие классы (например, такие Как AdminEmployee).
На рис. 2.20 показан абстрактный класс Video (в языке UML имя абстрактного класса выделяется курсивом). Этот класс ■ содержит абстрактную операцию rentalcharge (арендная плата). Ясно, что арендная плата вычисляется по-разному для видеокассет и видеодисков. Поэтому вводятся две различных реализации операции rentalcharge — для классов VideoTape и VideoDisk.
Абстрактные классы могут не иметь объектов, но очень полезны при моделировании. Они создают высокоуровневый “словарь” моделирования, без которого язык моделирования будет неполным. , -
Рис. 2.20. Абстрактный класс с абстрактной операцией
Объект-класс
Попутно мы провели различие между объектом-экземпляром и обвектом-классом. Объект-класс — это объект, область действия атрибутов и/или операций которого совпадает с данным классом. Область действия-класс здесь означает глобальный атрибут или операцию, которые применимы к самому классу и,не применимы ни к одному из объектов-экземпляров.
Поскольку в чистой объектно-ориентированной системе в качестве хранилищ выступают объекты, необходимо, чтобы объект-класс хранил глобальные атрибуты и операции. Наиболее распространенными атрибутам» с областью действия-класс, являются атрибуты, которые хранят значения, принятые по умолчанию, или агрегированные значения (такие, как суммы, итоги, средние значения). Наиболее распространенной операцией с областью действия-класс является операция создания и уничтожения объектов-экземпляров и операции, вычисляющие агрегированные значения.
На рис. 2.21 показан класс Student с атрибутом с областью действия-класс (max_courses_per_semester) (максимальное количество курсов за семестр) и диалогичной операцией averageStudentAge () (средний возраст студентов). Каждый студент может прослушать одинаковое максимальное количество курсов за семестр, поэтому данное количество должно храниться в объекте-классе. Операция, вычисляющая средний возраст студентов, обладает глобальной областью действия, поскольку ей для того, чтобы опредедить средний возраст всех студентов, необходим доступ к индивидуальному возрасту каждого студента (в объекте-экземпляре Student). ..
При работе с языком UML в прямоугольнике описания класса рекомендуется выделять атрибуты и операции с областью действия-класс. На рис. 2.21 символ $ перед именем атрибута обозначает атрибут с областью действия-класс (или статический атрибут). Для обозначения операции с областью действия-класс (или статической операции) в UML в качестве стандартной записи используется глобальное имя, заключенное внутрь скобок (« »).
Student
■student Id: String
■student name: PersonName
max_courses_per_semester: Integer
■«global» averageStudentAgeQ: Real
Рис. 2.21. Класс, содержащий атрибуты и операции с областью действия-класс
2.2. Наставление по моделированию анализа
В данном разделе представлено краткое наставление по визуальному моделированию на языке UML с использованием простого примера. Цель состоит в том, чтобы продемонстрировать различные виды диаграмм UML и показать, как они согласуются друг с другом. Каждая из диаграмм UML символизирует определенный взгляд на систему. Чтобы понять систему в целом, необходима разработка и интеграция нескольких видов диаграмм, представляющих разные взгляды.
На самом общем уровне можно выделить три типа UML-моделей— каждая со своим собственным набором диаграмм и связанных с ними конструкций.
Модель состояний (state model), которая представляет статический взгляд на систему, — это модель требований к данным. Модель состояния представляет структуры данных и отношения на них. Основной метод визуализации модели состояний состоит в использовании диаграммы классов.
Модель поведения (behavior model), которая представляет операционный взгляд на систему, — это модель функциональных требований. Модель поведения представляет биз- нес-транзакции, операции и алгоритмы над данными. Для визуализации модели поведения существует несколько способов — диаграммы прецедентов, диаграммы последовательностей, диаграммы коперации и диаграммы видов деятельности.
Модель изменения состояний (state change model), которая представляет динамический взгляд на систему, — это модель эволюции объектов со временем. Модель изменения состояний представляет возможные изменения состояний объекта (где под состоянием понимаются текущие значения атрибутов и ассоциативных связей с другими объектами). Основной метод визуализации модели изменения состояний заключается в использовании диаграммы состояний.
Internet-магазин
Internet вызвал революцию в способах ведения бизнеса. Чтобы оставаться конкурентоспособными организациям, необходимо “присутствовать” в Internet и расширить круг своих бизнес-приложений, включив в них средства электронной коммерции (е- commerce). Изменения касаются прежде всего клиентской части (front end) приложений, однако, основная серверная часть (back end) систем управления базами данных (СУБД) по- прежнему должна выполнять вполне традиционную обработку деловых операций.
Наше краткое наставление опирается на приложение Internet-магазин. В основном мы будем иметь дело с серверной частью приложения — приемом электронных заказов от клиентов, обработкой и выполнением заказов, выставлением счетов и отправкой товаров потребителю. .
| Производитель компьютеров предлагает возможность приобретения своей продукции | | через Internet. Клиент может выбрать компьютер на Web-странице производителя. Ком- I I пьютеры подразделяются на серверы, настольные и портативные. Заказчик может вы- { брать стандартную конфигурацию или построить требуемую конфигурацию в диалого- 1 j вом режиме. Компоненты конфигурации (такие, как оперативная память) представляют- | ; ся как список для выбора из доступных альтернатив. Для каждой новой конфигурации I t система может подсчитать цену.I
5 Чтобы оформить заказ, клиент должен заполнить информацию по доставке и оплате. В каче- I • стве платежных средств допускается использование кредитных карточек или чеков. После | ; ввода заказа система отправляет клиенту по электронной почте сообщение с подтверждени- i « ем получения заказа вместе с относящимися к нему деталями. Пока клиент ожидает прибы- } , тия компьютера, он может проверить состояние заказа в любое время в диалоговом режиме. | j Серверная часть обработки заказа состоит из заданий, необходимых для проверки кредита- i - способности и способа расчета клиента за покупку, истребования заказанной конфигурации - > со склада, печати счета и подачи заявки на склад о доставке компьютера клиенту.•
Наставление задумано с целью продемонстрировать методы визуального моделирования языка UML. Представленная последовательность видов деятельности по моделированию также задумана таким образом, чтобы показать зависимости между диаграммами UML.
Последовательность видов деятельности не должна рассматриваться как рекомендуемый процесс. В действительности процесс является итеративным процессом с наращиванием возможностей (раздел 1.1.3.1). Слишком сильная опора в наставлении на моделирование прецедентов в действительности не отражает сложившейся практики разработки ПО. Обычно наряду с моделированием прецедентов должно проводиться моделирование классов.
Моделирование прецедентов
Поведение системы— это ее реакция в ответ на внешние события. В языке UML внешне наблюдаемое и допускающее тестирование поведение фиксируется в виде прецедентов. Прецедент (use case) выполняет бизнес-функцию, которую может наблюдать внешний субъект и которая может быть впоследствии отдельно протестирована в процессе разработки.
Субъект (actor) — это некто или нечто (человек, машина и т.д.), взаимодействующее с прецедентом. Субъект взаимодействует с прецедентом, ожидая получить некий полезный результат.
Диаграмма прецедентов — это наглядное представление субъектов и прецедентов вместе с любыми дополнительными определениями и спецификациями. Диаграмма прецедентов представляет собой не просто некую схему, а является полностью документированной моделью предполагаемого поведения системы. Такое же понимание применимо в отношении других диаграмм языка UML. Если только не оговорено противное, то UML-диаграмма используется как синоним UML-модеяи.
. Субъекты
Субъекты и прецеденты определяются в результате анализа функциональных требований. Функциональные требования воплощаются в прецедентах. Прецеденты
удовлетворяют функциональные требования за счет предоставления субъекту полезного результата. При этом не имеет значения, в какой последовательности решает бизнес-аналитик свои задачи: сначала обозначает субъектов, а затем прецеденты, или наоборот. В нашем наставлении сначала выбираются субъекты.
Типичным графическим изображением субъекта является “штриховой человечек” (см. ниже). В общем случае субъект может быть показан в виде прямоугольного символа класса. Подобно обычному классу субъект может обладать атрибутами и операциями (связанными с событиями, сообщения о которых он отправляет и получает).
На рис. 2.22 показаны три субъекта, которые явно представлены в спецификации. Это субъекты Customer (Клиент), Salesperson (Продавец) и Warehouse (Склад).
CustomerCustomerSalespersonSalespersonWarehouseWarehouse
Customer
Customer
Salesperson
Salesperson
Warehouse
Warehouse
Рис. 2.22. Субъекты (Internet-магазин)
Обратитесь к приведенному выше содержанию наставления (с.54) и рассмотрите следующие
I расширенные требования для установления субъектов в приложении Internet-магазин.
Для знакомства со стандартной конфигурацией выбираемого сервера, настольного или портативного компьютера клиент использует Web-страницу lnternet-магвзина. При этом также приводится цена конфигурации.
Клиент выбирает детали конфигурации, с которыми он хочет познакомиться, возмож- г но, с намерением купить готовую или составить более подходящую конфигурацию. Це-
| нв для каждой конфигурации может быть подсчитана по требованию пользователя.
I 3. Клиент может выбрать вариант заказа компьютера no Internet либо попросить, чтобы ; | продавец связался с ним для объяснения деталей заказа, договорился о цене и т.п. ' । прежде, чем заказ будет фактически размещен.
I 4. Для размещения заказа клиент должен заполнить электронную форму с адресами для доставки товара и отправки счет-фактуры, а также деталями, касающимися оплаты (кредитная карточка или чек).,
После ввода заказа клиента в систему продавец отправляет на склад электронное ( требование, содержащее детали заказанной конфигурации.'
Детали сделки, включая номер заказа, номер счета клиента, отправляются по электрон- J ной почте клиенту, так что заказчик может проверить состояние заказа через Internet.;
Склад получает счет-фактуру от продавца и отгружает компьютер клиенту.;
Прецеденты
Прецедент (use case) представляет собой некий целостный набор функций, имеющих определенную ценность для субъекта. Субъект, который не общается с прецедентом, не имеет смысла, однако обратное утверждение не всегда верно (т.е. прецедент, который не общается с субъектом — вещь допустимая). Могут существовать некоторые прецеденты, которые обобщают или уточняют основной прецедент и не взаимодействуют непосредственно с субъектами. Они используются как внутренние в модели прецедентов и помогают основному прецеденту выработать результат, предоставляемый субъекту.
Прецеденты можно вывести в результате идентификации задач для субъекта. Для этого следует задаться вопросом: “Каковы обязанности субъекта по отношению к системе и чего он ожидает от системы?” Прецеденты также можно определить в результате непосредственного анализа функциональных требований. Во многих случаях функциональное требование отображается непосредственно в прецедент.
у-члад^адем*»^у-члад^адем*»^
у-члад^адем*»^
у-члад^адем*»^
Обратитесь к шагу 1 наставления и выберите прецеденты для приложения lntemet-магазин.
Для выполнения этого задания наставления мы можем построить таблицу, которая распределяет функциональные требования по субъектам и прецедентам. Обратите внимание, что некоторые потенциальные бизнес-функции могут выходить за рамки приложения — они не подлежат преобразованию в прецеденты.
В табл. 2.1 функциональные требования, приведенные на шаге 1 наставления, распределены по субъектами и прецедентам. Складские задачи сборки конфигурации компьютера и отправки его клиенту относятся к функциям, которые в данном случае выходят за рамки приложения.
На рис. 2.23 показано графическое обозначение прецедентов. Прецедент изображается в. виде эллипса, внутри или ниже которого помещается имя прецедента. Можно использовать также другие представления, включая обозначение класса в виде прямоугольника, внутри которого можно привести перечень всех необходимых атрибутов и операций прецедента.
Display StandardComputer ConfigurationDisplay StandardComputer ConfigurationBuild ComputerConfigurationBuild ComputerConfiguration
Display Standard
Computer Configuration
Display Standard
Computer Configuration
Build ComputerConfiguration
Build ComputerConfiguration
Order ConfiguredComputerOrder ConfiguredComputerRequestSalesperson ContactRequestSalesperson Contact
Order ConfiguredComputer
Order ConfiguredComputer
Request
Salesperson Contact
Request
Salesperson Contact
Verify and AcceptCustomer PaymentVerify and AcceptCustomer PaymentInform Warehouseabout OrderInform Warehouseabout Order
Verify and AcceptCustomer Payment
Verify and AcceptCustomer Payment
Inform Warehouseabout Order
Inform Warehouseabout Order
Print InvoicePrint InvoiceUpdateOrder Status
Print Invoice
Print Invoice
Таблица 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 (Печать счет-фактуры)
Диаграммы прецедентов
Диаграмма прецедентов приписывает прецеденты к субъектам. Она также позволяет пользователю установить отношения между прецедентами, конечно, если такие отношения существуют. Эти отношения рассматриваются в главе 4 (см. разд. 4.3.1.2).
Диаграммы прецедентов — основной метод визуализации для модели поведения системы. Чтобы представить полную .модель прецедентов (см. разд. 2.2.2.4), необходимо более подробное описание элементов диаграммы (прецедентов и субъектов).
Обратитесь к предыдущим заданиям наставления и изобразите диаграмму прецеден- * ; гов для приложения Internet-магазин.;
Решение для этого задания наставления можно прямо получить, воспользовавшись информацией предыдущих заданий. Единственное, что необходимо при этом учесть, — это отношения между прецедентами. Диаграмма прецедентов представлена на рис. 2.24. Смысл отношения <<extend>> (расширяет) состоит в том, что прецедент Order Configured Computer может быть расширен субъектом Customer с помощью прецедента Request Salesperson Contact.
Рис. 2.24. Диаграмма прецедентов (Internet-магазин)
2.2.2Л. Документирование прецедентов
Каждый прецедент должен быть описан с помощью документально зафиксированного потока событий (flow of events). Соответствующий текстовый документ определяет, что должна делать система, когда субъект инициирует прецедент. Структура документа, описываюгиего прецеденты, может варьироваться, однако типичное описание должно содержать следующие разделы [66].
Краткое описание.
Участвующие субъекты.
Предусловия, необходимые для инициирования прецедента.
Детализированное описание потока событий, которое включает:
основной поток, который можно разбить для того, чтобы показать подчиненные потоки событий (подчиненные потоки могут быть разделены дальше на еще более мелкие потоки, с целью улучшить удобочитаемость документа);
альтернативные потоки для определения исключительных ситуаций.
■ Постусловия, определяющие состояние системы, по достижении которого прецедент завершается.
Документ, содержащий описания прецедента, развивается по ходу разработки. Па ранней стадии определения требований составляется только краткое описание. Остальные части документа создаются постепенно и итеративно. Полный документ возникает в конце этапа спецификации требований. На этой стадии документ может быть дополнен прототипами GUI-экранов. Позднее документ по прецедентам используется для создания пользовательской документации для реализуемой системы.
Решение для этого задания наставления представлено в табличной форме (табл. 2.2). Не следует рассматривать этот способ документирования прецедента как общепринятый. Документы с описанием прецедентов могут быть многостраничными (в среднем около десятка страниц) и обладать стандартной для документов структурой, и включать, например, такие элементы, как оглавление.
Обратитесь к предыдущим заданиям наставления и подготовьте документ, содержащий описание прецедента Order Configured Computer. Чтобы установить детали, которые явно не сформулированы в требованиях, используйте ваши общие знания или информацию о типичной задаче обработки заказов.
Таблица 2.2.
Описательная спецификация прецедента Order Configured Computer (Internet-магазин)
Прецедент
Заказ сконфигурированного компьютера
Краткое опи-
Прецедент дает возможность клиенту. (Client) ввести заказ на покуп-
сание
ку. Заказ включает адреса доставки товара и оплаты счета, а также детали условий оплаты
Субъекты
Client (Клиент)
Предусловия
Клиент с помощью Internet-броузера выбирает страницу производителя компьютеров для ввода заказа. На Web-странице отображается подробная информация о сконфигурированном компьютере вместе с его ценой
Окончание табл. 2.2
Прецедент
Заказ сконфигурированного компьютера
Основной
поток
Начало прецедента совпадает с решением клиента заказать сконфигурированный компьютер с помощью выбора функции Continue (Продолжить) (или аналогичной функции) при отображении на экране детализированной информации, относящейся к заказу.
Система просит клиента ввести детали покупки, в том числе: имя продавца (если оно известно); детали, касающиеся доставки (имя и адрес клиента); детальную информацию по оплате (если она отличается от информации по доставке); способ оплаты (кредитная карточка или чек) и произвольные комментарии.
Клиент выбирает функцию Purchase (Покупка) (или аналогичную функцию) для отправки заказа производителю.
Система присваивает уникальный номер заказа и клиентский учетный номер заказу на покупку и запоминает информацию о заказе в базе данных.
Система отправляет клиенту по электронной почте номер заказа и клиентский номер клиенту вместе со всеми деталями, относящимися к заказу, в качестве подтверждения принятия заказа
Альтернатив ные потоки
Клиент инициирует функцию Purcha se до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию.
Клиент выбирает функцию Reset (Сброс) (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система дает возможность клиенту вновь ввести информацию
Постусловия
Если прецедент был успешным, заказ на покупку записывается в базу данных. В противном случае состояние системы остается неизменным
Моделирование видов деятельности
Модель видов деятельности (activity model) может представлять в графической форме поток событий для прецедента. Этот тип модели был введен только в более поздние версии UML и позволил преодолеть разрыв между высокоуровневым представлением поведения системы с помощью моделей прецедентов и намного более низким уровнем представления поведения с помощью моделей взаимодействий (диаграмм последовательностей и диаграмм кооперации).
Диаграмма видов деятельности показывает шаги вычисления. Каждый шаг соответствует состоянию (state), в котором что-либо выполняется. Поэтому шаги выполнения называются состояниями вида деятельности. Диаграмма описывает, какие шаги выполняются последовательно, а какие — параллельно. Передача управления от одного состояния вида деятельности к другому называется переходом (transition).
После завершения документа с описанием прецедента состояния вида деятельности можно установить по описанию основного и альтернативных потоков. Однако, между описанием прецедентов и моделью видов деятельности существует важное различие. Описание прецедента создается с точки зрения внешнего субъекта. Модель видов деятельности отражает внутрисистемную тачку зрения.
Модели видов деятельности могут находить и другое применение при разработке систем помимо моделирования прецедентов [25]. Они могут использоваться для анализа бизнес-процессов на высоком уровне абстракции до выработки прецедентов. И наоборот, их можно использовать на более низком уровне абстракции для разработки сложных последовательных алгоритмов или средств распараллеливания в многопоточных приложениях.
Виды деятельности
Если моделирование видов деятельности используется для визуализации последовательности видов деятельности, связанных с прецедентом, то состояния вида деятельности можно установить на основе документа описания прецедента. Как было отмечено выше, имена действиям следует присваивать, исходя из системных соображений, а не с точки зрения субъекта.
Состояние вида деятельности представляется в UML в виде прямоугольника с закругленными углами. Следует сразу уточнить, что один и тот же графический символ используется для визуализации состояния вида деятельности (activity state) и состояния действия (action state). Различие между деятельностью и действием реакцией заключается в их временном масштабе. Для осуществления деятельности требуется определенное время; действие же завершается столь быстро, что — в масштабах нашей временной шкалы — может считаться происходящим мгновенно. (Следовательно, в модели состояний (раздел 2.2.6) виды деятельности могут быть определены только в рамках состояния объекта, а действия могут появляться также при переходе между состояниями объекта.)
В табл. 2.3 изложены события, относящиеся к основному и альтернативным потокам, заимствованным из документа описания прецедента, а также обозначены состояния видов деятельности. Обратите внимание, что имя каждому виду деятельности присвоено, исходя из системной точки зрения, а не с точки зрения субъекта.
Виды деятельности, приведенные в табл. 2.3, показаны на рис. 2.25.
Таблица 2.3. Установление действий в основном и альтернативных потоках
№ п/п
Формулировка прецедента
Состояние вида деятельности
1.
Начало прецедента совпадает с решением клиента заказать сконфигурированный компьютер с помощью выбора функции Continue (или аналогичной функции) при отображении на экране детализированной информации, относящейся к заказу
Display Current Configuration (Отображение текущей конфигурации); Get Order Request (Получение запроса на заказ)
2.
Система просит клиента ввести детализированную информацию о покупке, в том числе: имя продавца (если оно известно); детали, касающиеся доставки (имя и адрес клиента); детальную информацию по оплате (если она отличается от информации по доставке); способ оплаты (кредитная карточка или чек) и произвольные комментарии
Display Purchase Form (Отображение закупочной формы)
Окончание табл. 2.3
№ п/п
Формулировка прецедента
Состояние вида деятельности
3.
Клиент выбирает функцию Purchase (или аналогичную функцию) для отправки заказа производителю
Get Purchase Details (Детализировать информацию о покупке)
4.
Система присваивает уникальный номер заказа и клиентский учетный номер заказу на покупку и запоминает информацию о заказе в базе данных
Store Order (Запомнить заказ)
5.
Система отправляет клиенту по электронной почте номер заказа и клиентский номер клиенту вместе со всеми деталями, относящимися к заказу, в качестве подтверждения принятия заказа
Email Order Details (Отправить детальную информацию по заказу)
6.
Клиент инициирует функцию Purchase до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию
Get Purchase Details;
Display Purchase Form
7.
Клиент выбирает функцию Reset (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система дает возможность клиенту вновь ввести информацию
Display Purchase Form
j Обратитесь к заданию 4 наставления. Проанализируйте основной и альтернативный по- ] ’ токи, представленные в документе описания прецедента. Установите, какие виды дея- j | тельности свойственны прецеденту Order Configured Computer. |
Диаграмма видов деятельности
Диаграмма видов деятельности (activity diagram) показывает переходы между видами деятельности. Если вид деятельности не представляет собой замкнутого цикла, то диаграмма содержит начальное состояние вида деятельности и одно или более конечных состояний вида деятельности. Полностью закрашенная окружность представляет начальное состояние. Конечное состояние изображается в виде окружности с закрашенной центральной частью (автор образно называет этот символ “бычьим глазом”).
Переходы могут разветвляться по условию и объединяться. В результате возникают альтернативные (alternative) вычислительные потоки (thread). Условие ветвления обозначается ромбом.
Переходы могут также разделяться и сливаться. В результате возникают параллельные (одновременно выполняемые) (concurrent) потоки. Распараллеливание и воссоединение переходов представляется в виде жирной линии или полосы. Заметим, что диаграмма вида деятельности, в которой отсутствуют параллельные процессы, похожа на обычную блок-схему. (Поведение с параллелизмом в наставлении не используется. Его демонстрации посвящен подраздел 4.3.2).
Get Order RequestGet Order RequestDisplayPurchase FormDisplayPurchase FormGet PurchaseDetailsGet PurchaseDetails
Get Order Request
Get Order Request
DisplayPurchase Form
DisplayPurchase Form
Get PurchaseDetails
Get PurchaseDetails
Display CurrentConfiguration
Обратитесь к заданию 4 и заданию 5 наставления и изобразите диаграмму видов деятельности для прецедента Order Configured Computer, относящегося к приложениюОбратитесь к заданию 4 и заданию 5 наставления и изобразите диаграмму видов деятельности для прецедента Order Configured Computer, относящегося к приложениюРис. 2.26. Диаграмма видов деятельности для прецедента Order Configured Computer (Internet-магазин)Рис. 2.26. Диаграмма видов деятельности для прецедента Order Configured Computer (Internet-магазин)
Обратитесь к заданию 4 и заданию 5 наставления и изобразите диаграмму видов деятельности для прецедента Order Configured Computer, относящегося к приложению
Обратитесь к заданию 4 и заданию 5 наставления и изобразите диаграмму видов деятельности для прецедента Order Configured Computer, относящегося к приложению
Рис. 2.26. Диаграмма видов деятельности для прецедента Order Configured Computer (Internet-магазин)
Рис. 2.26. Диаграмма видов деятельности для прецедента Order Configured Computer (Internet-магазин)
Puc. 2.25. Виды деятельности для прецедента Order Configured Computer (Internet-магазин)
$ Internet-магазин.
Чтобы изобразить диаграмму, виды деятельности, обозначенные в задании 5 наставления, следует соединить линиями перехода, как показано на рис. 2.26.
Начальное состояние деятельности—Display Current Configuration. Рекурсивный переход на этом состоянии служит признанием того факта, что отображение непрерывно обновляется до тех пор, пока не сработает следующий переход (переход в состояние Get Order Request). Этот факт может интерпретироваться как осознание того, что это состояние является деятельностью, а не действием.
Если при нахождении модели в состоянии Display Purchase Form сработает условие timeout (истечение времени ожидания), то выполнение модели видов деятель-
ности завершится. Иначе, активизируется состояние Get Purchase Details. Если детальные данные относительно покупки неполны, система вновь переходит в состояние Display Purchase Form. В противном случае система переходит в состояние Store Order, азатем —в состояние Email Order Details (конечноесостояние).
Обратите внимание, что на диаграмме показаны только те условные переходы, которые (всегда) появляются на выходах из состояния вида деятельности. Условные переходы, которые являются внутренними для состояния вида деятельности, не показаны явно на диаграмме. Об их существовании можно догадаться по наличию нескольких исходящих переходов, которые, возможно, сопровождаются именем условия в квадратных скобках (например, таким как [timeout] на выходе из состояния Display Purchase Form).
Моделирование классов
Систему образует системное состояние. Состояние является функцией содержимого системной информации в заданный момент времени — это функция системного текущего набора объектов-экземпляров (см. разд. 2.1.1).
Определение внутреннего состояния системы дается в модели классов (class model). К элементам, принимающим участие в моделировании классов, относятся сами классы, атрибуты и операции классов, ассоциации, агрегации и композиции, а также обобщения (см. разделы 2.1.2, 2.1.3, 2.1.4 и 2.1.5). Диаграмма классов (class diagram) дает обобщенное визуальное представление обо всех этих элементах модели.
Еще раз напоминаем, что хотя в наставлении моделирование классов рассматривается после моделирования прецедентов, на практике эти двй вида деятельности проводятся в параллель (см. разд. 3.2). Две модели взаимно дополняют одна другую вспомогательной информацией. Прецеденты облегчают выбор классов, и наоборот — модели классов могут помочь выявить упущенные прецеденты.
Классы
До сих пор мы использовали классы для определения бизнес-оббектов. Все приведенные в книге примеры классов относились к долгоживущим (постоянным или перманентным) сущностям бизнес-процессов, таким как Order (Заказ), Shipment (Доставка), Customer (Клиент), Student (Студент) и т.д. Это классы, которые определяют модель базы данных для прикладной области. По этой причине подобные классы часто называют классами-сущностями (entity class) или модельными классами. Они представляют постоянно хранимые объекты базы данных.
Классы-сущности определяют существо любой информационной системы. Анализ требований направлен преимущественно на выявление классов-сущностей. Однако, для функционирования системы требуются также классы другого типа. Пользователям системы необходимы классы, которые определяют GUI-объекты (например, такие как экранные формы), называемые пограничными классами (boundary classes) (классами представления (view classes)). Чтобы функционировать надлежащим образом, системе также необходимы классы, которые управляют программной логикой — управляющие классы (control classes) (см. разд. 5.2.3).
В зависимости от конкретного подхода к моделированию пограничные и управляющие классы могут рассматриваться или не рассматриваться на некотором уровне представления в ходе анализа требований. Моделирование классов этого типа может быть отложено до этапа проектирования системы.
| Обратитесь к требованиям, определенным в содержании наставления (разд. 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.4
№
п/п
Требование
Классчуцность
6.
Детали сделки, включая номер заказа, номер счета клиента, отправляются по электронной почте клиенту, так что заказчик может проверить состояние заказа через Internet
Order; Customer; Orderstatus (Состояние заказа)
7.
Склад получает счет-фактуру от продавца и отправляет компьютер клиенту
Invoice;Shipment
Выделение классов представляет собой итеративную задачу, и первоначальный перечень предполагаемых классов, как правило, претерпевает изменения. При определении того, являются ли понятия, присутствующие в требованиях, искомыми классами, могут помочь ответы на некоторые вопросы. Вот эти вопросы.
Является ли понятие “вместилищем" данных?
Обладает ли оно отдельными атрибутами, способными принимать разные значения?
Можно ли создать для него множество объектов-экземпляров?
Входит ли оно в границы прикладной области?
Перечень классов, приведенный в табл. 2.4, кроме того, вызывает много вопросов. К примеру, следует задаться такими вопросами.
В чем различие между классами Conf iguredComputer и Order? Помимо прочего, мы не собираемся хранить информацию о сконфигурированном компьютере (Conf iguredComputer), до тех пор пока заказ (объект Order) не размещен, или это не так?
Совпадает ли смысл понятия Shipment, приведенный в требованиях №4 и №7? Скорее всего, нет. Необходим ли нам класс Shipment, если нам известно, что поставка является обязанностью склада и, таким образом, выходит за рамки приложения? (Разд. 2.2.2.2).
Не является ли понятие элемента конфигурации (Configurationitem) просто атрибутом понятия сконфигурированного компьютера (Conf iguredComputer)?
Является понятие состояние заказа (Orderstatus) самостоятельным классом или же атрибутом понятия заказа (Order)?
Является ли понятие продавца (Salesperson) самостоятельным классом или же атрибутом понятий (Order) и (Invoice)?
Дать ответы на эти и аналогичные вопросы не легко, для этого требуется глубокое знание требований прикладной области. В целях дальнейшей работы с данным наставлением мы выбрали классы, перечень которых приведен на рис. 2.27. Обратите внимание, что класс Customer (Клиент) уже появился в качестве субъекта на диаграмме прецедента — отсюда примечание “с точки зрения прецедента”.
Рис. 2.27. Классы (Internet-магазин)Рис. 2.27. Классы (Internet-магазин)
Рис. 2.27. Классы (Internet-магазин)
Рис. 2.27. Классы (Internet-магазин)
Атрибуты
Структура класса определяется его атрибутами (разд. 2.1.2.1). При первоначальном объявлении класса аналитик должен иметь некоторое представление о структуре атрибутов. На практике основные атрибуты обычно назначаются классу сразу после его добавления к модели.
Customer(from Use Case View)^customer name: String@$customer address: String0phone_number: Stringflemail_address: StringCustomer(from Use Case View)^customer name: String@$customer address: String0phone_number: Stringflemail_address: StringConfigurationitem Я item type: String PI item descr: StringConfigurationitem Я item type: String PI item descr: StringOrderS8order_number: String Qorder_dste: Date g5shlp_address: String | ^^rdertotal: Currency y^order status: String Qjsalesperson_name: StringOrderS8order_number: String Qorder_dste: Date g5shlp_address: String | ^^rdertotal: Currency y^order status: String Qjsalesperson_name: StringComputer§flcomputer name: String ^Jstandard_price: CurrencyComputer§flcomputer name: String ^Jstandard_price: CurrencyConfiguredComputerQcomputer_name: String |||configured_price: CurrencyConfiguredComputerQcomputer_name: String |||configured_price: Currency
Customer
(from Use Case View)^customer name: String@$customer address: String0phone_number: Stringflemail_address: String
Customer
(from Use Case View)^customer name: String@$customer address: String0phone_number: Stringflemail_address: String
Configurationitem Я item type: String PI item descr: String
Configurationitem Я item type: String PI item descr: String
Order
S8order_number: String Qorder_dste: Date g5shlp_address: String | ^^rdertotal: Currency y^order status: String Qjsalesperson_name: String
Order
S8order_number: String Qorder_dste: Date g5shlp_address: String | ^^rdertotal: Currency y^order status: String Qjsalesperson_name: String
Computer
§flcomputer name: String ^Jstandard_price: Currency
Computer
§flcomputer name: String ^Jstandard_price: Currency
ConfiguredComputer
Qcomputer_name: String |||configured_price: Currency
ConfiguredComputer
Qcomputer_name: String |||configured_price: Currency
InvoiceInvoice number: String |P|invoice_date: Date: CurrencyInvoiceInvoice number: String |P|invoice_date: Date: Currency
Invoice
Invoice number: String |P|invoice_date: Date
: Currency
Invoice
Invoice number: String |P|invoice_date: Date
: Currency
Payment
* ayment method: String Iodate received: Date ^amount_received: Currency
Puc. 2.28. Элементарные атрибуты (Internet-магазин)
Наставлена аналйзу:задание8(1п1егп
—' .Sa кя- *..& V* ч •№«№_ а* . Wl<IH Л№ ..Жи.З® *'<*»- ОЯ* <
5 Обратитесь к заданиям 5, 6 и 7 наставления. Подумайте над атрибутами для классов, ' показанных на рис. 2.27. Рассмотрите только атрибуты, тип которых принадлежит к |
: элементарным (разд. 2.1.2.1).J
На рис. 2.28 показаны классы с элементарными атрибутами. При этом приведены только наиболее интересные атрибуты. Атрибуты класса Configurationitem требуют некоторых пояснений. Значениями атрибута item_type являются типы элементов конфигурации, такие как процессор, память, монитор, жесткий диск и т.д. Атрибут item_descr содержит более подробное описание типа Элемента. Например, процессор, входящий в конфигурацию, может представлять собой процессор марки Intel с частотой 600 МГц, имеющий кэш объемом 256 Кбайт.
Совершенно очевидно, что при определении атрибутов, приведенных на рис. 2.28, существуют широкие возможности для выбора произвольных вариантов. Если читатель попытается предложить свое собственное решение для этого задания наставления, то другие, отличные от предложенных в книге, интерпретации возможны и конечно допустимы.
Ассоциации
Ассоциации, связывающие классы, устанавливают пути, облегчающие кооперацию объектов (разд. 2.1.3). В реализуемой системе ассоциации представляются типами атрибутов, которые обозначают ассоциированные классы (разд. 2.1.2.1.1). В модели анализа ассоциации представлены соединительными линиями.
Наставление по анализу: задание 9 <1пСете£м« азинН‘;
Обратитесь к предыдущим заданиям наставления. Рассмотрите классы, показанные на ’ рис. 2.28. Подумайте, какие пути доступа между этими классами необходимы для пре- !
? цедентов. Добавьте к модели классов ассоциации.>
Рис. 2.29. Ассоциации (Internet-магазин)
На рис. 2.29 показаны наиболее очевидные ассоциации между классами. При определении кратности ассоциаций был сделан ряд предположений (разд. 2.1.3.2). Заказ (Order) поступает от одного клиента (Customer), однако клиент может разместить несколько заказов. Заказ не принимается до тех пор, пока не определены реквизиты платежа (Payment) (отсюда, ассоциация типа “один к одному”). Заказ не должен обладать связанной с ним счетом-фактурой (Invoice), однако счет-фактура всегда связана с единственным заказом. Заказ делается на один или несколько сконфигурированных компьютеров (ConfiguredComputer). А компьютер с данной конфигурацией может заказываться многократно или не заказываться вовсе.
Агрегации
Агрегация и композиция являются более сильной формой ассоциативной связи, которой присуща семантика принадлежности (разд. 2.1.4). В типичной коммерческой программной среде агрегация и композиция, скорее всего, должны быть реализованы подобно ассоциации — с помощью типов атрибутов, которые обозначают ассоциированные классы (разд. 2.1.2.1.1).
^ Настаалениепо! 1изу: задами! it Memel ник) ^
■ Обратитесь к предыдущим заданиям наставления. Рассмотрите модели, представлен- ( ные на рис. 2.28 и 2.29. Добавьте к модели классов агрегации.
На рис. 2.30 к модели добавлены отношения агрегации. Компьютер (Computer) обладает (как вы помните, выше говорилось о свойстве принадлежности'.) одним или более элементами конфигурации (Configurationitems). Подобно этому, сконфигурированный компьютер (ConfiguredComputer) состоит из одного или нескольких элементов (Configurationitems).
Рис. 2.30. Агрегации (Internet-магазин)
Обобщения
Обобщение представляет собой мощное средство повторного использования ПО, однако, оно также способно в значительной мере упростить и прояснить модель
(разд. 2.1.5). Упрощение модели семантически не находит выражения в ее графическом изображении. Обобщение обычно используют как метод создания дополнительных родовых классов (как правило, абстрактных). Упрощение достигается за счет увеличения точности, с которой существующий класс может быть ассоциирован с наиболее подходящими (т.е. на наиболее удобном уровне абстракции) классами в иерархии обобщения.
На рис. 3.31 показана модифицированная модель, в которой класс изменен на абстрактный класс Computer, являющийся родовым для двух конкретных подклассов — Standard Computer и ConfiguredComputer. Теперь классы Order и Conf igurationltem связаны с классом Computer, который может быть либо классом Standardcomputer, либо классом ConfiguredComputer.
Рис. 2.31. Обобщение (Internet-магазин)
2.2Л.6. Диаграмма классов
Диаграмма классов составляет, так сказать, “сердце” и “душу” объектноориентированной системы. В данном наставлении ставится цель только продемонстрировать возможности статического моделирования применительно к модели классов.
В классы пока что не введено ни одной новой операции. Операции принадлежат скорее к сфере проектирования, чем анализа. После того, как операции в конечном итоге вводятся в классы, модель классов в явном виде определяет поведе
ние системы.
Обратитесь к предыдущим заданиям наставления. Скомбинируйте модели, представленные на рис. 2.28 и 2.30, таким образом, чтобы показать полную диаграмму классов. Измените содержимое атрибутов классов, как того требует введение обобщающей иерархии.
На рис. 2.32 показана диаграмма классов для приложения Internet-магазин. Это еще не законченное решение, поскольку, например, для практического решения может потребоваться введение дополнительных атрибутов.
Рис. 2.32. Диаграмма классов (Internet-магазин)
Моделирование взаимодействий
Моделирование взаимодействий (interaction modeling) охватывает вопросы взаимодействия между объектами, необходимыми для выполнения прецедента. Модели взаимодей-
ствия используются на более развитых стадиях анализа требований, когда становится известной модель классов, так что ссылки на объекты опираются на модель классов.
Приведенное выше наблюдение служит опорой для установления основного различия между моделированием видов деятельности (см. разд. 2.2.3) и моделированием взаимодействий. Модели обоих типов описывают поведение одного прецедента (как правило). Однако, моделирование видов деятельности осуществляется на более высоком уровне абстракции — оно отражает последовательность событий вне связи событий с объектами. Моделирование взаимодействий отображает последовательность событий (сообщений) в их связи с действующими в кооперации объектами.
Диаграммы взаимодействий разделяются на два вида — диаграммы последовательностей и диаграммы кооперации. Они могут использоваться как взаимозаменяемые, и, конечно, многие CASE-средства поддерживают автоматическое преобразование одной модели в другую. Разница между моделями заключается в акцентах. Модели последовательностей концентрируются на временных последовательностях событий, а в моделях кооперации основное внимание уделяется отношениям между объектами [76].
В настоящей книге для этих типов моделей выбрано следующее применение: диаграммы последовательностей используются на этапе анализа требований, а диаграммы кооперации — системного проектирования. Этот выбор соответствует общепринятой практике разработки ИС.
Взаимодействия
Взаимодействие (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) отправителя.
Сообщение может быть отправлено коллекции (collection) объектов (коллекция может быть набором, списком, массивом объектов и т.д.). Довольно частой является ситуация, когда вызывающий объект связан с несколькими объектами-получателями (поскольку кратность ассоциации указана как “один ко многим’’ или “многие ко многим”). Итеративный маркер— звездочка перед обозначением сообщения — указывает на процесс итерации сообщения по всей коллекции.
Обратитесь к диаграмме видов деятельности на рис. 2.26. Рассмотрите первый шаг диаграммы Display Current Configuration. Постройте диаграмму последовательностей для этого шага.Обратитесь к диаграмме видов деятельности на рис. 2.26. Рассмотрите первый шаг диаграммы Display Current Configuration. Постройте диаграмму последовательностей для этого шага.Диаграмма последовательностей для “отображения текущей конфигурации ” показана на рис. 2.33. Внешний субъект— клиент— (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса Configurationwindow ([диалоговое] окно конфигурации). В результате создается (“материализуется как экземпляр”) новый объект ConfWin. (Класс Configurationwindow — пограничный класс (разд. 2.2.4.1).)Диаграмма последовательностей для “отображения текущей конфигурации ” показана на рис. 2.33. Внешний субъект— клиент— (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса Configurationwindow ([диалоговое] окно конфигурации). В результате создается (“материализуется как экземпляр”) новый объект ConfWin. (Класс Configurationwindow — пограничный класс (разд. 2.2.4.1).)•< aConfWin г' • fiflu A/inc•< aConfWin г' • fiflu A/incopenNew ' Tl getConfopenNew ' Tl getConfaComp:ComputeraComp:Computer: ConfigurationItem: ConfigurationItemi i i getConfltem(outitem_rec) ।i i i getConfltem(outitem_rec) ।displeyComputer(item_recset)displeyComputer(item_recset)i i i i i i i i i ii i i i i i i i i iPuc. 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.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.26. Рассмотрите первый шаг диаграммы Display Current Configuration. Постройте диаграмму последовательностей для этого шага.
Обратитесь к диаграмме видов деятельности на рис. 2.26. Рассмотрите первый шаг диаграммы Display Current Configuration. Постройте диаграмму последовательностей для этого шага.
Диаграмма последовательностей для “отображения текущей конфигурации ” показана на рис. 2.33. Внешний субъект— клиент— (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса Configurationwindow ([диалоговое] окно конфигурации). В результате создается (“материализуется как экземпляр”) новый объект ConfWin. (Класс Configurationwindow — пограничный класс (разд. 2.2.4.1).)
Диаграмма последовательностей для “отображения текущей конфигурации ” показана на рис. 2.33. Внешний субъект— клиент— (Customer) принимает решение об отображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса Configurationwindow ([диалоговое] окно конфигурации). В результате создается (“материализуется как экземпляр”) новый объект ConfWin. (Класс Configurationwindow — пограничный класс (разд. 2.2.4.1).)
•< aConfWin г' • fiflu A/inc
•< aConfWin г' • fiflu A/inc
openNew ' Tl getConf
openNew ' Tl getConf
aComp:
Computer
aComp:
Computer
: ConfigurationItem
: ConfigurationItem
i i i getConfltem(outitem_rec) ।
i i i getConfltem(outitem_rec) ।
displeyComputer(item_recset)
displeyComputer(item_recset)
i i i i i i i i i i
i i i i i i i i i i
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.
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.34 в начале отображают элементы стандартной конфигурации. Однако, эти поля для выбора заполнены другими не стандартными элементами, которые клиент может выбрать для создания новой допустимой конфигурации. Диаграмма последовательностей на рис. 2.33 не моделирует способ и время заполнения полей выбора данными.
Рис. 2.34. Пример окна выбора конфигурации (Internet-магазин)
Операции
Хотя введение операций в классы зачастую откладывается до этапа проектирования, в данном наставлении будет показано, что исследование взаимодействий между классами может привести к выявлению операций. Между взаимодействиями и операциями существует прямая зависимость. Каждое сообщение обращается к операции в вызываемом объекте. Имена операции и сообщения совпадают.
Конечно, это однозначное отображение между сообщениями модели взаимодействий и методами реализуемых классов может иметь смысл только в том случае, если модель взаимодействий образует детализированный технический проект, что вряд ли возможно и может потребоваться на этапе анализа.
Попутно заметим, что подобное однозначное соответствие существует между сообщениями и ассоциациями, когда сообщение пересылается между постоянными (модельными) объектами. Эти сообщения должны поддерживаться постоянными связями (разд. 2.1.1.3.1). Таким образом наличие сообщения в диаграмме последовательностей обусловливает необходимость в ассоциации в диаграмме классов.
Обратитесь к диаграмме видов деятельности на рис. 2.32 и диаграмме последовательностей на рис. 2.33. Для каждого сообщения о взаимодействии на диаграмме последовательностей введите операцию в соответствующий класс на диаграмме классов. Не перерисовывайте всю диаграмму классов—только отобразите классы, расширенные за счет операций.Обратитесь к диаграмме видов деятельности на рис. 2.32 и диаграмме последовательностей на рис. 2.33. Для каждого сообщения о взаимодействии на диаграмме последовательностей введите операцию в соответствующий класс на диаграмме классов. Не перерисовывайте всю диаграмму классов—только отобразите классы, расширенные за счет операций.
Обратитесь к диаграмме видов деятельности на рис. 2.32 и диаграмме последовательностей на рис. 2.33. Для каждого сообщения о взаимодействии на диаграмме последовательностей введите операцию в соответствующий класс на диаграмме классов. Не перерисовывайте всю диаграмму классов—только отобразите классы, расширенные за счет операций.
Обратитесь к диаграмме видов деятельности на рис. 2.32 и диаграмме последовательностей на рис. 2.33. Для каждого сообщения о взаимодействии на диаграмме последовательностей введите операцию в соответствующий класс на диаграмме классов. Не перерисовывайте всю диаграмму классов—только отобразите классы, расширенные за счет операций.
Решение для этого задания наставления показано на рис. 2.35. Изменениям подверглись три класса. Класс Configurationwindow — это пограничный класс. Два других класса— это классы-сущности, представляющие постоянные объекты базы данных. Операция openNew выбрана в качестве шаблона операции конструктора. Это означает, что операция openNew будет реализована в качестве метода конструктора, который порождает новые объекты класса.
«boundary»Configurationwindow
■«constructor» openNewf)
■displayComp uter(item_recset)
Computer■computer name: String ■«abstract» getConf()Computer■computer name: String ■«abstract» getConf()Configurationitem■item type: String Щ item_descr: String■getConf ltem(out item_rec)Configurationitem■item type: String Щ item_descr: String■getConf ltem(out item_rec)
Computer
■computer name: String ■«abstract» getConf()
Computer
■computer name: String ■«abstract» getConf()
Configurationitem
■item type: String Щ item_descr: String
■getConf ltem(out item_rec)
Configurationitem
■item type: String Щ item_descr: String
■getConf ltem(out item_rec)
Puc. 2.35. Использование взаимодействий для введения операций в классы (Internet-магазин)
Класс Computer — абстрактный класс. Операция getConf — абстрактная операция, наследуемая подклассами (ConfiguredComputer и Standardcomputer). Эти подклассы обеспечивают собственную реализацию операции getConf.
Диаграмма последовательностей
Как уже упоминалось, для каждого прецедента зачастую строится отдельная диаграмма последовательностей. Поскольку каждый прецедент вероятно должен быть выражен через диаграмму видов деятельности, диаграмма последовательностей строится для каждой диаграммы видов деятельности. Использование нескольких взаимоувязанных точек зрения на одну и ту же систему является краеугольным камнем надлежащего моделирования.
Решение для сформулированных выше вопросов показано на рис. 2.36. Для удобства диаграмма последовательностей разделена на две части (а именно, линии жизни объектов Order и Orderwindow разделены на две части).
: Customer
: ConfigurationWindow
: Computer
: Order
: Orderwindow
acceptConf
openNew
getConf
prepareforOrder
submitOrder
linkComputer
emailorder
displ^Order
storeOrder
linkPa
linkcustomer
: Order
: OrderWindow
: Customer
: Payment
Computer
displsyOrder
storeOrder
linkCustomer
linkPayment
Puc. 2.36. Диаграмма последовательностей для диаграммы видов деятельности Order Configured Computer (Internet-магазин)
Обратитесь к диаграмме видов деятельности на рис. 2.26 и постройте для нее диаграм- i му последовательностей. Чтобы упростить диаграмму, не показывайте обмен сообще * ниями между объектами Computer и Configurationitem. ; Кроме того, не изображайте объектов подклассов — считайте, что объект computer ; принадлежит либо классу Standardcomputer, либо классу Conf iguredComputer.
Покажите только сообщения активизации. Возвраты управления подразумеваются. За- : давать аргументы операций или другую управляющую информацию нет необходимости, I
Диаграмма последовательностей во многом является самоочевидной. Пояснения к первым двум сообщением были сделаны в задании 13 наставления. Сообщение acceptConf вызывает отправку сообщения prepareForOrdeг объекту : Order. Это приводит к созданию временного объекта : Order, отображаемого в “объекте-окне” :OrderWindow.
В ответ на принятие клиентом детализированных условий заказа (submitOrder) объект : OrderWindow инициирует (storeOrder) создание постоянного объекта : Order. После этого объект-заказ : Order устанавливает связь с заказанным компьютером (: Computer), а также соответствующими клиентом (: Customer) и платежом : Payment. После того, как эти объекты постоянно связаны в базе данных, объект : Order отправляет электронное сообщение emailOrder внешнему субъекту-клиенту (Customer).
Обратите внимание на двойное использование сущности : Customer — в качестве внешнего субъекта, представленного объектом, и внутреннего объекта-класса. Подобная двойственность довольно часто встречается в моделировании. Клиент (Customer) является по отношению к системе одновременно и внешней, и внутренней сущностью. Он представляет собой внешнюю сущность, поскольку взаимодействует с системой извне. Однако информация о клиенте должна храниться в системе, чтобы иметь возможность установить идентичность внешнего клиента и внутренней сущности, о которой знает система.
Моделирование состояний
Модель взаимодействий (interaction model) является источником детализированной спецификации прецедента. Модель состояний (statechart model) служит детализированным описанием класса или, более точно, динамических изменений состояний класса. Эти динамические изменения обычно описывают поведение объекта в рамках нескольких прецедентов.
Состояние (state) объекта обозначается текущими значениями его атрибутов (как элементарных атрибутов, так и атрибутов, обозначающих другие классы). Модель состояний (statechart model) фиксирует возможные состояния, в которых может находиться класс, и эффективно фиксирует “жизненный путь” класса. На протяжение своего жизненно цикла объект остается одним и тем же — его идентичность никогда не изменяется (разд. 2.LL3). Однако состояние объекта изменяется.
Диаграмма состояний представляет собой двудольный граф состояний (прямоугольников с закругленными углами) и переходов (стрелки), вызванных событиями. Основная концепция состояний и событий совпадает с концепцией, которая известна нам по диаграмме видов деятельности. Различие же заключается в том, что “состояния графа видов деятельности представляют состояния выполнения вычисления, а не состояния обычного объекта” [76].
Состояния и переходы
Значения атрибутов объекта изменяются, однако не все подобные изменения приводят к переходу межд^ состояниями. Рассмотрим объект BankAccount [банковский счет) и связанное с ним бизнес-правило, по которому банк отказывает- :я от взимания платы за услуги по ведению счета, когда остаток на счету (balance) превышает 100000 долларов. Можно сказать, что объект BankAccount переходит в привилегированное (priviledged) состояние. В противном случае объект пребывает в обычном состоянии. Остаток на счету (balance) изменяется после каждого перехода, соответствующего операции по снятию/вкладу денег, однако, состояние изменяется только тогда, когда баланс превышает или становится ниже порога в 100000 долларов.
[/ Наставление по[/ Наставление по
[/ Наставление по
[/ Наставление по
Рассмотрите класс Invoice (Счет-фактура), относящийся к приложению Internet- •
магазин. Из модели прецедентов нам известно, что клиент определяет способ оплаты [ (кредитная карточка или чек) за компьютер, когда закупочная форма заполнена и ото- I слана производителю. Это приводит к генерации заказа и последующей подготовке I
счет-фактуры. Однако, диаграмма прецедентов не проясняет вопрос о том, когда же ; производится фактическая оплата в соответствии со счет-фактурой. Можно, к примеру, { предположить, что оплата может осуществляться до или после того, как счет-фактура 1 выдана, а также предположить возможность частичной оплаты.
Из модели класса нам известно, что счет-фактура для заказа подготавливается продавцом, • однако, в конечном итоге она передается на склад. Склад отправляет счет-фактуру клиенту ” одновременно с доставкой компьютера. Важно отметить, что состояние оплаты счет-фактуры ; отслеживается в системе, так что счет-фактуры снабжены надлежащими комментариями. |
Изобразите диаграмму состояний, которая фиксирует возможные состояния счет- i фактуры в той мере, в которой это касается платежей.•
Приведенный выше пример схватывает сущность моделирования состояний. Модели состояний строятся для классов, которые характеризуются не просто изменениями состояний, а изменениями состояний, представляющими определенный интерес с точки зрения предметной области. Решение о том, что представляет интерес, а что нет, является прерогативой моделирования бизнес-процессов. Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Они относительно независимы от конкретных прецедентов. В действительности прецеденты должны соответствовать бизнес-правилам.
На рис. 2.37 показана модель состояний для класса Invoice. Начальным состоянием объекта Invoice является состояние Unpaid (не оплачено). Из состояния Unpaid возможны два перехода. При наступлении события partial payment (частичная оплата) объект Invoice переходит в состояние Partly Paid (частично оплачено). Допускается только одна частичная оплата. Наступление события final payment (окончательная оплата), когда объект Invoice находится в состоянии Unpaid или Partly Paid, инициирует переход в состояние Fully Paid (полностью оплачено). Это конечное состояние.
Рис. 2.57. Состояния и события для класса
Invoice (1п1етеЬмагазин)
Диаграмма состояний
Диаграмма состояний обычно присоединяется к классу, но, в общем случае, она может присоединяться к другим модельным представлениям, например, прецедентам. Диаграмма состояний, присоединенная к классу, определяет способ реагирования объектов класса на события. Более точно, диаграмма определяет — для каждого состояния объекта — действие (action), выполняемое объектом при получении им сигнала о событии. Один и тот же объект может выполнять различные действия в ответ на одно и то же событие в зависимости от состояния объекта. Выполнение действия, как правило, вызывает изменение состояния.
Полное описание перехода (transition) состоит из трех частей:
event (parameters) [guard] / action.
Каждая из частей является необязательной. Если строка перехода самоочевидна, допустимо опустить все компоненты. Событие — это кратковременное явление, которое воздействует на объект. Оно может обладать параметрами, например, кнопка мыши нажата (правая_кнопка). Событие может быть защищено ограждающим уело вием (guard), например, кнопка мыши нажата (правая_кнопка) [внутри окна]. Только в том случае, если условие принимает значение “истина”, событие срабатывает и воздействует на объект.
Различие между событием и защитой не всегда очевидно. Это различие состоит в том, что событие “происходит” и оно может быть даже сохранено до тех пор, пока объект не приготовится к его обработке. С этих позиций защитное условие проверяется на истинность, чтобы определить, должен ли сработать переход.
Действие (action) представляет собой короткое атомическое вычисление, которое выполняется при срабатываний перехода. Действие также может быть связано с состоянием. В общем случае действие — это отклик объекта на обнаруженное событие. Состояние может содержать более продолжительное вычисление — вид деятельности (activity).
Состояние может состоять из других состояний, которые называются вложенными (nestedstate). Составное состояние (composite state) является абстрактным — это всего лишь родовое имя для всех вложенных состояний. Переход, который берет начало из-за границы составного состояния, означает, что он может сработать от любого из вложенных состояний. Это делает диаграмму более ясной и лаконичной. Конечно, пере-
ход, который берет начало вне границы составного состояния, может сработать от вложенного состояния.
Диаграмма состояний для класса Order показана на рис. 2.38. Начальное состояние объекта класса — New Order (новый заказ). Это одно из вложенных состояний составного состояния Pending (ожидающий [заказ]) — к другим относятся состояния Back Order (невыполненный заказ) и Future Order (будущий заказ). Из каждого из этих трех состояний, вложенных в состояние Pending, возможны два перехода.
Рис. 2.38. Диаграмма состояний для класса Order (Internet-магазин)
Наставление по ана i£ ззд, ^/ : Ч .
Обратитесь к предыдущим заданиям наставления. Рассмотрите класс Order (заказ), отно- I сящийся к приложению /nternet-магазин. Обдумайте, в каких состояниях может находиться I класс Order, начиная от отправки заказа в систему и заканчивая его заполнением.
Рассмотрите ситуации, когда заказанный компьютер находится на складе в готовом ви- ; де или же его необходимо сконфигурировать в отдельности, чтобы удовлетворить ваши [ требования. Вы можете также задать определенный день, в который вы бы хотели полу- ; чить компьютер, даже если он имеется на складе. ; Вы можете отменить ваш заказ в любое время прежде, чем компьютер будет доставлен. [ Вам не требуется моделировать ситуацию взимания штрафа, связанную со слишком | поздним отказом. Изобразите диаграмму состояний для класса Order. , *
Переход в состояние Canceled (отменен) защищено условием [canceled]. Должна существовать возможность — без изменения правил моделирования состояний — заменить защитное условие событием cancel. Переход в состояние Ready to Ship (готов к доставке) помечен полным описанием, содержащим событие, защиту и действие.
2.3. Постановки задач для исследуемых примеров
Чтобы проиллюстрировать различные виды деятельности по моделированию, на протяжении всей книги разбираются четыре примера. Разбор примеров представлен с использованием того же подхода, который использовался для наставления “Internet- магазин” — сначала формулируются вопросы, а затем даются решения. Это дает возможность читателям предложить собственные решения, а затем сравнить их с предложенными в книге. Итак, мы разберем следующие четыре примера.
Запись на университетские курсы.
Магазин видеопроката.
Управление контактами с клиентами.
Телемаркетинг.
2.3.1. Запись на университетские курсы
Запись на университетские курсы — классический пример из учебников [66], [85]. Это удивительно сложная прикладная область с богатым набором бизнес-правил, которые относительно часто изменяются, при этом данные за прошлые периоды должны тщательно храниться вместе с действовавшими на то время бизнес-правилами.
Средний по размерам университет проводит набор студентов и аспирантов дневной и I вечерней формы обучения для подготовки по ряду специальностей. Учебная структура унив- ; ерситета состоит из факультетов. Факультет имеет в своем составе несколько кафедр. Хотя j
обучение и присвоение степени по определенной специальности является прерогативой । факультета, обучение по специальности может включать дисциплины, преподаваемы на j
других факультетах. В действительности, университет гордится свободой, предоставляемой им студентам в выборе дисциплин, изучаемыхдля получения специальности.
Гибкость выбора учебных курсов оказывает дополнительную нагрузку на университетскую систему набора. Индивидуально подобранным программам обучения должны быть противопоставлены правила, регулирующие получение степени по выбранной специальности. Такие правила можно сформулировать, например, в виде структуры дисциплин, изучение которых является обязательной предпосылкой получения диплома, так, чтобы студент мог прослушать обязательные для данной специальности курсы. Выбор студентами дисциплин может быть ограничен несоответствием расписаний, максимальной вместимостью аудиторий и т.д.
Гибкость в получении образования, предлагаемого университетом, стала одной из причин устойчивого роста количества студентов. Однако, для сохранения своих традиционно сильных сторон система набора — по-прежнему, частично ручная — должна быть заменена новым программным решением. Предварительный поиск готовых программных пакетов не дал результатов. Университетская система набора достаточно уникальна, чтобы оправдать разработку ПО собственными силами.
От системы требуется оказывать помощь в предварительной деятельности по записи на курсы и управляться с процедурами набора. Предварительная деятельность по записи должна включать рассылку оценок последнего семестра студентам наряду с инструкциями по записи на лекции. В период записи на курсы система должна принимать заявленные студентами программы обучения и проверять их на предмет обязательности, конфликтов расписания, вместимости аудиторий, специальных санкций и т.д. Решения по некоторым проблемам могут требовать консультаций с научными руководителями или профессорами, ответственными за преподавание дисциплин.
Двух одинаковых университетов не существует. У каждого есть собственные любопытные особенности, которые можно использовать при разборе примеров, чтобы уделить основное внимание определенным аспектам системного анализа и проектирования. Основное внимание при разборе данного примера посвящается сложностям, которые возникают при моделировании состояний, связанным с обработкой временных факторов (временной информации) и добыванием бизнес-правил в структуры данных.
Магазин видеопроката
Наш второй пример — обычное бизнес-приложение, характерное для малого бизнеса. Это приложение предназначено для поддержки работы небольшого магазина видеопроката. В видеомагазине имеется широкий выбор последних и наиболее популярных фильмов на видеокассетах и компакт-дисках. Основным видом деятельности магазина является прокат видеофильмов.
Типичную компьютерную систему для поддержки работы небольшого видеомагазина можно получить посредством настройки готового ПО или настройки какого- либо другого патентованного решения. Система может базироваться на одной из популярных систем управления базами данных (СУБД), способной функционировать на компьютере, ресурсов которого хватает для решения задач малого бизнеса.
Несмотря па то, что базис системы составляет ПО баз данных, она может быть поначалу развернута на одной машине. GUI-интерфейс должен, вероятно, разраба- тывться с использованием простого языка четвертого поколения (4GL), с возможностями создания экранных изображений, генерации программного кода и простым подключением к базе данных.
7УЖГ$ййй^>й7УЖГ$ййй^>йОтличительной чертой магазина видеопроката как примера для анализа является развитая цепочка видов деятельности — начиная с заказа видеопродукции с помощью управления ассортиментом и до расчетов с пользователями за прокат видеофильмов. В известном смысле — это модель цепочки ценностей, функционирующей в ограниченных масштабах (см. 1.2.2).
7УЖГ$ййй^>й
7УЖГ$ййй^>й
о Постанов* задач ? *=<
-- - -* б/ ■< <-<<'.. у.»,-ея= х1®V.$*f>
Вновь открывшийся видеомагазин намерен предложить прокат видеокассет и дисков широкой публике. Директор магазина полон решимости начать свою деятельность, опираясь ; на поддержку компьютерной системы. Директор уже навел справки по некоторым про- ■ граммным пакетам для малого бизнеса, которые могли бы пригодиться для настройки и : последующего развития. Для оказания помощи в выборе пакета магазин нанял бизнес- ■ аналитика, который занимается определением и спецификацией требований.
' Поначалу ассортимент магазина составляет около тысячи видеокассет и пятьсот видеодисков. Запас уже заказан у одного поставщика, однако, для будущих заказов директор
, намерен прибегать к услугам большего числа поставщиков. Все видеокассеты и диски ; снабжены штрих-кодом, так что сканер, интегрированный в систему, может поддержи- ■ вать операции выдачи напрокат и возврата видеофильмов. Членские карточки клиентов < также снабжены штрих-кодом.
Существующие клиенты имеют возможность резервировать видео таким образом, чтобы комплект видеофильмов был собран к определенной дате. Система должна обладать гибким поисковым механизмом для ответов на запросы клиентов, включая вопросы, ка- , сающиеся фильмов, которых нет в ассортименте магазина (но которые он может зака- ! ; зать по просьбе клиента).;
Управление контактами с клиентами
Управление контактами с клиентами — это “горячая” проблемная область. Больше известное под аббревиатурой CMS (Customer Management System — система управления работой с клиентами) управление контактами представляет собой важную составляющую ERP-систем (Enterprise Resource Planning — планирование ресурсов предприятия). ERP-системы автоматизируют так называемые конторские {back office) приложения обработки деловых операций. К трем наиболее типичным компонентам ERP-систем относятся: бухгалтере ий учет, производство и управление людскими ресурсами. CMS-системы принадлежат к компонентам управления людскими ресурсами.
ERP-система — очень масштабное настраиваемое решение. Некоторые специалисты называют их мега-пакетами. Вполне естественно, что CMS-компонета ERP- решения может быть очень сложной. В нашем примере мы касаемся только небольшой части проблемной области CMS.
Приложения по управлению контактами с клиентами отличаются весьма интересными решениями в отношении GUI-интерфейса, с помощью которого работники службы связей с клиентами (Customer Relations) или аналогичного подразделения могут планировать свою д ятельность, касающуюся клиентов. По существу GUI- интерфейс системы управления контактами работает как ежедневник по записи заданий и событий, связанных с клиентами, и позволяет следить за их ходом.
Подобный электронный ежедневник должен быть ориентирован на использование базы данных, позволяющей осуществлять динамическое планирование и отслеживать задания и события в отношении большого количества работников фирмы. Подобно большинству систем управления людскими ресурсами приложения по управлению контактами с клиентами требуют изощренной схемы авторизации для управления доступом к закрытой информации.
1-. ^ .-e-o^ssa^ss^ «®№'Ш®аз^зу^^. . «^
i Компания, занимающаяся иследованием рынка, обладает стабильной клиентской базой , | организаций, которые приобретают отчеты по анализу рынка. Некоторые крупные кли- i 1 енты приобретают у компании также специализированное ПО, предназначенное для , I создания отчетов. Этих клиентов компания также обеспечивает необработанной и агре! гированной информацией для генерации их собственных отчетов.
j Компания постоянно ищет новых клиентов, даже если новые клиенты заинтересованы 1 j только в получении однократных, узкоспециализированных отчетов по рынку. Хотя пер- i спективные клиенты — это в полном смысле еще клиенты, компания стремится устано- ; вить с ними контакт — отсюда, система управления контактами с клиентами (контакты । бывают с перспективными, реальными и прошлыми клиентами).
I Новая система управления контактами должна разрабатываться своими силами и нахо- j диться в распоряжении всех работников компании, но с предоставлением различного
I уровня доступа. Сотрудники отдела обслуживания клиентов (Customer Services , ? Department) берут шефство над системой. Система должна обеспечить гибкое планиро- =; ; вание и перепланирование видов деятельности, связанных с контактами, так чтобы со; трудники могли успешно кооперировать свои усилия в завоевании новых клиентов и ; стимулировании существующих взаимоотношений с клиентами.
Телемаркетинг
Многие организации продают свои товары и услуги с использованием телемаркетинга. Телемаркетинг — это прямое обращение к потребителям с помощью телефона. Система телемаркетинга требует поддержки детально продуманного процесса планирования телефонных звонков, осуществляемых продавцами, оказания помощи в поддержании разговора и фиксирования результатов разговора.
Одной из характерных особенностей систем телемаркетинга является сильная зависимость от способности базы данных активно планировать и динамически перепланировать телефонные звонки при поддержке параллельных разговоров. Другим интересным аспектом таких систем является возможность автоматического набора запланированного телефонного номера.
( Благотворительное общество продает лотерейные билеты для пополнения своего бюд- | жета. Пополнение бюджета осуществляется в рамках кампании, направленной на под- • держку текущих важных благотворительных мероприятий. Общество хранит список бла- i готворителей (жертвователей). Для каждой новой кампании часть этих благотворителей заранее выбирается для обращения к ним с использованием телемаркетинга, а также,
; возможно, с помощью прямых обращений по почте.
i Чтобы завоевать новых приверженцев, общество использует некоторые новейшие схемы. ! Эти схемы включают специальные призовые кампании для вознаграждения благотворите- । лей, закупающих лотерейные билеты в массовом количестве, для привлечения новых i жертвователей и т.д. Общество не обращается к случайным потенциальным благотворите- I лям с использованием телефонных справочников или других подобных средств.
■ Для поддержки своей деятельности общество решило заключить контракт на разработ- t ку нового телемаркетингового приложения. От новой системы требуется поддерживать ’ около пятидесяти сотрудников службы телемаркетинга, работающих одновременно. ! Система должна давать возможность планировать телефонные звонки в соответствии с ' заранее заданными приоритетами и другими известными ограничениями.
i От системы требуется устанавливать соединения в соответствии с запланированными , телефонными звонками. В случае неудачных попыток соединения звонки должны быть ; перепланированы так, чтобы можно было попытаться дозвониться позже. Обратные > звонки от приверженцеа также должны упорядочиваться. Результаты разговора, вклю- ■ чая заказ лотерейных билетов и какие-либо изменения, касающиеся данных о благотво- < ригелях, должны сохраняться..
Резюме
В данной главе нам удалось охватить значительную часть вопросов, связанных с основаниями анализа требований. Были введены основополагающие термины и понятия, касающиеся объектной технологии. При изложении принципов объектного моделирования были использоааны многочисленные поясняющие примеры, включая детальное наставление. Для новичков задания, должно быть, показались пугающими или унылыми. Награда за настойчивость не заставит себя ждать — она придет в следующих главах.
Объектная система состоит из взаимодействующих обьектое-жземтиифое. Каждый объект обладает состоянием, поведением и идентичностью. Последнее понятие является, наверное, самым существенным для правильного понимания объектных систем;
в то же время его также труднее всего оценить людям, имеющим за плечами определенный опыт в отношении традиционных компьютерных приложений. Перемещение по связям представляет собой modus operandi объектной технологии — нечто, что воспитанному на технологии реляционных баз данных читателю в действительности трудно переварить.
Класс— это шаблон, по которому создаются объекты. Он определяет атрибуты, которые объект может содержать, и операуии, которые объект может вызывать. Атрибуты могут относиться к элементарному типу или обозначать другие классы. Атрибуты, которые обозначают другие классы, служат объявлением ассоуиауий. Ассоциации — это один из видов отношений между объектами. В качестве других типов отношений выступают агрегаудии обобщения.
Отношение обобщения обеспечивает основу для полиморфизма и наследования. Коммерческие программные среды могут поддерживать множественное наследование, но маловероятно, чтобы они поддерживали множественную или динамическую класси- фикауию. С наследованием связано понятие абстрактного класса. Класс может обладать атрибутами и операциями, которые применимы только к нему, но не применимы ни к одному из его объектов-экземпляров. Подобные атрибуты и операции требуют введения понятия объекта-класса.
Понятия объектной технологии были закреплены в наставлении, сконцентрированном на разработке приложения для Internet-магазина. В наставлении был введен полный набор методов моделирования языка UML — моделирование прецедентов, видов деятельности, классов, взаимодействий и моделирование состояний. Перечисленные методы представлены на относительно высоком уровне абстракции, при этом многие детали моделирования были опущены. В последующих главах эти детали будут уточнены.
Наконец, мы сформулировали постановки задач для четырех конкретных разбираемых примеров, которые должны использоваться позже (наряду с наставлением) для иллюстрации и объяснения более сложных методов моделирования анализа и проектирования. Разбираемые примеры относятся к таким областям, как запись на университетские курсы, магазин видеопроката, управление контактами с клиентами и телемаркетинг.
И Вопросы
в чем состоит необходимость различения объектов-экземпляров и объектов-классов?
Что такое идентификатор объекта?
В чем заключается различие между временными и постоянными объектами?
Что такое временная и постоянная связь? Каким образом они используются во время выполнения программы?
Что подразумевают, когда говорят, что тип атрибута обозначает класс? Приведите пример.
Вб. Хорошая объектная модель отличается тем, что большинство атрибутов в ней закрытых, а большинство операций — открытых. Почему?
В чем различие между понятиями видимости и области действия операции?
В какой ситуации при моделировании должен использоваться ассоциативный класс? Приведите пример.
В чем различие между композицией и агрегацией?
Объясните смысл замечания о том, что в типичной объектной среде программирования наследование применяется к классам, а не к объектам?
Какова связь между переопределением и полиморфизмом?
Что такое сигнатуре?
В чем различие между множественной классификацией и множественным наследованием?
В чем преимущества использования абстрактных классов для моделирования?
Объясните, в чем состоят основные отличительные черты и принципиальные отличия между моделью состояний, моделью поведения и моделью изменения состояний?
Может ли субъект обладать атрибутами и операциями? Объясните саой ответ.
Объясните, какова роль и место диаграммы видов деятельности в системном моделировании?
В чем различие между ветвлением по условию и разделением потоков управления на диаграммах видов деятельности? Приведите пример.
Что такое классы-сущности?
Что такое фактический аргумент и что такое формальный аргумент?
В чем состоит различие между действием и деятельностью на диаграмме состояний? Приведите пример.
Упражнения
У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 (Сконфигурированный компьютер). Можно ли связать их в ассоциацию. Если это возможно, модифицируйте соответствующим образом диаграмму. Объясните ваше решение.
У7. Internet-магазин — обратитесь к заданию 11 (разд. 2.2.4.S).
Рис. 2.31 представляет собой относительно простой пример, иллюстрирующий обобщение. Какие сложности.могут возникнуть, если потребуется ввести различия в информацию, вносимую в счет-фактуру для продажи стандартного компьютера (Standardcomputer) и продажи сконфигурированного компьютера (ConfiguredComputer)? Например, может быть предусмотрена дополнительная плата, зависящая от модификации, требуемой для конфигурируемой системы (ConfiguredComputer), и, напротив, может быть предусмотрена скидка за оптовую покупку стандартной системы (standardcomputer).
Модифицируйте диаграмму таким образом, чтобы отразить подобное усложнение. Кратко поясните свое решение.
У8. Internet-магазин — обратитесь (в качестве примера) к заданию 13 (разд. 2.2.5.1) и зада* 1 нию 6 (разд. 2.2.3.2).
Изобразите диаграмму последовательностей для вида деятельности Display Purchase Form (Отобразить закупочную форму) (рис. 2.26).
У9. Internet-магазин — обратитесь к решению упражнения 8, приведенного выше.
Введите дополнительные операции в классы, обозначенные объектами в диаграмме последовательностей.
У10. Internet-магазин — обратитесь к заданию 16 (разд. 2.2.6.1).
Диаграмма состояний, показанная на рис. 2.37, удовлетворяет ограничению, е соответствии с которым допускается только один частичный платеж. Предположим, что это не так, и разрешается осуществлять большее количество частичных платежей. Модифицируйте соответствующим образом указанную диаграмму.
Установление
требований
В сравнении с другими этапами разработки системы установление требований в наименьшей степени касается технических сторон проекта. В действительности речь идет об успешном решении социальных, коммуникативных и управленческих вопросов. Недостаточно тщательное выполнение этого этапа может привести к более серьезным последствиям, чем в случае с другими этапами. Лавинообразный рост расходов, вызванных не зафиксированными, упущенными или неверно понятыми требованиями заказчиков, может впоследствии оказаться просто невыносимым для процесса разработки.
Эта глава охватывает широкий спектр вопросов, касающихся установления требований. Первая часть главы посвящена методам выявления, согласования и утверждения требований, а также принципам управления требованиями. Остаток первой части касается вопросов прослеживаемости и управления изменениями — темы, которая более подробно обсуждается в главе 10.
Во второй части главы вводятся базовые графические методы моделирования для описания бизнес-модели, относящейся к организации и прикладной области. Кроме того, здесь рассматривается структура документа, описывающего требования.
Принципы установления требований
Установление требований —первый этап жизненного цикла разработки системы. Система, подлежащая разработке, определяется с помощью вида деятельности, который получил название системного планирования (разд.1.2). Цель установления требований состоит в том, чтобы дать развернутое определение функциональных — а также нефункциональных — требований, которые участники проекта ожидают утвердить в реализуемой и разворачиваемой системе.
Требования определяют услуги, ожидаемые от системы (формулировки сервисов) и ограничения, которым система должна подчиняться (формулировки ограничений). Эти формулировки сервисов можно объединить в несколько групп: одна из групп описывает границы системы, вторая — необходимые бизнес-функции (функционалън'ые требования), а третья — требуемые структуры данных (требования к данным). Формулировки
ограничений можно классифицировать в соответствии с различными категориями ограничений, накладываемых на систему, такие как требуемое "впечатление и ощущение от использования программы”, производительность, безопасность и т.д.
Требования необходимо получить от заказчиков (пользователей и владельцев системы). Этот вид деятельности, называемый выявлением требований (requirements elicitation), осуществляется аналитиком бизнес-процессов (или системным аналитиком). Для этого подходят различные методы, начиная с традиционных интервью с заказчиком и заканчивая (при необходимости) построением программного прототипа, с помощью которого раскрываются дополнительные требования.
Собранные требования должны быть подвергнуты тщательному анализу для выявления в них повторов и противоречий. Это неизменно приводит к пересмотру требований и их повторному согласования) с заказчиками.
Требования, удовлетворительные с точки зрения заказчика, документируются. При этом требованиям дают определение, классифицируют, нумеруют и присваивают им приоритеты. Структура документа, описывающего требования, соответствует шаб лону (template), выбранному в организации для этой цели.
Хотя документ, фиксирующий требования, носит в значительной мере описательный характер, вполне возможно включить в него высокоуровневую схематичную бизнес-модель. Как правило, бизнес-модель состоит из модели границ системы, модели бизнес-прецедентов и модели бизнеслслассов.
Требования пользователя подобны движущейся цели. Чтобы справиться с изменчивыми требованиями, необходимо уметь управлять изменениями. Управление требованиями включает такие виды деятельности как оценка влияния изменений одних требований на другие, а также на неизменяемую часть системы.
Выявление требований
Бизнес-аналитик выявляет требования к системе посредством консультаций. К участию в консультациях привлекаются заказчики и эксперты в проблемной области. В некоторых случаях бизнес-аналитик обладает достаточным опытом в проблемной области, и помощь эксперта может не потребоваться. В этом случае Бизнес- аналитик представляет собой разновидность Эксперта проблемной области, что отражено в модели, показанной на рис. 3.1, с помощью отношения обобщения. (Следует, однако, иметь ввиду, что рис. 3.1 — это не модель прецедентов: нотация для прецедентов используется здесь только для удобства.)
Требования, выявленные с помощью эксперта проблемной области, составляют основу знаний о проблемой области. Они фиксируют широко признанные, не зависящие от времени бизнес-правила, применимые к большинству организаций и систем. Требования, выявленные в ходе консультаций с заказчиками, выражаются в сценариях прецедентов. Они выходят за рамки базовых знаний о проблемной области и фиксируют уникальные черты организации — способ ведения бизнеса “здесь и сейчас” либо пожелания в отношении того, как следует вести бизнес.
Задача бизнес-аналитика состоит в том, чтобы объединить два набора требований в бизнес-модели. Как показано на рис. 3.1, Бизнес-модель содержит Модель биз- нес-классов и Модель бизнес-прецедентов. Модель бизнес-классов представляет собой диаграмму классов верхнего уровня, которая идентифицирует и связывает между собой бизнес-объекты. Модель бизнес-прецедентов — это диаграмма прецедентов верхнего уровня, которая идентифицирует основные функциональные строительные блоки системы.
Рис. 3.1. Взаимные влияния моделей, характерные для процесса определения требований
В общем случае, классы проблемной области (бизнес-объекты) не должны выводиться из прецедентов [75]. Однако, на практике правильность модели бизнес- классов должна подтверждаться посредством сравнения с Моделью бизнес- прецедентов. Это сравнение, как правило, приводит к некоторой настройке или расширению Модели бизнес-классов.
Следуя Хофферу (Hoffer) [87] мы различаем традиционные и современные методы выявления фактов и сбора информации.
Традиционные методы выявления требований
К традиционным методам выявления требований относятся использование интервью и анкет, наблюдение и изучение деловых документов. Это простые и экономичные методы.
Эффективность традиционных методов обратно пропорциональна риску проекта. Высокий риск означает, что систему трудно реализовать — не вполне ясны даже обобщенные требования. Для таких проектов традиционных методов вряд ли будет достаточно.
Интервьюирование заказчиков и экспертов в проблемной области
Использование интервью представляет собой основной метод выявления фактов и сбора информации. Большинство интервью проводятся с заказчиками. Интервью с заказчиками позволяют выявить по большей части “прецедентные” требования, т.е. требования вытекающие из "прецедентов” (рис. 8.1). Если бизнес-аналитик не облада-
ет достаточным опытом в проблемной области, можно также проинтервьюировать соответствующих экспертов.
Интервью с экспертами в прикладной области зачастую представляет собой просто процесс передачи знаний — занятие по обучению бизнес-аналитика. Интервью с заказчиками отличает большая сложность [46], [81].
Заказчики могут иметь весьма смутное представление о своих требованиях. Они могут не желать сотрудничать или не умеют выражать свои требования в понятной форме. Они также могут запрашивать реализацию требований, которые превосходят бюджет проекта или нереализуемы. И наконец, весьма вероятно, что требования, исходящие от различных групп пользователей, могут оказаться противоречивыми.
Существуют два основных типа интервью: структурированное (формальное) и неструктурированное (неформальное). Структурированное интервью готовится заранее, отличается ясностью постановки вопросов, а многие вопросы могут быть заданы заранее. Заранее сформулированные вопросы можно разделить на две категории: вопросы, с открытым множеством ответов (open-ended question) (ответы на эту категорию вопросов заранее не готовятся) и вопросы с замкнутым множеством ответов (closed-ended question) (ответы на эту категорию вопросов можно выбрать из списка подготовленных ответов).
Структурированному интервью должно сопутствовать неструктурированное интервью. Неструктурированное интервью больше напоминает неформальную встречу, которой не свойственны заготовленные впрок вопросы или заранее поставленные цели. Цель неструктурированного интервью — подвигнуть заказчика к тому, чтобы он поделился своими мыслями и в процессе беседы подошел к требованиям, которых бизнес-аналитик мог и не ожидать и, следовательно, не мог задать нужные вопросы.
Как структурированное, так и неструктурированное интервью нуждаются в некоторой отправной точке и контексте для обсуждения. Это может быть небольшой документ или записка, отправленная по электронной почте интервьюируемому перед встречей, цель которых — объяснить цели интервьюера или поставить некоторые вопросы.
■ Существуют три категории вопросов, которых, в общем случае, необходимо избегать [91].
■ Небеспристрастные вопросы, в которых интервьюер выражает (прямо или косвенно) свое мнение по вопросу (“Должны ли мы работать так, как мы работаем?”).
■ Предвзятые вопросы, аналогичные небеспристрастным, но отличаются от последних тем, что мнение интервьюера является, очевидно, тенденциозным (“Вы ведь не станете этого делать, не так ли?”).
■ Наводящие вопросы, которые предполагают ответ в самом вопросе (“Вы ведь сделаете именно так, не правда ли?”).
■ ■ Успех интервью зависит от многих факторов, но едва ли не главными среди них являются навыки интервьюера в области коммуникации и межличностного общения. Хотя основная задача интервьюера — задавать вопросы и владеть ситуацией, не менее важ- ■ но в ходе беседы внимательно слушать и проявлять терпение к интервьюируемому так, чтобы он чувствовал себя непринужденно. Для сохранения хороших личных отношений и в расчете на положительный отклик со стороны интервьюируемого необходимо отправить ему в течение одного-двух дней после интервью записку, содержащую краткие итоги интервью.
Анкетирование
Использование анкет или анкетирование (questionnaires) — эффективный способ сбора информации от многих заказчиков. Обычно анкеты используются в дополнение к интервью, а не вместо них. Исключение могут составлять проекты с низким риском, цели которых ясно очерчены. Для таких проектов обычно достаточно использовать анкеты с вопросами, которые носят пассивный характер и не отличаются большой глубиной.
В общем случае, анкетирование менее продуктивно, чем использование интервью, поскольку в вопросы или возможные ответы нельзя внести дополнительную ясность. Анкетирование пассивно — это можно расценивать и как достоинство, и как недостаток. Это достоинство, поскольку у респондента есть время подумать над ответом, а анкета может остаться анонимной. Это недостаток, поскольку респонденту нелегко прояснить для себя вопросы.
Анкета (или вопросник) должна быть разработана таким образом, чтобы, по возможности, облегчить ответы на вопросы. В частности, следует избегать вопросов с неопределенным множеством ответов— большинство вопросов должны относиться к вопросам с замкнутым спискам ответов. Подобные вопросы могут принимать три формы [91].
Многоамтернативные вопросы (multiple-choice questions). При ответе на эти вопросы респондент должен указать один или более ответов, выбрав их из прилагаемого списка. Кроме того, иногда допускаются дополнительные комментарии к вопросам со стороны респондентов.
Рейтинговые вопросы (rating questions). При ответе на этот тип вопросов респондент должен выразить свое мнение в отношении высказанного утверждения. Для этого могут использоваться такие рейтинговые значения, как “абсолютно согласен”, “согласен”, “отношусь нейтрально", “не согласен", “абсолютно не согласен” и “не знаю”.
Вопросы с ранжированием (ranking questions). Этот тип вопросов предусматривает ранжирование ответов с помощью присваивания им последовательных номеров, процентных значений и использования других средств упорядочения.
Тщательно продуманная, облегчающая ответы анкета поощряет респондента к тому, чтобы сразу вернуть заполненный документ. Однако, при оценке результатов анкетирования бизнес-аналитик должен предусмотреть возможность искажения информации из-за того, что те люди, которые не отвечали на вопросы, могли бы ответить на них иначе, чет принимавшие участие в опросе [87].
Наблюдение
В некоторых ситуациях бизнес-аналитик находит трудным получить полную информацию с использованием интервью и анкет. У заказчика по тем или иным причинам может отсутствовать возможность (или умение) предоставить необходимую информацию, либо он может не иметь полного представления о бизнес-процессе в целом. В подобных случаях в качестве эффективного метода выявления фактов может выступать наблюдение (observation). Как-никак, лучший способ научиться завязывать галстук — понаблюдать за процессом.
Наблюдение может выступать в двух формах.
Пассивное наблюдение (passive observation), в ходе которого бизнес-аналитик наблюдает за различными видами деловой деятельности без вмешательства или
прямого участия в них. В некоторых случаях для того, чтобы наблюдение было как можно менее навязчивым, можно даже использовать видеокамеры.
Активное наблюдение (active observation'), в ходе которого бизнес-аналитик участвует в деятельности и становится фактически частью команды.
Чтобы результаты наблюдений были представительными, наблюдения необходимо проводить в течение продолжительного периода времени, в разные временные интервалы и при разной рабочей нагрузке (выборочные периоды). Основная трудность, связанная с наблюдением, состоит в том, что люди, за которыми наблюдают, склонны вести себя иначе, чем в обычной обстановке. В частности, они стремятся работать в соответствии с формальными правилами и процедурами. Это приводит к искажению реального положения дел за счет утаивания “рациональных” приемов работы — как положительных, так и отрицательных. Следует помнить, что “работа по правилам” — это одна из эффективных форм забастовочного движения.
Изучение документов и программных систем
Изучение документов и программных систем является неоценимым методом выявления как требований типа прецедентов, так и требований, связанных со знанием проблемной области (см. разд. 3.2). Этот метод используется всегда, хотя он может касаться только отдельных сторон системы.
Требования, формулируемые в виде прецедентов, или прецедентные требования (use case requirements') выявляются посредством изучения существующих организационных документов и системных форм и отчетов (если, конечно, для текущей системы существует автоматизированное решение, что типично для больших организаций). Одним из наиболее полезных способов постижения сути требований на основе прецедентов является фиксация дефектов (естественно, при их наличии) и формирование запросов на изменение для существующей системы.
К организационным документам, подлежащим изучению, относятся: формы деловых документов (по возможности — заполненные), описания рабочих процедур, должностные обязанности, методические руководства, бизнес-планы, схемы организационных структур, внутриофисная корреспонденция, протоколы совещаний, учетные записи, внешняя корреспонденция, жалобы клиентов и т.д.
Системные формы и отчеты, подлежащие изучению, включают: копии экранов, отчеты вместе с соответствующей документацией — системные руководства по эксплуатации, пользовательская документация, техническая документация, системные модели анализа и проектирования и т.д.
Требования, основанные на знании проблемной области, выясняются посредством изучения журналов и учебников, которые относятся к данной сфере. Изучение патентованных программных пакетов наподобие ERP-систем (Enterprise Resource Planning Systems — системы планирования ресурсов предприятия) также может стать богатым источником знаний о проблемной области. Следовательно, посещения библиотек и поставщиков ПО являются частью процесса выявления требований (конечно, Internet позволяет осуществить многие такие “визиты”, не покидая офиса).
Современные методы выявления требований
К современным методам выявления требований относится использование программных прототипов, а также такие методы, как JAD (Joint Application Development — совместная разработка приложений) и RAD (Rapid Application Development —
быстрая разработка приложений). Эти подходы предлагают более глубокое проникновение в суть требований, но за счет большей цены и усилий. Однако, долговременные вложения в эти методы могут окупиться с лихвой.
Применение современных методов обычно связано с высоким проектным риском. Существует множество факторов, обусловливающих высокий риск проекта. К таким факторам относятся неясные цели, недокументированные процедуры, нестабильные требования, слабое знание дела пользователями, неопытные разработчики, недостаточная приверженность пользователей разработке и т.д.
Прототипирование
Прототипирование (prototyping)— это наиболее часто используемый современный метод выявления требований. Программные прототипы конструируются для визуализации системы или ее части для заказчиков с целью получения их отзывов.
Прототип представляет собой демонстрационную систему— “наскоро и грубо” сделанную рабочую модель решения, которая представляет пользовательский GUI- интерфейс и моделирует поведение системы при инициировании пользователем различных событий. Информационное наполнение экранов чаще жестко запрограммировано в программе прототипа, чем получается автоматически из базы данных.
Сложность (и растущие “аппетиты" заказчиков) современных GUI-интерфейсов делают прототипирование обязательным элементом разработки ПО. Прототипы позволяют довольно неплохо оценить реализуемость и полезность системы до начала ее реализации.
В общем случае, прототип — это весьма эффективный способ выявления требований, которые трудно получить от заказчика с помощью других средств. Чаще всего такая ситуация встречается для систем, которые должны предоставить в распоряжение пользователей новые бизнес-функции. Подобная ситуация также характерна для случаев противоречивых требований и наличия проблем в кооперации между заказчиками и разработчиками.
Существуют две основные разновидности прототипов [46].
“Одноразовый"прототип (“throw-away" prototype), который после того, как выявление требований завершено, просто отбрасывается. Разработка “одноразового” прототипа нацелена только на этап установления требований ЖЦ ПО. Как правило, этот прототип концентрируется на наименее понятных требованиях.
Эволюционный прототип (evolutionary prototype), который сохраняется после выявления требований и используется для создания конечного программного продукта. Эволюционный прототип нацелен на ускорение поставки продукта. Как правило, он концентрируется на ясно изложенных требованиях, так что первую версию продукта можно предоставить заказчику довольно быстро (хотя ее функциональные возможности, как правило, неполны).
Дополнительным доводом в пользу использования именно “одноразового” прототипа может служить стремление избежать риска “консервации" скорых и грубых и, как следствие, неэффективных решений в конечном продукте. Однако мощь и гибкость современных средств создания ПО ослабляют этот довод. Если управление проектом осуществляется надлежащим образом, то причины, по которой нельзя было бы избавиться от неэффективных предложенных для прототипа решений, не существует.
,Совместная разработка приложений (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].
Быстрая разработка приложений (RAD-метод)
Метод быстрой разработки приложений (Rapid Application Development — RAD) — это нечто большее, чем метод выявления требований — это целостный подход к разработке ПО [37]. Как ясно из названия метода, он предполагает быструю поставку системных решений. Техническое превосходство отступает на второе место в сравнении со ско
ростью поставки.
Согласно Вуду (Wood) и Сильверу (Silver) [95] технология RAD сочетает в себе пять методов, перечисленных ниже.
Эволн^ионное прототипирование (разд. 3.2.2.1).
CASE-cpedcmea с возможностями генерации программ и циклической разработкой с переходом от проектных моделей к программе и обратно.
Специалисты, влхйекпцие развитыми инструментальными средствами (Specialists unth Advanced Tools — SWAT) — RAD-бригада разработчиков. Лучшие аналитики, проектировщики и программисты, которых только может привлечь организация. Бригада работает в рамках строгого временного режима и размещается вместе с пользователями.-
ИнтерактивныйJAD-метод—JAD-сессия (разд. 3.2.2.2), во время которой секретарь заменяется бригадой SWAT, оснащенной CASE-средствами.
Жесткие временные рамки (timeboxing) — метод управления проектом, который отводит бригаде SWAT фиксированный период времени (timebox) для завершения проекта. Этот метод препятствует “расползанию рамок проекта”; если проект затягивается, то рамки решения сужаются, чтобы дать возможность завершить проект своевременно.
Использование RAD-подхода может оказаться привлекательным вариантом для многих проектов, в особенности, для небольших проектов, которые не затрагивают сферу ключевых бизнес-процессов организации, и которые, таким образом, не задают план решения для других проектов по разработке ПО. Маловероятно, чтобы быстрые решения были оптимальными или долговременными для ключевых сфер деятельности организации. С использованием RAD-метода связан ряд проблем; некоторые из них перечислены ниже.
Несовместимый проект GUI-интерфейса.
Вместо общих решений, способствующих многократному использованию ПО, специализированные решения.
Неполная документация.
Трудное для поддержки и масштабирования ПО и т.д.
Согласование и проверка обоснованности требований
Требования, полученные от пользователей, могут дублироваться или противоречить друг другу. Некоторые требования могут быть неясными или нереальными Другие требования могут остаться невыясненными. По этой причине прежде, чем требования попадут в документ описания требований, их необходимо согласовать.
В действительности согласование и проверка обоснов мости требований осуществляется параллельно с выявлением требований. После того как требования выявлены, они подвергаются определенному уровню проверки. Для всех современных методов выявления требований, которые связаны с так называемой “групповой динамикой", это вполне естественно. Как бы там ни было, после того как выявленные требования соб-
раны вместе, они в любом случае должны быть подвергнуты тщательному обсуждению и проверке.
Согласование и проверка требований не могут быть отделены от процесса подготовки документа описания требований. Обычно согласование требований основано на черновом варианте документа. Требования, перечисленные в черновом варианте документа, обсуждаются и при необходимости модифицируются. Побочные требования удаляются. Вновь выявленные требования добавляются.
Для проверки обоснованности требований (requirements validation) необходима более полная версия документа, в котором все требования четко идентифицированы и классифицированы. Участники проекта изучают документ и проводят совещания по их формальному пересмотру. Пересмотры (reviews) часто структурированы в виде так называемых процедур сквозного контроля (walkthroughs) или инспекций (inspections). Пересмотры являются разновидностью тестирования (testing) (разд. 10.1.1).
Требования, выходящие за рамки проекта
Выбор проекта в сфере ИТ и, следовательно, подлежащей реализации системы (и их четких границ) определяется в рамках вида деятельности, получившего название системного планирования (разд. 1.2). Однако, детализированные взаимозависимости между системами могут быть раскрыты только на этапе анализа требований. Установление границ системы (системных рамок) — задача этапа анализа требований, так что проблема “растягивания рамок" может решаться на ранних этапах процесса разработки как составная часть этой задачи.
Чтобы иметь возможность решить, лежит ли конкретное требование в рамках системы или выходит за рамки, необходима эталонная модель, по отношению к которой и должно приниматься решение. Исторически роль подобной эталонной модели сыграла контекстная диаграмма (context diagram) — высокоуровневая диаграмма популярного метода структурного моделирования под названием диаграмма потоков данных (Data Flow Diagrams — DFD). Хотя в языке UML место этой диаграммы заняла диаграмма прецедентов, контекстная диаграмма по-прежнему остается превосходным методом установления границ системы (разд. 3.5.1).
Существуют, впрочем, и другие причины, по которым требование может быть расценено, как выходящее за рамки проекта [81]. Например, требование может представлять большую трудность для реализации в компьютеризованной системе и остается прерогативой человека, участвующего в процессе. Либо требование может иметь низкий приоритет и исключается из первой версии системы. Требование может быть также реализовано с помощью аппаратного обеспечения или внешних устройств и, таким образом, может оказаться вне контроля со стороны программного обеспечения.
Матрица зависимости требований
Полагая, что все требования четко идентифицированы и пронумерованы (разд. 3.4.1), можно сконструировать матрицу зависимостей требований (requirements dependency matrix) (или матрицу взаимодействия (interaction matrix требований)) [81], [46]. В столбце и строке заголовка перечислены упорядоченные идентификаторы требований, как показано на рис. 3.2.
Требование
Т1
Т2
ТЗ
Т4
Т1
X
X
X
X
Т2
Конфликт
X
X
X
ТЗ
X
X
Т4
Перекрытие
Перекрытие
X
Рис. 3.2. Матрица зависимости требований
Верхняя правая часть матрицы (над диагональю включительно) не используется. Оставшиеся ячейки указывают на то, перекрываются ли два любых требования, противоречат друг другу или независимы друг от друга (пустые ячейки). Противоречивые требования необходимо обсудить с заказчиками и при возможности переформулировать для смягчения противоречий (фиксацию противоречия, видимую для последующей разработки, необходимо сохранить). Перекрывающиеся требования также должны быть сформулированы заново, чтобы исключить совпадения.
Матрица зависимости требований представляет собой простой, но эффективный метод обнаружения противоречий перекрытий, когда количество требований относительно невелико. В противном случае описанный метод все же можно применить, если удается сгруппировать требования по категориям (разд. 3.4.1), а затем сравнить их отдельно в пределах каждой категории.
Риски и приоритеты требований
После того, как в результате снятия противоречий и устранения повторов в требованиях выработан пересмотренный набор требований, их необходимо подвергнуть анализу рисков и назначить им приоритеты. Анализ рисков (risk analysis') направлен на идентификацию требований, которые являются потенциальными источниками трудностей в разработке. Назначение приоритетов (prioritization} необходимо для того, чтобы обеспечить возможность без труда изменить рамки проекта в случае возникновения непредвиденных задержек.
Требования могут быть “рискованными” вследствие влияния различных факторов. Требованиям свойственны следующие типичные виды рисков [81].
Технический риск, когда требование технически трудно реализовать.
Риск, связанный со снижением производительности, когда требование — будучи реализовано — может неблагоприятно сказаться на времени реакции системы.
Риск, связанный с нарушением безопасности, когда требование — будучи реализовано — может создать бреши в защите системы.
Риск, связанный с процессом разработки, когда для реализации требования необходимо использование необычных методов разработки, незнакомых разработчикам (например, методов формальной спецификации).
Риск, связанный с нарушением целостности баз данных, когда требование не может быть легко проверено и может привести к противоречивости данных.
Политический риск, когда требование может оказаться трудным выполнить по внутриполитическим причинам.
Риск, связанный с нарушением законности, когда требование может привести к нарушению действующих законов или ожидаемого изменения закона.
Риск, связанный с изменчивостью, когда требование может потенциально изменяться или эволюционировать в течение процесса разработки.
В идеале приоритеты требованиям назначают отдельные заказчики в процессе выявления требований. Затем они согласовываются на совещаниях и снова изменяются после приложения к ним факторов риска.
Для исключения неопределенности и облегчения назначения приоритетов количество групп приоритетов не должно быть слишком велико. Обычно используется от трех до пяти приоритетов. Их можно обозначить как “высокий”, “средний”, “низкий” и "неопределенный”. Альтернативный перечень приоритетов может выглядеть, например, так: "существенное", "полезное", “трудно определимое" и "отложенное".
Управление требованиями
Требованиями необходимо управлять. Управление требованиями в действительности представляет собой часть общего управления проектом. Оно связано с тремя основными вопросами.
Идентификация, классификация, организация и документирование требований.
Изменение требований (с помощью процессов, которые устанавливают способы выдвижения, согласования, проверки достоверности и документирования неизбежных изменений к требованиям).
Прослеживаемость требований (с помощью процессов, которые поддерживают отношения взаимозависимости между требованиями и другими системными артефактами, а также, собственно, между требованиями) (обратитесь к главе 10).
Идентификация и классификация требований
Требования описываются на естественном языке, например, следующим образом.
“Система должна запланировать следующий телефонный звонок клиенту по запросу телемаркетера”.
“Система должна автоматически набирать запланированный телефонный номер и одновременно отображать на экране телемаркетера информацию, включающую телефонный номер, номер клиента, имя клиента”.
“В случае успешного соединения система должна отобразить вводный текст, с которым телемаркетер может обратиться к клиенту для того, чтобы завязать разговор”.
Типичная система может состоять из сотен или тысяч формулировок требований, наподобие тех, что приведены выше. Для надлежащего управления таким огромным количеством требований их необходимо пронумеровать с помощью некоторой схемы идентификалуш (identijicatian scheme') Схема может включать классификачусю требований в виде групп, которые легче поддаются управлению.
Существует несколько методов идентификации и классификации требований [46].
Уникальный идентификатор— обычно последовательный номер, присвоенный вручную или сгенерированный с использованием базы данных CASE-средства (т.е. базы данных (или репозитория), в которой CASE-средства хранят артефакты, выработанные в результате анализа или проектирования).
Последовательный номер внутри иерархии документа— присваивается с учетом положения требований в пределах документа описания требований (например, седьмое требование в третьем разделе второй главы может быть пронумеровано как 2.3.7).
Последовательный номер в пределах категории требований— присваивается в дополнение к мнемоническому имени, которое обозначает категорию требований (где под категорией требований подразумевают функциональное требование, требование К данным, требования к производительности, требования к безопасности и т.д.)
Каждый из методов идентификации обладает своими за и против. Наибольшей гибкостью и защищенностью от ошибок отличаются уникальные идентификаторы, го шрируемые с помощью базы данных. Базы данных обладают встроенными возможностя-. ми генерации уникальных идентификаторов для каждой новой записи данных в условиях одновременного доступа к данным со стороны многих пользователей.<
Некоторые базы способны дополнительно поддерживать сопровождение ‘ нескольких версий одной и той же записи (за счет расширения значения уникального идентификатора с помощью номера версии). Наконец, базы данных могут обладать возможностями поддержки ссылочной целостности связей между артефактами моделирования, включая требования, и могут, таким образом, обеспечить необходимую поддержку управления и прослеживаемости требований.
Иерархии требований
Требования можно упорядочить в виде иерархически упорядоченной структуры, представляющей отношение родитель-потомок. Отношение родитель-потомок подобно отношению композичии (разд. 2.1.4). Родительское требование составлено из дочерних требований. Дочернее требование — это фактически “под-требование” родительского требования.
Иерархические отношения позволяют ввести дополнительный уровень классификации требований. Это может непосредственно отражаться (или не отражаться) в идентификационном номере (с помощью использования точки в записи составного имени). Поэтому требование, пронумерованное как 4.9, может быть девятым “потомком" “родителя" с идентификационным номером, равным 4.
Приведенный ниже набор формулировок представляет собой иерархически упорядоченные требования.
“Система должна запланировать следующий телефонный звонок клиенту по запросу телемаркетера”.
“Система должна активизировать клавишу Next Call (Следующий звонок) при открытии формы Telemarketing Control (Управление телемаркетингом) или при завершении предыдущего вызова”.
“Система должна удалить звонок из начала очереди запланированных звонков и придать ему статус текущего звонка”.
Другие требования...
Иерархии требований позволяют определять требования на различных уровнях об стракции. Это согласуется с общим принципом моделирования, в соответствии с которым при переходе к более низкому уровню абстракции модели систематически обогащаются все новыми деталями. В результате для родительских требований можно сконструировать обобщенные требования, а детализированные модели можно связать с дочерними требованиями.
Управление изменениями
Требования изменяются. Требования могут изменяться, они могут быть удалены, а новые требования могут быть добавлены на любом этапе разработки. Изменения нельзя рассматривать как “удар”, а вот неуправляемые изменения — это настоящий удар по проекту.
Чем дальше продвинулась разработка, тем дороже обходится внесение изменений. Фактически, минимальные затраты, необходимые для выправления проекта после внесения изменений, всегда растут и зачастую растут экспоненциально. Изменение только что сформулированных требований, которые не связаны с другими требованиями, — это простое упражнение в редактировании. Изменение тех же требований, после того как они реализованы, может обойтись чрезвычайно дорого.
Изменения могут быть связаны с субъективными ошибками, но зачастую они вызваны изменениями внутренней политики или внешними факторами, такими как конкурентные силы, глобальные рынки или технологические достижения. Вне зависимости от причин, для документирования запросов на изменения {change request) оценки влияния, оказываемого изменениями {change impact), и осуществления изменений необходима сильная стратегия управления изменениями.
Поскольку изменение требований обходится дорого, для каждого запроса на изменение необходимо создавать формальный бизнес-прецедент. Обоснованное изменение, которое не встречалось раньше, оценивается с точки зрения его технической осуществимости, влияния на остальной проект и затрат. После согласования требование включается в соответствующие модели и реализуется в программном обеспечении.
Управление изменениями, помимо прочего, включает отслеживание больших объемов взаимосвязанной информации в течение длительного периода времени. Без инструментов поддержки управление изменениями обречено. В идеале, изменения требований должны храниться и отслеживаться с помощью средств конфигурационного управления ПО, которое используется разработчиками для контроля версий моделей и программ на протяжении ЖЦ разработки. Подходящие CASE-средства должны либо обладать собственными возможностями конфигурационного управления, либо возможностями взаимодействия с автономными средствами конфигурационного управления.
Прослеживаемость требований
Прослеживаемость требований {requirements traceability) — это всего лишь часть, хотя и крайне важная часть, управления изменениями {change management). Блок прослеживаемости требований технологии управления изменениями поддерживает отношения прослеживаемости, чтобы фиксировать изменения, искодягцие от или вносимые в требования на протяжении ЖЦ разработки.
Рассмотрим требование: “Система должна запланировать следующий телефонный звонок клиенту по запросу телемаркетера”. Это требование можно впоследствии смоделировать с помощью диаграммы последовательностей, которая активизируется из GUI-интерфейса с помощью кнопки запуска действия, помеченной как Next Call, и триггера, запрограммированного в базе данных. Если между всеми этими элементами существует отношение прослеживаемости, изменение любого элемента вновь открывает отношение для обсуждения — траектория системы “подпадает под подозрение" (говоря языком одного из инструментальных средств).
Отношение прослеживаемости может охватывать многие модели последовательных этапов ЖЦ. Непосредственной модификации подлежат только смежные связи по прослеживаемости. Например, если элемент А восходит к элементу В, а элемент В
восходит к элементу С, изменение, внесенное в любой из конечных точек отношения, должно осуществляться в два этапа: сначала посредством модификации связи A-В, а затем В-С. (Более подробно прослеживаемость и управление требованиями рассматриваются в главе 10).
Бизнес-модель требований
На этапе установления требований осуществляется выявление требований и их определение, преимущественно, в виде формулировок на естественном языке. Формальное моделирование требований с использованием языка UML проводится позже на этапе спеуи<рикауии требований. Тем не менее, во время установления требований постоянно ведется деятельность по обобщенному визуальному представлению собранных требований, называемая бизнес-моделированием требований.
Для установления рамок системы требуется, по меньшей мере, высокоуровневая визуальная модель, позволяющая обозначить ключевые прецеденты и ввести наиболее существенные бизнес-классы. На рис. 3.3 показаны зависимости между этими тремя моделями этапа установления требований и модели остальных этапов ЖЦ разработки.
Ведущая роль диаграмм прецедентов в ЖЦ разработки нашла свое отражение на рис. 3.3, из которого ясно, что источником тестовых прецедентов, пользовательской документации и проектных планов выступают модели прецедентов. Более того, диаграммы прецедентов и модели классов используются параллельно и поочередно играют роль “лидера гонки” в рамках последовательных итераций разработки. Проектирование и реализация также тесно переплетены и могут инициировать обратную связь с моделями спецификации требований.
Рис. 3.3. Использование бизнеомоделей на различных этапах выработки требований
Модель рамок системы
Вследствие того, что требования подвержены постоянным изменениям, наверное, наибольшее беспокойство при разработке доставляет так называемое “расползание рама^ системы. Хотя некоторые изменения требований неизбежны, необходимо строго следить за тем, чтобы заявленные изменения не выходили за пределы принятых рамок проекта.
На самом деле, попытка ответить на вопрос: “Каким образом мы определяем рамки системы?” показывает, что ответ не лежит на поверхности. Это связано, в первую очередь, с тем, что любая система является всего лишь частью большей по своим масштабам среды — частью совокупности систем, которые вместе образуют эту среду. Системы взаимодействуют, обмениваясь информацией и обращаясь к услугам друг друга. Следовательно, поставленный выше вопрос можно переформулировать следующим образом: “Должны ли мы реализовать требования или же выполнение требуемых функций возлагается на другую систему?”.
Чтобы ответить на вопрос о рамках системы, необходимо знать, в каком контексте функционирует наша система. Необходимо знать, какие внешние сущности (external entities) — другие системы, организации, люди, машины и т.д.— рассчитывают на получение услуг от нас или готовы предоставить услуги нам. В бизнес-системах подобные услуги приобретают форму информации и представляются потоками данных (data jloui).
Поэтому рамки системы можно определить, обозначив внешние сущности и вход- ные/выходные потоки данных между внешними сущностями и нашей системой. Наша система получает входную информацию и выполняет ее необходимую обработку с целью выработки выходной информации. Всякое требование, которое не может быть поддержано за счет внутрисистемных возможностей обработки, выходит за рамки системы.
Язык UML не обладает средствами построения визуальной модели, позволяющей определить границы системы. Поэтому зачастую для решения этой задачи прибегают к помощи давно известных контекстных диаграмм потоков данных— DFD— (разд. 3.3.1). На рис. 3.4 показана контекстная диаграмма для приложения Телемаркетинг.
Пример моделирования рамок системы
Рассмотрите постановку задачи для приложения Телемаркетинг (раздел 2.3.4) и постройте '
для нее контекстную диаграмму. Кроме того, примите к сведению следующие замечания.
Камлании планируются на основе рекомендации доверенных лиц общества, которые решают, насколько являются своевременными и подобающими те или иные благотво- i ригельные мероприятия. Кампании должны быть согласованы с местными органами исполнительной власти. Разработка проекта и планирование кампании поддерживает- : ся отдельной прикладной системой campaign Database (База данных кампаний).
Существует также отдельная база данных Supporter Database (База данных благо- i творителей), предназначенная для хранения и ведения информации обо всех благо- : творителях — прошлых и настоящих. Эта база данных используется для отбора бла- , готворителей, с которыми необходимо установить контакт в ходе конкретной кампа- ' нии. Отобранный сегмент благотворителей передается для работы с ним во время кампании с использованием телемаркетинга.
Заявки от благотворителей на лотерейные билеты регистрируются во время сеансов телемаркетинга для их анвлиза системой обработки заказов (Order Processing). Система обработки заказов отслеживает состояние заявок в базе данных благотворителей.
Рис. ЗЛ. Модель рамок системы — контекстная диаграмма (Телемаркетинг)
Контекстная диаграмма, к которой вы, возможно, также пришли в результате работы над данным упражнением, показана на рис. 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.
Модель бизнес-прецедентов
Модели бизнес-прецедентов (business case model) [47] представляет собой модель прецедентов на верхнем уровне абстракции (разд. 2.2.2). Модель бизнес-прецедентов определяет обобщенные бизнес-процессы — бизнес-прецедемты. Бизнес-прецедент соответствует тому, что иногда называют возможностями системы (system feature). (Возможности системы определяются в документе, описывающем видение системы (system vision). Если при разработке системы представляется документ описания видения системы, он может использоваться взамен модели бизнес-прецедентов).
Диаграмма бизнес-прецедентов концентрируется на архитектуре бизнес- процессов. Эта диаграмма дает возможность взглянуть на предполагаемое поведение системы так сказать “с высоты птичьего полета”. Неформальное описание каждого из бизнес-прецедентов должно быть кратким, ориентированным на деловую сторону системы, и концентрироваться на основных потоках видов деятельности. Модель бизнес- прецедента не вполне подходит для того, чтобы объяснить разработчику, что же должна делать система.
На этапе спецификации требований бизнес-прецеденты превращаются в прецеденты. Именно на этом этапе определяются детальные прецеденты, и неформальное описание расширяется за счет включения в него подпроцессов и альтернативных процессов, некоторых копий экранов, демонстрирующих GUI-интерфейс, а также взаимосвязей между введенными прецедентами.
Субъекты (actor) диаграммы бизнес-прецедентов отличаются от внешних пщностей на диаграмме контекста. Различие заключается в способе взаимодействия субъектов с системой. Субъекты активны. Они управляют процессом. Они активизируют прецеденты, отправляя им сообщения о событиях. Прецеденты управляются событиями. Линии, связывающие субъектов и прецеденты, — это не потоки данных. Эти липни связи представляют поток событий, исходящих от субъектов и поток откликов, исходящих от прецедентов.
Субъекты обладают любопытной двойственной природой. По отношению к системе субъекты могут быть как внешними, так и внутренними сущностями. Опи являются внешними сущностями, поскольку они взаимодействуют с системой, оставаясь вне ее. В то же время они — внутренние сущности, поскольку система может поддерживать информацию о субъектах, так что она может “со знанием дела” взаимодействовать с “внутренними” субъектами. Системная спецификация — как модель системы — должна описывать систему и ее среду. Среда содержит субъекты. Система сама может хранить информацию о субъектах. Следовательно, спецификация заключает в себе две моде ли, связанные с субъектами, — модель субъекта и модель данных о субъектах, которые подлежат регистрации.
Пример моделирования бизнес-прецедентов
Пример 3.2. Телемаркетинг'
Рассмотрите постановку задачи для приложения Телемаркетинг (раздел 2.3.4 и 3.5.1.1) и постройте для нее диаграмму бизнес-прецедентов.
Один из возможных вариантов диаграммы бизнес-прецедентов показан на рис. 3.5.
Рис. 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 не обязательно. В общем случае все отношения между прецедентами можно опустить, чтобы избежать беспорядка и загромождения диаграммы. Как правило, прецеденты некоторым образом связаны с большинством остальных прецедентов, и включение в диаграмму всех отношений противоречит ее предназначению.
Модель бизнес-классов
Модель бизнес-классов (business class model) — это модель классов. Точно так же, как в случае модели бизнес-прецедентов, различие заключается в уровне абстракции. Модель
бизнес-классов определяет основные “бизнес-объекты” системы — структуры данных бизнес-процессов, которые составляют основу системы и определяют ее деятельность.
Модель бизнес-классов представляется на высоком уровне абстракции. На этом уровне нас меньше интересует содержание атрибутов классов— достаточно имен классов и их краткого описания.
Довольно любопытно отметить, что нередкой бывает ситуация, при которой субъекты модели бизнес-прецедентов представляются как классы в модели бизнес-классов. Это подтверждает нашу мысль о том, что субъекты зачастую выступают по отношению к системе как внешние и внутренние сущности (разд. 3.5.2).
Пример моделирования бизнес-классов
ffipHM^^i,Te^^ л.; ,
; Рассмотрите постановку задачи, диаграмму контекста и диаграмму бизнес! прецедентов для приложения Телемаркетинг (раздел 2.3.4, 3.5.1.1 и 3.5.2.1) и построй- I те для нее диаграмму бизнес-классов. Следующие соображения можно использовать ■ как подсказки.
' 1. Акцент в системе сделан на планирование звонков. Само по себе планирование
* звонков является вычислительной процедурой, т.е. здесь решение является строго I алгоритмическим по природе. Тем не менее, очереди запланированных звонков и ; результаты звонков должны запоминаться в некоторой структуре данных.
s 2. Как обсуждалось выше, может потребоваться хранить информацию о субъектах в классах.
Модель бизнес-классов в первом приближении показана на рис. 3.6. Диаграмма содержит шесть классов, два из которых (Supporter и Telemarketer) являются производными от субъектов модели бизнес-прецедентов. Алгоритм планирования звонков получает телефонный номер и другую информацию от класса Supporter и планирует звонок одному из имеющихся в наличии телемаркетеров (Telemarketer). Алгоритм в конечном счете долей быть реализован в базе данных системы в виде хранимой процедуры (storedprocedure) (разд. 9.1.2.1).
Рис. 3.6. Модель бизнес-классов (Телемаркетинг)
Класс Call Scheduled (Планируемый звонок) содержит текущую очередь звонков, включая звонки, которые в текущий момент являются активными. Результаты звонков регистрируются в классе CallOutcome (Результат звонка), а также распространяются в другие задействованные классы, такие как CampaignTicket (Билет кампании) и Supporter.
Класс Campaign содержит класс CampaignTickets и связан с классом Scheduled отношением "один ко многим”. Аналогично, объекты классов Supporter и Telemarketer могут обладать многими объектами класса CallScheduled. Ассоциация между классами CallScheduled и CallOutcome имеет кратность “один к одному”.
Документ описания требований
Документ, описывающий требования, является осязаемым результатом этапа установления требований. Большинство организаций вырабатывают документ описания требований в соответствии с заранее определенным шаблоном. Шаблон определяет структуру (содержание) и стиль документа.
Ядро документа описания требований состоит из формулировок (изложения) требований. В разделе 3.1 указывалось, что требования могут быть сгруппированы в виде формулировок сервисов (зачастую называемых функциональными требованиями) и формулировок ограничений. Формулировки сути сервисов могут быть затем разделены на требования к функциям (function requirements') и требования к данным (data requirements). (В литературе термин “ функционалкные требования” (functional requirements) в широком и в узком смысле используется как взаимозаменяемый. При использовании в узком смысле он соответствует тому, что мы называем требованиями к функциям).
Не говоря уже о самих требованиях, документ описания требований должен обращаться к проектным вопросам. Обычно проектные вопросы рассматриваются в начале документа, а затем в конце документа. Во вводной части документа рассматривается бизнес-контекст проекта, включая цель проекта, участников проекта и основные ограничения. Ближе к заключительной части документа поднимаются другие проектные вопросы, включая план-график выполнения проектных работ, бюджет, риски, документацию и т.д.
Шаблоны документа
Шаблоны для документов описания требований широко доступны. Их можно найти в учебниках, стандартах, выпускаемых такими организациями как ISO, IEEE и т.д., на Web-страницах консалтинговых фирм, программных средствах разработки и т.д. Со временем каждая организация разрабатывает свои собственные стандарты, которые соответствуют принятой в организации практике, корпоративной культуре, кругу читателей, типам разрабатываемых систем и т.д.
Шаблон документа описания требований определяет структуру документа и содержит подробные указания о содержании каждого из разделов документа. Указания могут включать содержание вопросов, мотивацию, примеры и дополнительные соображения [71].
На рис. 3.7 показано типичное оглавление документа описания требований. Последующие разделы включают объяснение к приведенному оглавлению.
Предварительные замечания к проекту
Часть документа описания требований, содержащая предварительные замечания к проекту, преимущественно дает ориентиры тем руководителям и участникам проекта, ответственным за принятие решений, которые, вероятно, не станут подробно изучать документ целиком. В начале документа необходимо ясно обозначить цели и рамки проекта, а затем описать деловой контекст системы.
Документ описания требований должен создать прецедент для системы. В частности, необходимо упомянуть обо всех усилиях, приложенных для обоснования необходимости системы на этапе планирования системы (разд. 1.2). Документ описания требований должен прояснить вопрос о том, каким образом предлагаемая система может способствовать достижению деловых целей и решению задач организацией.
Необходимо обозначить участников проекта (разд. 1.1.2) системы. Важно, чтобы заказчик выступал не в виде безликого подразделения или офиса — необходимо привести конкретные имена. К концу дня человек должен быть в состоянии решить, приемлемо ли поставляемое ПО для организации.
Доклею описания требований
.2,Дловои(контекстЛ .
.3 Участник! ■ проекта"
‘ 1А Идей в отношении решений;^
2 Системные ^рдисы
Райки системы. ;_6:
:&£4>Ун циональные требования
„ ^-Дз. ребования к Данном/.;
'jCMtirPiMHbieограничения.'^
*„^^3,1йТре№юния кинт^рфей/у4
3.2 ребовгниякпроизводигел ости.:?"г£
~ З-З^рёбования к?без( асности *
<|Й^^пт^^ш^.■ ■ Р"^■ ■ '- ^-%
$ .поди «»« ^^Йтай
, Л ,Д$^^ Ч
* ,M|oti||r^^ рро^4
'• $4.ЙМ^Мйгель^^пж^^-
'гдеардаьйы Mei
§ приложенияму-
' ■ ■' "йос^эдй"W
ЛЙ»йедокумента и:?-у"^
Рис. 3.7. Содержание документа описания требований
Хотя документ описания требований может быть как угодно далек от технических решений, все же важно обсудить идеи, касающиеся решения, на самых ранних этапах ЖЦ разработки. Особый интерес представляют готовые решения. Всегда неплохо рассмотреть вариант приобретения готового продукта вместо его разработки “с нуля”.
Документ описания требований должен предоставлять перечень существующих программных пакетов и компонент, которые должны быть в дальнейшем изучены в качестве вариантов возможных решений. Обратите внимание, что приобретение го-
тового решения изменяет процесс разработки, однако это не избавляет от необходимости проведения анализа требований и проектирования системы!
Наконец, неплохо в заключение раздела предварительных замечаний к проекту документа описания требований привести обзор оставшейся части документа. Это может подтолкнуть занятого читателя к тому, чтобы изучить остальные части документа, а также способствует лучшему пониманию содержания документа. Обзор также может содержать пояснения в отношении методологии анализа проектирования, выбранной разработчиками.
Системные сервисы
Основная часть документа описания требований посвящена определению системных сервисов (разд. 1.3.1 и 3.1). Эта часть может занимать до половины всего объема документа. Это также, пожалуй, единственная часть документа, которая может содержать обобщенные модели — модели бизнес-требований (разд. 3.5).
Рамки системы можно моделировать с помощью диаграммы контекста (разд. 3.5.1). В пояснениях к диаграмме контекста должны быть четко определены рамки системы. Без подобного определения проект не может быть застрахован от попыток “растянуть” его рамки.
Функциональные требования можно моделировать с помощью диаграммы бизнес- иреуедентов (разд. 3.5.2). Однако, диаграмма охватывает перечень функциональных требований только в самом общем виде. Как отмечалось в разд. 3.4, все требования необходимо обозначить, классифицировать и определить.
Требования к данным можно моделировать с помощью диаграммы бизнес-классов (разд. 3.5.3). Так же, как и в случае функциональных требований, диаграмма бизнес- классов не даст полного определения структур данных для бизнес-процессов. Каждый бизнес-класс требует дальнейших пояснений. Необходимо описать атрибутное наполнение классов и определить идентифицирующие атрибуты классов. В противном случае невозможно правильно представить ассоциации.
Системные ограничения •
Системные сервисы определяют, что должна делать система. Системные ограничения (разд. 1.3.1 и 3.1) определяют, насколько система ограничена при выполнении обслуживания. Системные ограничения связаны со следующими видами требований.
Требования к интерфейсу.
Требования к производительности.
Требования к безопасности.
Эксплуатационные требования.
Политические и юридические требования.
Требования к интерфейсу определяют, как система взаимодействует с пользователями. В документе описания требований определяется только “впечатление и ощущение" от GUI- интерфейоа. Начальное проектирование (закрашивание экрана) GUI-интерфейса проводится во время специфшкации требований и позже во время системного проектирования.
В зависимости от области приложения требования к производительности могут играть довольно значительную роль в успехе проекта. В узком смысле они задают скорость (время отклика системы), с которой должны выполняться различные задания. В
широком смысле, требования к производительности включают другие ограничения — в отношении надежности, готовности, пропускной способности и т.д.
Требования к безопасности описывают пользовательские права доступа к информации, контролируемые системой. Пользователям может быть предоставлен ограниченный доступ к данным или ограниченные права на выполнение определенных операций с данными.
Эксплуатационные требования определяют программно-техническую среду, если она известна на этапе проектирования, в которой должна функционировать система. Эти требования могут оказывать влияние на другие стороны проекта, такие как подготовка пользователей и сопровождение системы
Политические требования и юридические требования зачастую подразумеваются, чем явно формулируются в документе описания требований. Подобная ошибка может обойтись очень дорого. Пока эти требования не выведены явно, программный продукт может быть трудно развернуть по политическим или юридическим причинам.
Возможны и другие виды ограничений. Например, в отношении некоторых сис тем могут предъявляться повышенные требования к легкости их использования (требования в отношении пригодности к использованию) или легкости их сопровождения (требования в отношении пригодности к сопровождению).
Значение выработки недвусмысленных определений для системных ограничений трудно переоценить. Существует немало примеров проектов, которые провалились из-за упущенных или неверно понятых ограничений. Эта проблема в равной мере относится как к заказчикам, так и к разработчикам. Недобросовестные или нерассудительные разработчики могут разыграть “карту системных ограничений", чтобы получить преимущество в своем стремлении уклониться от ответственности.
Проектные вопросы
Заключительная часть документа описания требований обращается к другим проектным вопросам. Один из важных разделов этой части называется “Открытые вопросы. Здесь поднимаются все вопросы, которые могут сказаться на успехе проекта и которые не рассматривались в других разделах документа. Сюда относится ожидаемое возрастание значения некоторых требований, которые в текущий момент выходят за рамки проекта. Сюда можно отнести также любые потенциальные проблемы и отклонения в поведении системы, которые могут начаться в связи с развертыванием системы.
В этой же части необходимо представить предварительный план-график выполнения основных проектных заданий (разд. 1.3.8). Сюда же относится предварительное распределение людских и других ресурсов. Для выработки стандартных плановых графиков можно использовать программные средства управления проектами, например, такие как система PERT (program evaluation-and-review technique — метод оценки и пересмотра планов) или карты Гантта [51].
Прямым результатом составления план-графика может быть разработка предварительного бюджета. Стоимость проекта может быть выражена скорее в виде диапазона значений затрат, а не конкретного значения. При наличии надлежащим образом документированных требований для оценки затрат можно использовать один из подходящих методов (например, балльную функциональную оценку (functionpoint analysis)).
Приложения
Приложения содержат остальную, полезную для понимания требований, информацию. Основным добавлением здесь служит глоссарий. Глоссарий определяет термины, сокращения и аббревиатуры, используемые в документе описания требований. Значение толкового глоссария трудно переоценить. Неверное истолкование терминологии таит в себе большую опасность для проекта.
Одна из особенностей, которую часто упускают из виду при составлении документа описания требований, состоит в том, что в проблемной области, определяемой документом, можно довольно неплохо разобраться с помощью изучения документов и форм, используемых в процессах делопроизводства. При возможности следует включать в документ заполненные формы — “пустые" формы не дают такого же уровня понимания бизнес-процессов.
Раздел ссылок содержит перечень документов, которые упоминаются или используются при подготовке документа описания требований. К ним могут относиться книги и другие опубликованные источники информации, но — что, пожалуй, даже более важно — необходимо также упомянуть протоколы совещаний, служебные записки и внутренние документы.
Резюме
В этой главе были полностью рассмотрены вопросы, связанные с установлением требований. Установление требований предшествует их спецификации. Установление требований касается их выявления и оформления в виде документа, который носит преимущественно описательный характер. В результате спецификации требований — рассматриваемой в следующей главе — вырабатываются более формализованные модели требований.
Выявление требований связано с их поиском по двум направлениям — в области знаний о проблемной области и в области прецедентов. Эти два направления исследования требований дополняют друг друга и приводят к определению модели деловой деятельности для разрабатываемой системы.
Существуют различные методы выявления требований, среди которых можно назвать такие методы как проведение интервью С заказчиками и экспертами в проблемной области, анкетирование, наблюдение, изучение документации и программных систем, создание прототипов, JAD- и RAD-методы.
Полученные от заказчиков требования могут перекрываться и противоречить друг другу. Устранение дублирования и снятие противоречий — задача бизнес-аналитика, который решает ее с помощью согласования и проверти обоснованности требований. Для надлежащего решения этой задачи бизнес-аналитик должен построить матрицу зависимости требований, а также приписать требованиям определенные риски и приоритеты.
Большие проекты связаны с управлением большими массивами требований. Для таких проектов весьма существенным моментом является обозначение и классификация формулировок требований. Затем можно определить иерархию требований. Осуществление подобных шагов обеспечивает необходимый уровень прослеживаемости требований на последующих стадиях проекта, а также надлежащую обработку запросов на изменение требований.
Несмотря на то что установление требований не включает формального моделирования систем, уже на этом этапе ЖЦ разработки ПО можно построить бизнес-модель
основных требований. Бизнес-модель может быть представлена в виде трех общих диаграмм — диаграммы контекста, диаграммы бизнес-прецедентов и диаграммы бизнес- классов.
Документ, который создается в результате выполнения этапа установления требований— документ описания требований— начинается с общего описания замечаний к проекту (которое создается, в основном, в интересах представления проекта руководству). Основные части документа описывают системные сервисы и системные ограничения. Заключительная часть документа связана с остальными проектными вопросами, включая подробности, касающиеся проектного план-графика и бюджета.
Й) Вопросы
В процессе установления требований мы стремимся согласовать общие требования, связанные с представлениями о проблемной области, и требования, полученные в результате анализа прецедентов. Объясните, в чем состоит различие между этими двумя типами требований? Может ли один из них превалировать над другим в процессе установления требований? Объясните свои доводы.
При проведении интервью рекомендуется избегать небеспристрастных, предвзятых и наводящих вопросов. Можете ли вы представить себе ситуацию, при которой подобные вопросы могли бы принести выгоду проекту?
Что такое прототипирование? Насколько оно полезно для установления требований?
Что такое JAD-метод? В чем заключаются основные преимущества JAD-метода по сравнению с другими методами установления требований?
Что такое “растягивание рамок проекта”? Как справиться с этим явлением при установлении требований?
Перечислите и дайте определения проектных рисков.
Почему требования необходимо пронумеровать?
Что такое "подозрительная траектория изменений системы"?
В чем отличие субъектов диаграммы бизнес-прецедентов от внешних сущностей диаграммы контекста?
Опишите типичную структуру (оглавление) документа описания требований.
|В| Упражнения
В
*1кйЫ|бвк»;а^^рекламу,
i Рассмотрите постановку задачи для коммерческой деятельности по измерению затрат f на рекламу (Advertising Expenditure Measurement — АЕМ).
1. Организация, занимающаяся АЕМ-деятельностью, собирает данные по рекламе в ; отношении различных торговых точек, предлагающих средства аудиовизуальной i информацию, теле- и радиостанций, газет, журналов, а также кинематографа, на- ■ ружной и internet-рекламы.
2. Собранные данные позволяют охватить две области анализа, интересующие АЕМ- i клиентов. Клиенты могут заказать отчет о том, действительно ли реклама, за кото- t рую они платят, появляется так, как было предусмотрено (это называется монито- । рингом рекламной кампании). Клиент может также заказать отчет, который очерчи- ; вает их конкурентные позиции в отношении рекламы применительно к отрасли, в ко- ■ торой они работают (это называется отчетом о затратах). Отчеты о затратах
касаются уровня, которого достигли затраты рекламодателя или затраты на реклам» ный товар с точки зрения различных критериев (время, географические регионы, средства информации и т.д.).
Отчеты о затратах составляют основу АЕМ-деятельности. Фактически, любой АЕМ- ; клиент (не только клиент, занимающийся рекламой) может приобрести отчет в виде г программного обеспечения для генерации отчетов, изготовленного под заказ или в 1 виде отпечатанных отчетов. Клиентская база АЕМ-предприятия состоит из индивидуальных рекламодателей, рекламных агентств, средств массовой информации, :консультантов, покупающих средства информвции, а также руководителей подраз
делений сбыта и маркетинга, органов, планирующих развитие средств информвции, ,покупателей и т.д.
! 4. АЕМ-предприятие заключает контракты со многими торговыми точками, предла- , тающими средства информации, касающиеся получения от них на регулярной осно- i 'ве электронных файлов журнвлов, которые содержат информацию по содержанию :
;рекламы в этих торговых точках. Информация из регистрационных журналов пере
, носится в базы данных АЕМ, а затем подвергается тщательной проверке — отчасти ’ автоматически, отчасти вручную. Задача проверки состоит в том, чтобы подтвер- s дить, что все зафиксированные детали, касающиеся рекламы, овладеют достовер- • ностью и логичностью в контексте информационной среды. Существенную часть АЕМ-деятельности составляет ручной ввод (мониторинг) данных по рекламе, для ко
;торой не существует электронных учетных журналов.f
После ввода и проверки реклама подвергается ревалоризации — процессу оцени- ; вания затрат, необходимых на ту или иную рекламу.
У1. Измерение затрат на рекламу (АЕМ) — обратитесь к приведенной выше постановке задачи. Изобразите контекстную диаграмму для АЕМ-системы. Сделайте пояснения к модели.
У2. Измерение затрат на рекламу (АЕМ) — обратитесь к приведенной выше постановке задачи.
Изобразите диаграмму бизнес-прецедентов для АЕМ-системы. Сделайте пояснения к модели.
УЗ. Измерение затрат на рекламу (АЕМ) — обретитесь к приведенной выше постановке задачи. Изобразите диаграмму бизнес-классов для АЕМ-системы. Сделайте пояснения к модели.
Спецификация требований
Требования необходимо спеи,ифицироватъ (т.е. задать) графически или каким-либо иным формальным способом. Всесторонняя спецификация системы может потребовать использования многих типов моделей. Язык UML изобилует интегрированными методами моделирования, способными помочь бизнес-аналитику справиться с этой задачей. Спецификация — подобно процессу разработки ПО в целом — итеративный процесс с пошаговым наращиванием уровня детализации моделей. Немаловажную роль в успешном моделировании играет использование CASE-средств.
В результате спецификации требований вырабатываются три категории моделей: модели состояний, модели поведения и модели изменения состояния. Для каждой из категорий существует несколько методов работы с ними. В этой главе объясняются и иллюстрируются на примерах все основные методы моделирования языка UML.
Несмотря на то, что мы начнем изучение с моделей состояния, затем перейдем к моделям поведения, а затем — к моделям изменения состояний, это не отражает реальной последовательности, в которой проводится моделирование. Многие модели разрабатываются в параллель и служат источником взаимного развития. Это в особенности справедливо в отношении двух основополагающих типов моделей — моделей классов и моделей прецедентов.
Принципы спецификации требований
Спецификация требований связана с доскональным моделированиям требований заказчиков, определенных в процессе установления требований. При этом рассматриваются только услуги, которые стремятся получить от системы заказчики (формулировки сервисов) (разд.3.1). На этапе спецификации требований формулировки ограничений не подлежат дальнейшей проработке, хотя и могут претерпеть изменения как результат обычного цикла итерации.
В качестве входной информации процесса спецификации требований выступают неформальные требования заказчиков, а результатом этого процесса являются модели спецификации проектных конструкций. Эти модели (разд. 2.2) дают более формальное определение различных сторон (представлений) системы. Обычно требования пользователей в процессе спецификации подразделяются на две основные категории: функциональные требования и требования к данным.
В качестве результата этапа спецификации выступает расширенный (“детально проработанный”) документ описания требований (разд. 3.6). Новый документ часто называют документом спецификации требований (или просто “спецификацией" на жаргоне разработчиков). Структура исходного документа не изменяется, однако содержание значительно расширяется за счет глав, которые определяют требования заказчиков. Постепенно для целей проектирования и реализации документ спецификации требований заменяет документ описания требований (на практике, расширенный документ может по-прежнему называться документом описания требований).
Модели спецификаций можно разделить на три группы.
Модели состояний.
Модели поведения.
Модели изменения состояний.
Модели состояний “детализируют” требования к данным. Модели поведения обеспечивают детализированные спецификации для функциональных требований. Модели изменения состояний охватывают два вида требований. Они призваны объяснить, каким образом действие функций приводит к изменению данных.
Модели представляются в виде диаграмм на языке визуального моделирования (Visual Model ing Language} — в нашем случае это язык UML. Обычно диаграмма служит целям моделирования одной из сторон системы — состояний, поведения или изменения состояний. Заметное исключение составляет диаграмма классов, которая определяет все три аспекта — состояние и поведение объектов, и, косвенно, изменения состояний объектов.
Каждая диаграмма дает представление об определенной стороне системы. Взятые вместе диаграммы дают возможность разработчикам и пользователям взглянуть на предлагаемое решение с разных точек зрения, выделяя одни его стороны и игнорируя другие. Ни одна из диаграмм в отдельности не дает полного определения системы. Систему можно понять только через взаимосвязанный набор диаграмм.
Аналогично случаю интерпретации завершенных моделей конструирование диаграмм — это не последовательный процесс построения одной диаграммы за другой. Диаграммы разрабатываются в параллель, и в результате каждой последующей итерации к ним добавляются новые детали. В то время, как разработчики должны следовать строго определенному процессу разработки, решение о том, какая из моделей должна играть роль “движущей силы” разработки, в значительной мере зависит от личных предпочтений аналитика. Обычно диаграммы прецедентов и модели клас- "ов— как наиболее важные типы моделей — конструируются параллельно, взаимно “обогащая” друг друга идеями.
С каждой новой итерацией разработки глубина и степень детализации спецификации возрастает. Многие более глубокие свойства объектов модели выражаются скорее в текстовом, нежели графическом виде. Некоторые свойства определяют замысел объекта модели, а не результат анализа. Некоторые другие свойства могут отражать особенности CASE-средств.
Спецификации состояний
Состояние объекта определяется значениями его атрибутов и ассоциаций. Например, объект BankAccount (Банковский счет) может находиться в состоянии “превышение кредитного лимита”, если значение атрибута balance (баланс) отрица-
тельно. Поскольку состояния объекта определяются структурам данных, модели структур данных называются спеуификауиями состояний.
Спецификация состояний дает статический взгляд на систему (поэтому моделирование состояний часто называют статическим моделированием). Здесь основной задачей является определение классов проблемной области, их атрибутов и отношений с другими классами. Вначале операции классов обычно не рассматриваются. Они выводятся из моделей спецификации поведения.
В типичной ситуации сначала определяются классы-сущности, т.е. классы, которые определяют проблемную область и характеризуются постоянным присутствием в базе данных системы. Подобные классы иногда называются “бизнес-классами”. Классы, которые обслуживают системные события {управляющие классы) и классы, которые представляют GUI-интерфейс (классы представления или пограничные классы) не устанавливаются до тех пор, пока не станут известны поведенческие характеристики системы.
Моделирование классов
Модель классов — это краеугольный камень разработки объектно-ориентированной системы. Классы лежат в основании наблюдаемости свойств и поведения системы. К сожалению, классы всегда трудно поддаются определению, а свойства классов не всегда очевидны. Весьма маловероятно, чтобы два аналитика пришли к одному и тому же множеству классов и их свойств для одной и той же нетривиальной проблемной области. Хотя модели классов могут отличаться, конечный результат и степень удовлетворенности пользователя могут быть в равной мере достаточными (или в равной мере недостаточными).
Моделирование классов — это не детерминированный процесс. Не существует общего рецепта отыскания и определения наилучших классов. Этот процесс в значительной мере носит итеративный и пошаговый наращиваемый характер. К факторам, определяющим успешное проектирование классов, относится уровень квалификации и опыта аналитика, в частности, перечисленные ниже возможности.
Знания в области моделирования классов.
Понимание проблемной области.
Опыт в области аналогичных и успешных проектов.
Способность смотреть вперед и предвидеть последствия решений.
Готовность к пересмотру модели с целью устранения недостатков и т.д.
Последний момент связан с использованием CASE-средств. Широкомасштабное применение CASE-технологии может стать препятствием на пути разработки системы в технологически незрелых организациях (разд. 1.1.4.2). Однако использование CASE- средств для повышения личной продуктивности всегда оправдано.
Выявление классов
Два разных аналитика, как правило, не могут прийти к идентичным моделям классов для одной и той же проблемной области, и точно так же два разных аналитика не пользуются одним и тем же мыслительным процессом при выделении классов. Литература изобилует подходами, предлагаемыми для выявления классов. Аналитики могут поначалу даже следовать одному из этих подходов, однако последующие итерации.
как правило, обязательно приводят к использованию нешаблонных и в чем-то даже случайных механизмов.
Барами (Bahrami) [4] подробно изучил главные особенности четырех основных подходов к выявлению классов {class discovery). Ниже перечислены эти подходы.
Подход на основе использования именных групп.
Подход на основе использования общих шаблонов для классов.
Подход на основе использования прецедентов.
Подход CRC (class-responsibility-collaborators — класс-обязанности-“сотрудники”).
Барами [4] поставил в соответствие каждому из подходов опубликованные работы, однако — по нашему мнению— только последний подход обладает неоспоримым источником. Теперь мы обобщим эти подходы, а затем приведем примеры, в которых используется комплексный подход {mixed approach).
Подход на основе использования именных групп
Подход на основе использования именных групп (т.е. имен существительных в предложениях) предполагает, что аналитик читает формулировки документа описания требований в поисках именных групп. Каждое имя существительное рассматривается как нотенуиальный класс {candidate class). Затем список всех классов разделяется на следующие три группы.
Релевантные или подходящие классы.
Нечеткие или сомнительные классы.
Нерелевантные или неподходящие классы.
К нерелевантным {irrelevant) относятся классы, которые выходят за рамки проблемной области. Для них не удается дать формулировку их назначения. Опытные аналитики-практики вероятнее всего не включают неподходящие классы в первоначальный список потенциальных классов. Таким образом удается избежать формальных шагов по идентификации и исключению нерелевантных классов.
К релевантным {relevant) относятся классы, которые безусловно принадлежат проблемной области. Имена существительные, представляющие имена этих классов, часто встречаются в документе описания требований. Кроме того, значение и назначение этих классов можно обосновать на основе общих знаний о прикладной области, а также на основе изучения аналогичных систем, руководств, документов и патентованных программных пакетов.
К нечетким {fuzzy) относятся классы, которые нельзя уверенно и безоговорочно признать подходящими. Они составляют наибольшую проблему. Их необходимо проанализировать более глубоко, а затем либо включить в список релевантных классов, либо исключить из списка нерелевантных. Окончательное отнесение этих классов к той или другой группе, собственно, и проводит различие между хорошей и плохой моделью классов.
Подход на основе использования именных групп предполагает наличие полного и корректного документа описания требований. На практике это предположение редко соответствует действительности. Но даже если оно обоснованно, кропотливое изуче-
ние больших объемов текста не обязательно должно привести к получению исчерпывающего и точного результата.
Подход на основе использования общих шаблонов
для классов
Подход на основе использования общих шаблонов для классов позволяет вывести потенциальные классы на основе теории родовой классификации объектов. Теория классификации касается разделения мира объектов на удобные группы, что позволяет более эффективно строить рассуждения о них.
Барами [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 (Отмена резервирования)).
Подход на основе использования общих шаблонов классов служит в качестве полезного руководства, но не определяет систематического процесса, посредством которого можно было бы выделить надежное и полное множество классов. Этот подход можно с успехом использовать для определения начального множества классов или для проверки того, должны ли некоторые классы (полученные другими способами) присутствовать в нашем множестве или, напротив, отсутствовать в нем. Однако, подход на основе использования общих шаблонов классов слишком слабо связан со специфическими требованиями пользователей, чтобы претендовать на исчерпывающее решение.
Особая опасность, связанная с подходом на основе использования общих шаблонов классов, заключается в неверном истолковании имен классов. Например, что означает Arrival (Прибытие)? Означает ли это прибытие на взлетно-посадочную полосу (время приземления), прибытие к терминалу (время высадки), прибытие в зал возврата багажа (время таможенного досмотра) и т.д.? Аналогично, слово Reservation (в данном случае резервация. Прим, ред.) в среде североамериканских индейцев имеет совершенно иное значение по сравнению с тем, что имелось в виду до сих пор.
Подход на основе использования прецедентов
Подходу на основе использования прецедентов придается особое значение в языке UML. Можно даже сказать, что этот подход рекомендуется использовать в рамках UML (если быть точным — то в рамках методологии RUP (Rational Unified Process)). Графическая модель прецедентов сопровождается неформальными описаниями, а также диаграммами последовательностей и кооперации для отдельных прецедентов (разд. 2.2 и далее в этой главе). Эти дополнительные описания и шаги определения диаграмм (и объектов) требуется выполнить для каждого прецедента. На основе этой информации можно прийти к обобщениям, необходимым для выявления потенциальных классов.
Подход, направляемый прецедентами, обладает особенностями, присущими подходу снизу-вверх. После того, как прецеденты становятся известны, а представление о системе с точки зрения взаимодействия, по меньшей мере, частично определено с помощью диаграмм последовательностей, объекты, используемые в этих диаграммах, приводят к выявлению классов.
В действительности этот подход в чем-то похож на подход, использующий именные группы. Их объединяет тот факт, что прецеденты специфицируют требования. Оба подхода направлены на изучение формулировок, изложенных в документе описания требований, чтобы выявить в итоге потенциальные классы. То, что эти формулировки излагаются в повествовательной форме или представлены графически. имеет второстепенное значение. В любом случае на этом этапе ЖЦ разработки ПО большую часть прецедентов можно описать только в текстовой форме без диаграмм вза- -одействия.
Подход, основанный на прецедентах, страдает теми же недостач и, что и подход, использующий именные группы. Будучи по сути подходом сниз) ерх в смысле точности, он опирается на полноту и корректность моделей прецеден г>в. В результате, он даже может привести к нежелательному разбалансированию итеративного и наращива юго процесса разработки ПО, при котором модели прецедентов должны быть завершены еще до построения моделей классов. В общем, каковы бы ни были цели и средства, это приводит к функциональному подходу (Junction-driven, approach) (сторонники объектно-ориентированного подхода предпочитают называть его проблемно-ориентированным (problem-driven)).
Л. 1.4. Подход CRC
Подход CRC (Class-Responsibility-Collaborators — класс-ответственность-“сотруд- ники") представляет собой нечто большее, чем метод выявления классов, — это привлекательный способ интерпретации и изучения объектов (а также и обучения объектному подходу). Наибольшую известность подход CRC получил благодаря работам Ребекки Вирфс-Брок (Rebecca Wirfs-Brock) и ее коллег Б. Вилкерсон (В. Wilkerson) и Л. Винер (L. Wiener) [94], [93].
Подход CRC включает в себя сеансы “мозгового штурма”, проведение которых облегчается за счет использования специально подготовленных карточек. Карточки состоят из трех отделений: имя класса записывается в верхнем отделении, “обязанности” класса перечислены в левом отделении, а “сотрудники" перечислены в правом отделении. Обязанности— это услуги (операции), которые класс готов выполнить в интересах других классов. Для выполнения многих обязанностей необходимо участие (обслуживание) со стороны других классов. Такие классы перечисляются как “сотрудники".
Процесс CRC— это живой процесс, во время которого разработчики “играют в карты”, они заполняют карточки именами классов и назначают им “обязанности" и “сотрудников” в ходе исполнения сценария обработки информации (например, сценария прецедента). В тех случаях, когда возникает потребность в некоей услуге, а существующие классы не покрывают ее, создается новый класс, которому назначаются соответствующие “обязанности” и “сотрудники". Если класс становится “слишком занятым”, он разделяется на несколько меньших классов.
Подход CRC отличается от других подходов тем, что при его использовании выделение классов является результатом анализа сообщений, передаваемых между объектами для выполнения задач обработки информации. Акцент делается на унифицированном методе распределения “интеллекта” в системе, и некоторые классы могут быть скорее получены, исходя из подобной технической потребности, чем выявлены в качестве “бизнес-объектов” как таковых. В этом смысле метод CRC может быть более приемлемым для проверки правильности выбора классов уже выявленных с помощью других методов. Подход CRC также полезен при установлении свойств классов (которые логически следуют из “обязанностей” и типов “сотрудников” класса).
Комплексный подход
На практике процесс выявления классов в разное время, вероятнее всего, следует разным подходам. Зачастую, он включает элементы всех четырех подходов, рассмотренных выше. Немаловажными факторами при этом выступают общая эрудиция эксперта, его опыт и интуиция. Процесс в чистом виде не следует ни методу сверху-вниз, ни методу снизу-вверх — он все время идет “из средины”. Подобный подход к выявлению классов мы называем комплексным подходом (mixedapproach).
Вот один из возможных сценариев. Начальное множество классов можно сформировать на основе общих знаний и опыта эксперта. При этом дополнительно можно руководствоваться подходом на основе общих шаблонов классов. Остальные классы можно добавить, основываясь на анализе обобщенного описания проблемной области с использованием подхода на основе именных групп. Если в распоряжении аналитика имеются прецеденты, можно воспользоваться подходом, направляемым прецедентами, чтобы добавить новые и проверить состоятельность существующих классов. Наконец, подход CRC позволяет применить “мозговой штурм” для проверки правильности выбора выделенного к этому времени множества классов.
Некоторые правила выявления классов
Ниже приведен далеко не полный перечень руководящих принципов или правил, которым должен следовать аналитик при выборе потенциальных классов. Вновь напоминаем о том, что здесь мы имеем дело только с классами-сущностями.
Для каждого класса должно быть ясно сформулировано его назначение в системе.
Каждый класс — это шаблон описания множества объектов. Единичные классы, для которых можно представить существование только одного объекта, весьма маловероятны среди “бизнес-объектов”. Подобные классы обычно составляют в приложении “общее знание” и как правило жестко запрограммированы в программах приложения. Например, если система спроектирована для единственной организации, существование класса Organization (Организация) может быть не оправданно.
Каждый класс (т.е. класс-сущность) должен содержать набор атрибутов. Хорошим приемом является установление идентифицирующих атрибутов (ключей), чтобы помочь нам судить о мощности (cardinality) класса (т.е. ожидаемом количестве объектов данного класса в базе данных). Следует, однако, помнить о том, что класс не обязательно должен обладать пользовательским ключом. Объекты классов идентифицируются с помощью идентификаторов объектов (О//)) (разд. 2.1.1.3).
Каждый класс должен отличаться от атрибута. Представляется ли понятие классом или атрибутом зависит от области приложения. Цвет автомобиля обычно воспринимается как атрибут класса Саг (Автомобиль). Однако на фабрике по производству красок Color (Цвет) — это определенно класс со своими собственными атрибутами (яркостью, насыщенностью, прозрачностью и т.д.).
Каждый класс содержит набор операций. Однако на данном этапе мы не касаемся вопросов идентификации операций. Операции, входящие в интерфейс класса (сервисы, предоставляемые классом системе), являются логическим следствием формулировки назначения класса (пункт 1).
Примеры выявления классов
Давайте проанализируем требования с целью выделения потенциальных классов. В первом утверждении подходящими классами являются классы Degree (Степень) и Course (Курс). Эти два класса удовлетворяют пяти правилам, перечисленным ранее. Мы пока не уверены, должен ли .и каким образом класс Course быть сужен до классов CompulsoryCourse (Обязательный курс) и ElectiveCourse (Выборочный курс). Например, ясно, что курс является обязательным или выборочным в зависимости от степени. Возможно, что различие между обязательными и выборочными курсами может быть зафиксировано с помощью ассоциации или даже атрибута класса. Таким образом, CompulsoryCourse и ElectiveCourse рассматриваются как нечеткие классы.
Второе утверждение идентифицирует только атрибуты класса Course, а именно course_level (уровень курса) и credit_point_value (количество условных очков). Третье утверждение характеризует ассоциацию между классами Course и Degree. Четвертая формулировка вводит атрибут min_total_credit_points (минимальное общее количество условных очков) в качестве атрибута класса Degree.
^7 ’Пдом^4Д».43'апйс1^^7 ’Пдом^4Д».43'апйс1^
^7 ’Пдом^4Д».43'апйс1^
^7 ’Пдом^4Д».43'апйс1^
) Рассмотрите следующие требования к системе Запись на университетские курсы и вы-
■ делите потенциальные классы.;
; 1. Для получения каждой университетской степени существует несколько обязатель- > ? ных и несколько выборочных курсов.
' 2. Каждому курсу соответствует заданный уровень и значение условных очков (Creditpoint — условное очко, начисляемое за прослушивание какого-либо курса (за один курс может быть начислено несколько очков); студент обязан набрать на данном го
. ду обучения такое число курсов, чтобы число очков за них было не ниже определен-
• ного значения. Прим, ред.у
= 3. Курс может быть составной частью системы получения произвольного количества
( степеней.
i 4. Каждая степень определяет минимальное общее значение условных очков, требуе- I мое для получения степени (например, для степени бакалавра (вычислительные и i информационные системы) требуется 68 очков, включая обязательные курсы).
, 5. Студенты могут составлять из дисциплин программы обучения, приспособленные к s их индивидуальным нуждам и обеспечивающие им получение степени, на которую ; они претендуют.
Последнее утверждение позволяет нам выделить три новых класса: Student (Студент), Courseoffering (Предлагаемый курс) и StudyProgram (Программа обучения). Первые два, безусловно, являются релевантными классами, а вот StudyProgram можно превратить в ассоциацию между классами Student и Courseoffering. Поэтому StudyProgram классифицируется как нечеткий класс. Наши рассуждения отражены в табл. 4.1.
Пример 4 2. Mai зи адес-г экатг
i Рассмотрите следующие требования к системе Магазин видеопроката и выделите по; тенциальные классы.
: 1. Магазин видеопроката держит в запасе огромную видеотеку современных популярных ’видеофильмов. Конкретный фильм может храниться на видеокассетах или дисках.
: 2. Видеокассеты могут быть записаны в формате “Beta" или “VHS”. Видеодиски запи- ; саны в формате DVD.
‘ 3. Для каждого фильма установлен конкретный период проката (исчисляемый в днях) с i соответствующей платой за прокат за этот период.
; 4. Видеомагазин должен быть в состоянии немедленно дать ответ на любой запрос по ’ наличию фильмов в запасе, а также количеству кассет или дисков (текущие условия i по каждой ленте и диску должны быть известны и зафиксированы).
Таблица 4.1. Потенциальные классы (Запись на университетские курсы)
Релевантные классы
Нечеткие классы
Course (Курс)
Degree (Степень)
Student (Студент)
Courseoffering (Предлагаемый курс)
CompulsoryCourse (Обязательный курс) и ElectiveCourse (Выборочный курс) StudyProgram (Программа обучения)
Первое утверждение содержит несколько имен существительных, но только некоторые из них можно превратить в потенциальные классы. “Видеомагазин” — это не класс, поскольку он составляет всю систему (в базе данных может быть только один объект этого класса — так называемый единичный класс). Аналогично, понятия “запаса” и “видеотеки” слишком общие, чтобы рассматривать их в качестве классов, по крайней мере на этом этапе. Релевантными классами представляются 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
Первое утверждение содержит понятия “клиент”, “контракт” и “товар”. Наша общая эрудиция и опыт подсказывают нам, что это типичные классы. Однако понятия контракта и товара не входят в рамки системы Управление контактами с клиентами и должны быть отброшены.
■ Рассмотрите следующие требования к системе Управление контактами с клиентами и Т { выделите потенциальные классы.
i 1. Система поддерживает функции “постоянного контакта” с нашей наличной и потен- .
I циальной клиентской базой, так чтобы откликаться на ее нужды и заполучать новые
« контракты на приобретение наших тоааров.
- 2. Система хранит имена, номера телефонов, обычные почтовые и курьерские адреса
* и т.д. организаций и наших контактных лиц в этих организациях.
’ 3. Система позволяет нашим сотрудникам планировать задания и мероприятия, кото-
I рые необходимо провести в отношении наших контактных лиц. Сотрудники плани- ,руют задания и мероприятия для других сотрудников или для себя.
, 4. Задание — это группа мероприятий, которые осуществляются для достижения определенного результата. Результатом может быть превращение потенциального
i клиента в клиента, организация доставки товара или решение проблемы клиента. К • обычным типам мероприятий относятся телефонный звонок, визит, отправка факса, ( устройство обучения и т.д. '
Customer (Клиент) — это релевантный класс, однако мы можем предпочесть назвать его Contact (Контакт), имея в виду, что не все контакты осуществляются с нашими настоящими клиентами. Различие между наличным и потенциальным клиентом может оправдать или не оправдать введение таких классов как Currentcustomer (Наличный клиент) и ProspectiveCustomer (Потенциальный клиент). Поскольку уверенности у нас нет, мы объявляем эти классы нечеткими.
Второе утверждение проливает новый свет на приведенные выше рассуждения. Нам необходимо провести различие между контактной организацией и контактным лицом. Имя Customer не кажется слишком удобным для названия класса. Помимо прочего, понятие Customer подразумевает только наличного клиента и, кроме того, это может заключать в себе как понятие организации, так и контактного лица. Наше новое предложение состоит в том, чтобы назвать классы следующим образом: Organization (Организация), Contact (Контакт) (подразумевается контактное лицо), CurrentOrg (Наличная организация) (т.е. организация, являющаяся нашим наличным клиентом) и ProspectiveOrg (Потенциальная организация) (т.е. организация, являющаяся нашим потенциальным клиентом).
Во втором утверждении упоминается несколько атрибутов классов. Однако обычный и курьерский почтовые адреса представляют собой составные атрибуты и применимы к обоим классам: Organization и Contact. Поэтому PostalAddress и Courier Address — законные нечеткие классы.
Таблица 4.3. Потенциальные классы (Управление контактами с клиентами)
Релевантные классы
Нечеткие классы
Organization (Организация)
Contact (Контакт)
Employee (Сотрудник)
Task (Задание)
Event (Мероприятие)
CurrentOrg ProspectiveOrg PostalAddress CourierAddress
В третьей формулировке вводится три релевантных класса Employee (Сотрудник), Task (Задание) и Event (Мероприятие). Это предложение объясняет суть плановой деятельности.
Последнее утверждение посвящено дальнейшему прояснению смысла и взаимоотношений между классами, однако здесь не вводится ни одного нового класса.
4.2.1.2. Спецификация классов
После того, как перечень потенциальных классов сформирован, необходима их дальнейшая спецификация: классы требуется включить в диаграмму классов и определить их свойства. Некоторые свойства можно ввести и отобразить внутри графических пиктограмм, представляющих классы на диаграмме классов. Многие другие свойства, включенные в спецификацию класса, имеют только текстовое представление. CASE-средства, как правило, обладают возможностями редактирования, позволяющими легко вводить или модифицировать подобную информацию посредством диалоговых окон, снабженных вкладками, или с помощью аналогичных способов.
Как объяснялось в начале этой главы, классы задаются на определенном уровне абстракции. Более развитые возможности моделирования языка UML здесь не используются — они рассматриваются в главе 5 и последующих главах.
Именование классов
Каждому классу необходимо присвоить имя. При работе с некоторыми CASE- средствами помимо имени классу можно также присвоить код, возможно, отличный от имени. Код может удовлетворять соглашениям по именованию, требуемым целевым языком программирования или СУБД. Для генерации программного кода из проектной модели используется именно код класса, а не имя.
Мимоходом, мы приняли определенное соглашение в отношении имен классов. Это соглашение заключается в том, что имя класса начинается с заглавной буквы. Для составных имен в качестве первой буквы каждого слова также используется заглавная буква (вместо того, чтобы отделять слова знаком подчеркивания или дефисом), Это всего лишь рекомендуемое соглашение, однако среди разработчиков оно нашло довольно много приверженцев. (В разд. 6.1.3.2 к имени каждого класса рекомендуется добавить однобуквенный префикс для обозначения программного слоя, к которому принадлежит класс).
Имя класса должно быть именем существительным в единственном числе (например, Course) либо, при возможности, сочетанием прилагательного и существительного в единственном числе (например, CompulsoryCourse). Ясно, что класс представляет собой шаблон для множества объектов и использование в качестве имен существительных во множественном числе не несет никакой дополнительной информации. Иногда существительное в единственном числе не отражает истинного предназначения класса. В подобных ситуациях допустимо использование существительных во множественном числе (например, Rentalconditions (Условия проката) в примере 4.2).
Имя класса должно быть осмысленным. Оно должно отражать истинную природу класса. Ойо должно заимствоваться из словаря пользователей (а не жаргона разработчиков).
Лучше использовать более длинные имена, чем скрывать их смысл за шифром. Можно с уверенностью сказать, что имена длиной более тридцати символов слишком громоздки (а некоторые программные среды их просто не воспринимают, если CASE-
средства работают с именами классов, а не кодами классов). Возможно также использование более длинных описательных имен в дополнение к именам и кодам классов.
Выявление и спецификация атрибутов классов
Графическая пиктограмма, представляющая класс, состоит из трех отделений (имя класса, атрибуты, операции) (разд. 2.1.2). Спецификация атрибутов классов принадлежит к спеиифгскагуии состояний и рассматривается в этом разделе. Спецификация операций рассматривается позже в этой главе в разделе, посвященном спсуифи- кации поведения (разд. 4.3).
Выделение атрибутов осуществляется параллельно с выделением классов. Идентификация атрибутов своего рода “побочный эффект" установления классов. Это не означает, что выявление атрибутов — простая задача. Напротив, это процесс, требующий значительных усилий и многократных итераций.
Исходные модели спецификации определяют только атрибуты, являющиеся существенными для понимания состояний, в которых могут находиться объекты класса. Остальные атрибуты можно до поры до времени игнорировать (однако аналитик должен быть уверен в том, что установленная, но проигнорированная на определенном этапе информация не будет по ошибке утеряна и будет зафиксирована впоследствии). Маловероятно, чтобы все атрибуты класса были приведены в документе описания требований, однако важно не включать в спецификацию те атрибуты, которые не вытекают из требований. В последующих итерациях можно добавить больше атрибутов.
Для имен атрибутов мы рекомендуем придерживаться простого соглашения: в именах атрибутов использовать только строчные буквы, а слова в составных именах отделять подчеркиванием.
Примеры спецификации классов
■ '4'0..-,^ «.х-^ху^."У.-'^-'.*14 * "Л >$A*VX&- 8s №^№Й»"С;. ^^SZ^M- . ^..-«#С<*/<"• У-' . S'.-f» ^ :»*.»Ш
П> • 4,4. Запись н -зерен »п « урсы
" -44 ,«:й'-'-”. ^г ' I ' -^ . ■ -№: ■&*-£■• •''< ... -fs^V'*4-. «**#"---".'"" --».- -^S <-/'- ™—».-. ' w'-;z -» •'•,„.; <4
; Обратитесь к примеру 4.1 и рассмотрите следующие дополнительные требования, изложенные в документе описания требований.
I 1. Выбор студентами учебных курсов может быть ограничен из-за конфликтов распи- : сания, а также за счет ограничения на количество студентов, которое может быть i набрано на текущий предлгаемый курс.
i 2. Предлагаемая студентом программа обучения вводится в интерактивную систему записи < на курсы. Система проверяет программу на непротиворечивость и сообщает о любых * проблемах. Проблемы требуется решать при помощи научного руководителя. Оконча- f тельная программа является предметом научного согласования со стороны представите- I ля заведующего кафедрой, а затем направляется секретарю учебного заведения.
В первом утверждении упоминаются конфликты расписания, однако мы не знаем достоверно, как следует моделировать эту проблему. Возможно, что речь здесь идет о прецеденте, который процедурно определяет конфликты расписания. Вторую часть этой же формулировки можно смоделировать за счет ведения атрибута enrolment_quota (киота набора) в класс Courseoffering. Теперь также ясно, что класс должен обладать атрибутами year (год) и semester (семестр).
Вторая формулировка укрепляет нас во мнении о необходимости введения класса StudyProgram. Можно видеть, что класс StudyProgram сочетает в себе ряд дисцнп-
лин, предлагаемых к изучению в текущий момент. Поэтому класс 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).
Пример 4.5. Мага и; видеопроката"।
Обратитесь к примеру 4.2. Предположим, что мы прояснили требование 3 об условиях ( прокате. Ниже приведен перечень дополнительных требований.!
, 1. Плата за прокат отличается в зависимости от видеоносителя: кассета или диск (однако для двух типов кассет — Beta и VHS — она одинакова).
Хотя магазин держит в запасе видеодиски только одного формата — DVD, пользова- ; тели желали бы расширить в будущем систему проката и на другие форматы дисков. \
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, отражающий наличие в запасе фильма с данным названием, является производным
(derived) атрибутом, т.е. он может быть вычислен на основе имеющегося в наличии текущего количества фильмов — VideoMedium. number_currently_available.
Degree«РК» degree_name: String total credit points: IntegerDegree«РК» degree_name: String total credit points: IntegerCourse«РК» course_code: String «СК» course_name: String credit points: IntegerCourse«РК» course_code: String «СК» course_name: String credit points: Integer
Degree
«РК» degree_name: String total credit points: Integer
Degree
«РК» degree_name: String total credit points: Integer
Course
«РК» course_code: String «СК» course_name: String credit points: Integer
Course
«РК» course_code: String «СК» course_name: String credit points: Integer
StudyProgramyear: Datesemester: Integer
Student «РК» studentjd: String student name: StringStudent «РК» studentjd: String student name: StringCourseoffering year: Date semester: Integer enrolment quota: IntegerCourseoffering year: Date semester: Integer enrolment quota: Integer
Student «РК» studentjd: String student name: String
Student «РК» studentjd: String student name: String
Courseoffering year: Date semester: Integer enrolment quota: Integer
Courseoffering year: Date semester: Integer enrolment quota: Integer
Puc. 4.1, Спецификация классов (Запись на университетские курсы)Puc. 4.1, Спецификация классов (Запись на университетские курсы)MovieTitle«РК» movie_code: String movie_title: Stringdirector: String/ isJn stock: BooleanMovieTitle«РК» movie_code: String movie_title: Stringdirector: String/ isJn stock: BooleanVideoMediumvideo_condition: Byte$ percentage excellent condition: DecimalVideoMediumvideo_condition: Byte$ percentage excellent condition: Decimal
Puc. 4.1, Спецификация классов (Запись на университетские курсы)
Puc. 4.1, Спецификация классов (Запись на университетские курсы)
MovieTitle
«РК» movie_code: String movie_title: String
director: String
/ isJn stock: Boolean
MovieTitle
«РК» movie_code: String movie_title: String
director: String
/ isJn stock: Boolean
VideoMedium
video_condition: Byte
$ percentage excellent condition: Decimal
VideoMedium
video_condition: Byte
$ percentage excellent condition: Decimal
VideoTapeVideoTapeVideo DiskVideo Disk
VideoTape
VideoTape
Video Disk
Video Disk
Rentalconditions 1rental„period_in_days: Integer1 rental charge per period: CurrencyRentalconditions 1rental„period_in_days: Integer1 rental charge per period: CurrencyBetaTapeBetaTapeVHSTapeVHSTapeDVDDiskDVDDisk
Rentalconditions 1
rental„period_in_days: Integer1 rental charge per period: Currency
Rentalconditions 1
rental„period_in_days: Integer1 rental charge per period: Currency
BetaTape
BetaTape
VHSTape
VHSTape
DVDDisk
DVDDisk
Puc. 4.2. Спецификация классов (Магазин видеопроката)
Анализ первого утверждения говорит нам о том, что понятие наличного клиента выводится на основе ассоциации между классами Organization и Contract. Эта ассоциативная связь может быть довольно динамичной. Следовательно, нужда в классах CurrentOrg и ProspectiveOrg отпадает. Более того, наша система не касается управления контрактами и не отвечает за поддержку класса Contract. Лучший вариант, который просматривается в данном случае — смоделировать решение с помощью производного атрибута Organization. is_current. который обозначает наличную организацию и при необходимости может изменяться подсистемой управления контрактами.
Второе утверждение наводит на мысль о необходимости введения двух классов для адресов: PostalAddress и CourierAddress.
Оставшиеся формулировки требований дают дополнительную информацию о содержании атрибутов классов. Кроме того, здесь можно высказать несколько соображений, связанных с ассоциативными отношениями и ограничениями целостности (они будут рассмотрены позже).
: Обратитесь к примеру 4.3 и рассмотрите следующую дополнительную информацию.
Клиент рассматривается как наличный, если существует контракт с этим клиентом на поставку наших товаров или услуг. Однако, функции управления контрактами выходят за рамки нашей системы.
Система позволяет вырабатывать различные отчеты по нашим контактам на основе почтового и курьерского адресов (напрймер, находить всех клиентов по почтовому коду).
Дата и время создания задания фиксируются. Можно также сохранить значение “дохода", ожидаемого от осуществления задания.
Мероприятия для сотрудника отображаются на экране его компьютера в виде стра-
ницы календаря (один день на страницу). Приоритет каждого мероприятия (низкий, средний, высокий) визуально выделяется на экране.
5.5.6.7.8.6.7.8.Не со всеми мероприятиями связвно понятие "срок исполнения” — некоторые из них являются “бессрочными” (они могут выполняться в любое время в течение дня, на который они запланированы).
5.
5.
6.
7.
8.
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 гласит, что у каждого билета есть номер, однако этот номер не уникален среди всех билетов (он уникален только в рамках кампании). Мы вводим ат-
рибут ticket_nuinber, однако, не придаем ему статус первичного ключа для класса CampaignTicket. Два других атрибута CampaignTicket представляют цену билета (ticket_value) и статус билета (ticket_status). Общее количество билетов и количество проданных билетов— атрибуты класса Campaign (num_tickets и num_tickets_sold).
•«S3 Кий•«S3 КийОбратитесь к разделу 2.3.4 (Постановка задачи 4) и к разделу 3.5, в котором представлены бизнес-модель требований для приложения Телемаркетинг. Рассмотрите, в частности, диаграмму бизнес-классов на рис. 3.6 (разд. 3.5.3.1). Примите к сведению следующую дополнительную информацию.
•«S3 Кий
•«S3 Кий
Каждая кампания имеет свое название, которое, как правило, используется при ее упоминании. Кроме того, кампания обладает уникальным внутренним кодом для внутренних ссылок. Каждая кампания проводится в течение заданного периода времени. Вскоре после закрытия кампании проводится розыгрыш призов и объявляются владельцы выигрышных билетов.
Все билеты пронумерованы. В рамках кампании все билеты обладают уникальными номерами. Общее количество билетов, выпущенных для кампании, количество билетов, проданных до настоящего времени, и текущее состояние каждого билета известны (например, “наличный”, "заказан”, “оплачен”, "выигрышный").
Для установления производительности телемаркетеров благотворительного общества фиксируется продолжительность звонков и успешные результаты звонков (т.е. звонков, завершившихся заказом билетов).
В системе ведется обширная информационная база, касающаяся благотворителей. Помимо обычных деталей, относящихся к контактам (адрес, телефонный номер и т.д.) эта информация включает исторические подробности, такие как дата первого и последнего участия благотворителя в кампаниях вместе с общим количеством кампаний, в которых они участвовали. В системе также хранятся данные обо всех известных предпочтениях и ограничениях, связанных с благотворителем (например, таких как нежелательное время для звонков и обычно используемая им при покупке билетов кредитная карточка).
Телемаркетинговые звонки должны обрабатываться в соответствии с определенными приоритетами. Звонки, на которые не получен ответ или зафиксирован ответ автоответчика, требуется перепланировать, чтобы попробовать дозвониться позже. Важно изменять время повторных попыток дозвониться.
Можно пытаться дозвониться снова и снова до тех пор, пока не будет исчерпан лимит попыток. Этот лимит может отличаться для различных типов звонков. Нвпример, лимит для обычного “звонка-приглашения" может отличаться от лимите для "звонка- напоминания" благотворителю о невыполненном платеже.
Возможные результаты звонков классифицируются, чтобы облегчить ввод данных в систему телемаркетерами. Типичными видами результата являются: “успех” (т.е. билеты заказаны), “неудача", “перезвонить позже”, “нет ответа”, "занято”, "автоответчик”, "факс”, "неверный номер”, “разъединение".
Утверждение 3 обнаруживает несколько открытых вопросов. Какие структуры данных требуются нам для расчета продуктивности телемаркетеров? Чтобы ответить на этот вопрос нам требуется определить некоторые показатели, с помощью которых можно выразить продуктивность. Один из возможных вариантов состоит в том, чтобы подсчитывать среднее количество звонков в час и среднее количество успешных звонков в час. Затем можно вычислить показатель продуктивности, разделив количество ус-
пешных звонков на общее количество звонков. Теперь введем в класс Telemarketer соответствующие атрибуты: average_per_hour и success_per_hour.
PostalAddress street: String ро_Ьж: String city: String state: String post_code: String country: StringPostalAddress street: String ро_Ьж: String city: String state: String post_code: String country: StringCourierAddress street_and_directions: String city: String state: String country: String
PostalAddress street: String ро_Ьж: String city: String state: String post_code: String country: String
PostalAddress street: String ро_Ьж: String city: String state: String post_code: String country: String
Contact«РК» contactJd: Integer family_name: String first_name: String phone: String fax: String email: StringContact«РК» contactJd: Integer family_name: String first_name: String phone: String fax: String email: StringTask description: String createdjjt: Date value: CurrencyTask description: String createdjjt: Date value: CurrencyEvent description: String created dt: Date due dt: Date completed_dt: Date priority: ByteEvent description: String created dt: Date due dt: Date completed_dt: Date priority: ByteEmployee «РК» employeejd: String family_name: String first_name: String middle_name: StringEmployee «РК» employeejd: String family_name: String first_name: String middle_name: StringOrganization «РК» 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
Contact
«РК» contactJd: Integer family_name: String first_name: String phone: String fax: String email: String
Task description: String createdjjt: Date value: Currency
Task description: String createdjjt: Date value: Currency
Event description: String created dt: Date due dt: Date completed_dt: Date priority: Byte
Event description: String created dt: Date due dt: Date completed_dt: Date priority: Byte
Employee «РК» employeejd: String family_name: String first_name: String middle_name: String
Employee «РК» employeejd: String family_name: String first_name: String middle_name: String
Puc. 43. Спецификация классов (Управление контактами с клиентами)
Для вычисления показателей продуктивности телемаркетера необходимо запоминать продолжительность каждого звонка. Хранилищем для этой информации служит класс 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. У нас нет полного понимания того, как поддерживать требование о том, что последующие звонки должны производится в разное время дня. Очевидно, что это должно быть возложено
на алгоритм планирования, однако нам потребуется поддержка структур данных. К счастью, некоторый свет на эту проблему проливает следующая формулировка.
Результатом анализа утверждения 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. Спецификация классов (Телемаркетинг)
Моделирование ассоциаций
Ассоциации служат объединению объектов в системе. Они- способствуют взаимодействию между объектами. Без ассоциаций объекты могут устанавливать связь только во время прогона программы, если они совместно используют одни и те же атрибу-
ты или они имеют доступ (с помощью других средств, таких как глобальные переменные) к идентифицирующим объекты значениям других объектов.
Ассоциации представляют собой наиболее существенный вид отношений моделей, в частности, моделей постоянных “бизнес-объектов". Ассоциации поддерживают выполнение прецедентов и, таким образом, обеспечивают совмещение спецификации состояний и поведения.
Выявление ассоциаций
Нахождение основных ассоциаций представляет собой побочный эффект процесса выявления классов. При определении классов аналитик принимает решение об атрибутах классов, и некоторые из этих атрибутов являются ассоциациями с другими классами. Атрибуты могут относиться к элементарным типам данных либо могут вводиться в качестве других классов, устанавливая таким образом отношения с другими классами. По существу, любой атрибут, относящийся к неэлементарным типам данных, должен моделироваться как ассоциация (или агрегация) по классу, представляющему этот тип данных.
Выполнение пробного прогона прецедентов позволяет выявить остающиеся ассоциации. Устанавливаются пути взаимодействия между классами, необходимые для прогона прецедентов. Обычно ассоциации должны поддерживать эти пути взаимодействия.
Каждая тернарная ассоциация должна быть заменена циклом или бинарной ассоциацией. Тернарные ассоциации привносят риск неверного семантического истолкования.
Иногда для того, чтобы полностью выразить базовую семантику, циклы, образуемые ассоциациями, не должны коммутировать (быть замкнутыми) [51]. Это значит, что по меньшей мере одна из ассоциаций в цикле может быть производной (derived). Подобная ассоциация является избыточной в семантическом смысле и должна быть исключена (хорошая семантическая модель должна быть лишена избыточности). Вполне допустимо, что многие производные ассоциации, тем не менее, все же войдут в проектную модель (например, из соображений эффективности).
Спецификация ассоциаций
Спецификация ассоциаций подразумевает выполнение следующих действий.
Присваивание имен ассоциациям.
Присваивание имен ассоциативным ролям.
Установление кратности ассоциации (разд. 2.1.3.2).
Правила именования ассоциаций должны соответствовать соглашениям по именованию атрибутов — имена ассоциаций состоят из строчных букв, отдельные слова в имени ассоциации разделяются подчеркиванием (разд. 4.2.1.2.2).
Если два класса связаны только одним ассоциативным отношением, задавать имя ассоциации и ассоциативные ролевые имена между этими классами необязательно (разд. 2.1.2.1.1). CASE-средства могут внутренне различать каждую ассоциацию через системные идентификационные имена.
Ролевые имена можно использовать для раскрытия более сложных ассоциаций, в частности самоассоциативных отношений (self associations') (рекурсивных ассоциаций, которые связывают объекты одного и того же класса). При задании ролевых имен их следует выбирать с учетом того, что в проектной модели они станут атрибутами классов, расположенных на противоположных концах ассоциативной связи.
Кратность должна быть задана для обоих концов (ролей) ассоциации. Если вопрос кратности на этом этапе не ясен, нижняя и верхняя границы кратности можно опустить.
Пример спецификации ассоциации
Модель ассоциаций для приложения Управление контактами с клиентами показана на рис. 4.5. Чтобы продемонстрировать гибкость ассоциативного моделирования, имена ассоциаций и ролевые имена используются бессистемно.
0..10..10..10..1org_conorg_con0..10..10..10..10..10..1theOrganizationtheOrganizationcontactcontact11
0..1
0..1
0..1
0..1
org_con
org_con
0..1
0..1
0..1
0..1
0..1
0..1
theOrganization
theOrganization
contact
contact
1
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
.. CourierAddress
streeVand_directions: String city: String state: String
country: String
0..1
Contact
«РК» contactJd : Integer family_name: String firsLname: String
phone: String
fax: String
email: String
contact
1 theOrganization
Puc. 4.5. Спецификация ассоциаций (Управление контактами с клиентами)
"$ляй 7^£^^^^J,^:’^ ^.<”^Зз;У^V -W' '*
О ПР -4 8. Управление контактами с кл^ sw.,___, ^
Обратитесь к примерам 4.3 и 4.6. Требования, приведенные в этих примерах, позволя- j ют нам выявить и специфицировать ассоциации на классах для системы Управление t контактами с клиентами. j
Кратность всех ассоциаций между классами PostalAddress и CourierAddress с эдной стороны и классами Organization и Contact с другой равна “ноль или один”. Цадим пояснения к использованию ассоциации между классами Organization и PostalAddress).
На одном конце ассоциации объект Organization связан максимум с одним объек- гом PostalAddress, но только в том случае, если почтовый адрес организации извес- ген. На противоположном конце ассоциации конкретный объект PostalAddress связан с объектом Organization или объектом Contact. Следовательно, чтобы удовле- гворять этим ограничениям, кратность должна быть равна “ноль или один”. (Даже при >тих условиях, само ограничение необходимо отдельно зафиксировать документально с юмощью средств моделирования ограничений языка UML (разд. 5.1.2)).
Ассоциация между классами Organization и Contact демонстрирует использо- зание как имен ассоциаций, так и ролевых имен. Ролевые имена преобразуются в чмена атрибутов модели реализации приложения Управление контактами с клиентами. Модель реализации содержит следующие атрибуты: Organization. contact и Contact.theOrganization. Префикс “1Ье”означает, что роль theOrganization чмеет кратность точно равную “один”. (Артикль “the” употребляется в английском чзыке для указания на определенный, конкретный объект. Прим. ред.). Кратность ро- 1И contact равна “много” (нижняя и верхняя границы не установлены).
Кратность роли contact между классами Task и Contact не задана. Требования не объясняют, должно ли задание быть непосредственно связано с контактом. Поэтому у час нет уверенности в том, может ли оно быть связано более, чем с одним контактом.
Наконец, существует три ассоциации между классами Event и Employee. Эти ас- :оциации устанавливают, кто из сотрудников создает мероприятие, кто отвечает за :го выполнение и кто, в конце концов, завершает его. Во время создания мероприятия сотрудник, который работает над его завершением, неизвестен (поэтому крат- чость на конце ассоциации completed со стороны работника равна “ноль или один”).
Моделирование отношений агрегации и композиции
Агрегация и ее более строгая форма композиция служит проводником семантики ‘часть-целое” между составным (супермножество) классом и компонентным 'подмножество) классом (разд. 2.1.4). В языке UML агрегация трактуется как ограниченная форма ассоциации. Это колоссальное умаление роли агрегации в моделировании. Достаточно сказать, что агрегация, наряду с обобщением, является наиболее зажным методом многократного использования функциональных возможностей в збъектно-ориентированных системах.
Моделирующая способность языка UML значительно усилилась, если бы язык поддерживал четыре возможных семантики для агрегации [55].
Агрегация типа “Безраздельно обладает”.
Агрегация типа “Обладает”.
Агрегация типа “Включает”.
Агрегация типа “Участник”.
Агрегация типа Безраздельно обладает устанавливает следующее:
между компонентными классами и их составными классами установлено отношение зависимости по существованию (следовательно, удаление составного
объекта распространяется вниз по иерархии отношения, так что связанные компонентные объекты также удаляются);
агрегация транзитивна (если объект С1 является частью объекта Bl, а В1 является частью А1, тогда С1 является частью А1);
агрегация оетшмелфичнл (нерефлексивна) (если объект является частью объекта А1, то объект А1 не является частью В1);
агрегация стационарна (если объект В1 является частью объекта А1, то он не может быть частью объекта Аг (i*l)).
Агрегация типа Обладает поддерживает первые три свойства агрегации типа “Безраздельно обладает”, к которым относятся:
зависимость существований;
транзитивность;
асимметричность.
Агрегация типа Включает слабее, чем агрегация типа Обладает. Агрегация типа Включает поддерживает следующие свойства:
транзитивность;
асимметричность.
Агрегация типа Участник обладает свойством целенаправленного группирования независимых объектов— группирования, при котором не делается предположений относительно свойства зависимости по существованию, транзитивности, асимметричности или стационарности. Это абстракция, посредством которой совокупность членов-компонентов рассматривается как составной объект более высокого уровня. Компонентный объект в агрегации типа Участник может одновременно принадлежать более, чем одному составному объекту (поэтому, кратность агрегации типа Участник может иметь значение “многие ко многим).
Хотя агрегация получила признание как фундаментальная концепция моделирования, по меньшей мере, одновременно с обобщением [80], в объектно-ориентированном анализе и проектировании ей уделяется лишь незначительное внимание (за исключением областей приложений “совершенной парочки”, наподобие систем мультимедиа). К счастью, эта тенденция в будущем может перемениться, благодаря вкладу и проницательности методологов, работающих над шаблонами проектировангш. Это ясно видно, например, из трактовки агрегации (композиции) в плодотворной книге Гамма (Gamma) и др. [28].
2.З.1. Выявление агрегаций и композиций
Поиск агрегаций ведется параллельно с поиском ассоциаций. Если ассоциация проявляет одно или более из четырех семантических свойств, рассмотренных выше, то ее можно моделировать как агрегацию.
При объяснении отношения агрегации лакмусовой бумажкой выступают фразы “включает” (“has”) и “является частью” (“is-part-of). При истолковании отношения сверху-вниз по иерархии классов используется фраза “включает” (например. Книга “включает” Главу). При интерпретации снизу-вверх используется фраза “является частью" (например, Глава “является частью” Книги). Если предложение, описывающее отношение, прочитывается вслух с использованием этих фраз и оно лишено смысла на естественном языке, то это отношение неявляется агрегацией.
Со структурной точки зрения агрегация часто связывает воедино большое количество классов, тогда как ассоциация' степени выше двух бессмысленна (см. разд. 2.1.3.1). Когда требуется связать более двух классов воедино, отличным вариантом моделирования может быть агрегация типа Участник.
2.3.2. Спецификация агрегаций и композиций
Язык UML обеспечивает только ограниченную поддержку агрегации. Сильная форма агрегации называется в UML композицией. В композиции составной объект может физически содержать компонентные объекты (семантически это отношение берется “по значению”). Компонентный объект может принадлежать только одному составному объекту. Отношение композиции языка UML в большей или меньшей степени соответствует нашим агрегациям типа Безраздельно обладает и Обладает.
Слабая форма агрегации в UML называется просто агрегацией. Это отношение семантически берется “по ссылке” — составной объект физически не содержит компонентный объект. Один компонентный объект может обладать несколькими ассоциативными или агрегативными связями в модели. Попросту говоря, агрегация в языке UML соответствует нашим агрегациям типа Включает и Участник.
Сплошной ромб в языке UML представляет композицию. Пустой ромб используется для определения агрегации. В остальном спецификация агрегации совпадает с обозначениями для ассоциации.
2.3.3. Пример спецификации агрегации и композиции
О Пример .Э. Запись науниверситетские кура*
: Обратитесь к примерам 4.1 и 4.5. Рассмотрите следующие дополнительные требования.
Академическая характеристика студента должна быть доступна по требованию. Характеристика должна включать информацию об оценках, полученных студентом по каждому из курсов, на которые записался студент (и которые он не покинул без взыскания, т.е. в первые три недели с начала семестра).
2.2.За каждый курс отвечает преподаватель, однако этот курс могут вести и другие преподаватели. В течение разных семестров за один курс могут отвечать разные преподава- ■
2.
2.
5тели; кроме того, в течение разных семестров курс могут вести разные преподаватели, [
На рис. 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 (ответственный преподаватель)).
Рис. 4.6. Спецификация агрегаций (Запись на университетские курсы)
Моделирование отношений обобщения
Общие характеристики (атрибуты и операции) одного или более классов можно погрузить в более общий класс. Это явление известно как обобщение. Отношение обобщения соединяет родовой класс (суперкласс) с более специализированными классами (подклассы). Обобщение делает возможным наследование (многократное использование) характеристик суперкласса подклассом. В традиционных объектноориентированных системах наследование применяется к классам, а не к объектам (наследуются типы, а не значения).
Помимо наследования обобщение преследует еще две цели [76].
Подставимость.
Полиморфизм.
В соответствии с принципом подставимости (substitutability) объект подкласса является законным значением переменной суперкласса. Например, если переменная объявлена с целью хранения объекта Fruit (Фрукт), то объект Apple (Яблоко) является допустимым значением.
В соответствии с принципом полиморфизма (polymorphism) одна и та же операция может иметь разные реализации в разных классах. Вызывающий объект может вызвать операцию, не зная и не заботясь о том, какая из реализаций операции выполнится. Вызываемый объект знает, какому классу он принадлежит и выполняет свою собственную реализацию.
Полиморфизм работает лучше в тех ситуациях, когда он идет “рука об руку” с наследованием. Зачастую полиморфная операция в суперклассе объявляется^ а реализация для нее в этом классе отсутствует. Это значит, что операция получила сигнатуру (имя и список формальных аргументов), а реализация должна быть обеспечена в каждом из подклассов. Подобная операция называется абстрактной.
Абстрактную операцию не следует путать с абстрактным классом. Последний является классом, у которого отсутствуют непосредственные объекты-экземпляры ( однако его подклассы могут обладать объектами-экзеплярами). Экземпляров класса Vegetable (Овощи) может не существовать. Непосредственными экземплярами являются только объекты классов Potato (Картофель), Carrot (Морковь) и т.д.
Фактически, класс, обладающий абстрактной операцией, является абстрактным. Конкретный класс, наподобие Apple, не может иметь абстрактных операций [37]. Хотя абстрактные операции вводятся на уровне спецификаций поведения, абстрактные классы — это сфера спецификаций состояния.
Выявление обобщений
Многие суперклассы/подклассы аналитик отмечает еще в процессе формирования первоначального перечня классов. Многие другие обобщения можно обнаружить при определении ассоциаций.
Различные ассоциации (даже принадлежащие одному и тому же классу) может потребоваться связать с классом на различных уровнях обобщения/специализации. Например, класс Course может быть связан с классом Student (Student takes Course — студент берет курс), кроме того, этот класс может быть связан с классом TeachingAssistant (TeachingAssistant teaches Course — ассистент ведет, курс). Дальнейший анализ может показать, что класс TeachingAssistant является подклассом Student.
При поиске отношения обобщения лакмусовой бумажкой выступают фразы “может бытъ” ^‘сап-ЪсП и "это нечто epodd’ (“is-a-kind-of). При истолковании отношения сверху-вниз по иерархии классов используется фраза “может быть” (например, Student “can-be” a TeachingAssistant — “студент “может быть" ассистентом”). При интерпретацйи отношения снизу-вверх используется фраза “это нечто вроде" (например, TeachingAssistant “is-a-kind-of’ Student — “ассистент “это нечто вроде” студента”). Обратите внимание, что если также справедливо утверждение о том. что “ассистент— это “TeachingAssistant “is-a-kind-of’ Teacher”, то мы установили множественное наследование.
Спецификация обобщений
Отношение обобщения между классами показывает, что один класс совместно использует структуру или поведение, определенные в одном или более классов. Обобщение представляется в языке UML сплошной линией со стреловидным наконечником, указывающим на суперкласс.
Полная спецификация обобщения включает несколько мощных возможностей. Например, более подробное определение отношения может содержать квалификацию доступа к нему, указания на то, предоставляет ли класс права другому классу, решая, что необходимо делать в случае множественного наследования и т.д. Эти вопросы рассматриваются в главе 5.
Пример спецификации обобщений
На рис. 4.7 представлена расширенная модель классов для приложения Магазин видеопроката. Иерархия обобщения выражает тот факт, что видеоноситель (VideoMedium) “может бытъ” видеокассетой (VideoTape) или видеодиском VideoDisk. Видеокассета (VideoTape) “может бытъ” кассетой типа BetaTape или типа VHSTape. Видеодиск “может бытъ” диском типа DVDDisk (в настоящий момент
видеодиск “должен быть” диском DVDDisk, однако мы предполагаем, что в будущем возможно появление новых подклассов для Video Dis к).
Рис. 4.7. Спецификация обобщения (Магазин видеопроката)Рис. 4.7. Спецификация обобщения (Магазин видеопроката)У^У-wi? ■ .-'яму >».—-*«и|У^У-wi? ■ .-'яму >».—-*«и|
Рис. 4.7. Спецификация обобщения (Магазин видеопроката)
Рис. 4.7. Спецификация обобщения (Магазин видеопроката)
У^У-wi? ■ .-'яму >».—-*«и|
У^У-wi? ■ .-'яму >».—-*«и|
Обратитесь к примерам 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
Conditions лучше было бы связать в ассоциацию с конкретными объектами классов VideoTape и VideoDisk. Пока же мы примиримся с этой неэффективностью.
. Моделирование объектов
Моделирование касается проблем определения систем. Модель — это не действующая система, и поэтому она не отражает объектов-экземпляров. В любом случае, количество объектов в работающей системе может быть огромным, и представить их графически невозможно. Тем не менее, при моделировании классов мы часто представляем себе объекты и рассматриваем трудные сценарии с использованием примеров объектов.
Л. Спецификация объектов
Язык UML позволяет представить объекты графически (разд. 2.1.1.1). Мы можем изобразить диаграмму объектов, чтобы проиллюстрировать сложные отношения между классами или продемонстрировать изменения объектов со временем. Объектные модели можно использовать для иллюстрации и исследования способа взаимодействия объектов во время прогона программной системы.
S.2. Пример спецификации объектов
На рис. 4.8 показана диаграмма объектов, соответствующая модели классов, представленной на рис. 4.6. Из рисунка ясно, что объект-студент Student Don Donaldson физически содержит два объекта AcademicRecord (для курсов СОМР224 и СОМР326). К настоящему времени Don записался на два курса: СОМР225 и СОМР325. Изучение одного из курсов СОМР325 было предложено провести во втором семестре 2000-го года. За чтение этого курса отвечал профессор Rick Richardson.
Рис. 4.8. Диаграмма объектов (Запись на университетские курсы)
1 Наша задача в этом примере заключается а том, чтобы показать несколько объектов, j представляющих классы из модели классов на рис. 4.6 (пример 4.9).
Спецификация поведения
Поведение системы — так как оно выглядит для внешнего пользователя — изображается в вид прецедентов (разд. 2.2.2). Модели прецедентов можно разрабатывать на различных уровнях абстракции. Их можно применить к системе в целом для того, чтобы специфицировать основные функциональные блоки разрабатываемого приложения. Их также можно использовать для фиксации поведения пакетов UML, частей пакетов или даже класса внутри пакета.
На этапе анализа прецеденты вбирают в себя системные требования, концентрируясь на том, что делает или должна делать система. На этапе проектирования представление проектных решений в виде прецедентов можно использовать для спецификации поведения системы в том виде, как оно должно быть реализовано.
Поведение системы, закрепленное с помощью прецедентов, требует осуществить соответствующие вычисления и обеспечить взаимодействие объектов для выполнения этих прецедентов. Вычисления можно смоделировать с помощью диаграмм видов деятельности. Взаимодействие объектов можно задать с помощью диаграмм последовательностей или диаграмм кооперации. (В данной главе используются только диаграммы последовательностей, диаграммы кооперации используются далее в главах, посвященных проектированию (разд. 6.2).)
Спецификация поведения позволяет взглянуть на систему с точки зрения ее функционирования. Здесь основная задача состоит в том, чтобы определить прецеденты для области приложений и установить, какие классы участвуют в выполнении этих прецедентов. При этом необходимо идентифицировать операции классов и сообщения, передаваемые между объектами. Хотя взаимодействие объектов инициирует изменения состояния объектов, спецификации поведения дают функциональный взгляд на застывшее состояние системы. Изменения в состоянии объектов явным образом находят выражение в спецификациях изменения состояний.
Модели прецедентов должны нарабатываться итеративно и параллельно с моделями классов. Классы, введенные в спецификации состояний, подлежат дальнейшей детальной проработке, при этом обозначаются наиболее важные операции. Следует, однако, напомнить, что спецификация состояний определяет только классы сущностей (“биз1 iec-объектов”).
По мере создания моделей поведения появляются еще два уровня классов.
Классы, которые обслуживают события, инициируемые пользователями, и представляют бизнес-процессы ^управляющие классы).
Классы, представляющие GUI-интерфейсы (пограничные классы) (разд. 5.2.4).
Моделирование прецедентов
Моделирование прецедентов тесно связано с установлением требований (см. главу 3). Требования, изложенные в текстовом виде в документе описания требований, необходимо довести до прецедентов, зафиксированных в документе спецификации требований. Если остальной процесс разработки направляется прецедентами, то процесс называется проблемно-ориентированным (разд. 4.2.1.1.3).
Подобно моделированию классов моделирование прецедентов существенно итеративный и наращиваемый процесс. Первоначальную диаграмму прецедентов можно определить на основе требований верхнего уровня. Это может быть модель бизнес-
прецедентов (разд. 3.5.2). Для дальнейшего уточнения прецедентов следует руководствоваться более детализированными требованиями. Если в течение ЖЦ разработки требования пользователей подвергаются изменениям, эти изменения следует отразить сперва в документе описания требований, а уже затем — в модели прецедентов. Затем изменения в прецедентах доводятся до других моделей [37], [69].
Выявление прецедентов
При выявлении прецедентов аналитик должен убедиться в том, что он твердо придерживается сущности концепции прецедентов. Прецеденты представляют следующие компоненты общей модели системы [37], [47], [66], [76].
Завершенный фрагмент функциональных возможностей (включая основной поток логики управления, его любые вариации (подпотоки) и исключительные условия (альтернативные потоки?)^. '
Фрагмент внешне наблюдаемых функций (отличных от внутренних фунций).
Ортогональный фрагмент функциональных возможностей (прецеденты могут при выполнении совместно использовать объекты, но выполнение каждого прецедента независимо от других прецедентов).
Фрагмент функциональных возможностей, инициируемый субъектом (будучи инициирован, прецедент может взаимодействовать с другими субъектами). При этом возможно, что субъект окажется только на принимающем конце прецедента (может быть, опосредовано), инициированного другим субъектом.
Фрагмент функциональных возможностей, который предоставляет субъекту ощутимый полезный результат (и этот полезный результат достигается в пределах одного прецедента).
Выявление прецедентов основано на анализе следующих источников информации.
Требования, определенные в документе описания требований.
Субъектов и их целей применительно к системе.
Вопросы управления требованиями рассматривались в разделе 3.4. Напомним только, что требования представляются в отпечатанном виде. При поиске прецедентов нас интересуют только функциональные требования.
Прецеденты можно определить на основе анализа задач, выполняемых субъектами. Джекобсон (Jacobson) [39] предлагает ответить на ряд вопросов, касающихся субъектов. Ответы на эти вопросы могут позволить обозначить прецеденты. Вот эти вопросы.
Каковы основные задачи, выполняемые каждым субъектом?
Должен ли субъект получать доступ к информации в системе или модифицировать информацию?
Должен ли субъект информировать систему о любых изменениях в других системах?
Должен ли субъект быть проинформирован о непредвиденных изменениях в системе?
В ходе анализа прецеденты обращаются к личностным потребностям субъектов. В некотором роде это прецеденты субъектов. Поскольку прецеденты определяют основные строительные блоки для системы, то существует необходимость в выделении системных прецедентов. Системные прецеденты извлекают все то общее, что присутствует в прецедентах субъектов и дают возможность разработать общее решение, примени-
мое (через механизм наследования) к области прецедентов субъектов. “Субъектом” системного прецедента является разработчик/программист, а не пользователь. Системные прецеденты идентифицируются на этапе проектирования.
Спецификация прецедентов
Спецификация прецедентов включает графическое представление субъектов, прецедентов и четырех типов отношений, перечисленных ниже [24], [76].
Ассоциация.
Включение.
Расширение.
Обобщение прецедента.
Отношение асапципршустанавливает каналы связи между субъектом и прецедентом. В качестве стереотипов для отношений "включает' (include) и “расширяет1 (extend) используются слова «include» и «extend». Отношение обобщения позволяет специализировать прецедент посредством изменения любого из аспектов базового прецедента.
Отношение включения «include» позволяет вынести общее поведение за пределы включаемого прецедента. (Это отношение пришло на смену широко применяемой в более ранних версиях UML концепции отношения «uses» (использует)). Отношение «extend» обеспечивает контролируемую форму расширения поведения прецедента с помощью активизации другого прецедента в определенных точках расширения. Отношение «include» отличается от отношения «extend» в том, что “включаемый” прецедент является необходимым для завершения “активизирующего” прецедента.
На практике, проект может легко столкнуться с проблемами, если прилагать слишком большие усилия для выявления отношений между прецедентами и установления, какие отношения применимы к определенной паре прецедентов. Кроме того, обобщенные прецеденты имеют тенденцию к таким тесным связям, что взаимосвязи станут превалировать и загромождать диаграмму, смещая акценты с надлежащей идентификации прецедентов в сторону отношений между прецедентами.
Пример спецификации прецедентов
^■^v •■те-^е^■^v •■те-^е
^■^v •■те-^е
^■^v •■те-^е
Обратитесь к постановке задачи для системы Запись на университетские курсы, приве- I денной в разделе 2.3.1, а также к требованиям, определенным в примерах 4.1 и 4.4 раз- ; дела 4.2.1. Наша задача состоит в том, чтобы установить прецеденты на основе анализа |
функциональных требований.
На рис. 4.9 показана обобщенная диаграмма прецедентов для приложения Запись на университетские курсы. Модель содержит четыре субъекта и четыре прецедента. Каждый прецедент инициируется субъектом и является завершенным, внешне видимым и ортогональным фрагментом функциональных возможностей. Все субъекты, за исключением субъекта Student, представляют собой инициируюи^их субъектов. Субъект Student получает результаты экзаменов и инструкции по записи на учебные курсы перед тем, как программа обучения в следующем семестре (учебном периоде) может быть введена и проверена.
Прецедент Provide Examination Results (Предоставить результаты экзаменов) может “расширить” («extend») прецедент Provide Enrolment Instructions (Предоставить инструкции по записи). Первый прецедент не всегда расширяет последний прецедент. Например, для новых студентов результаты экзаменов неизвестны. Вот почему отношение моделируется с использованием стереотипа расширения («extend»), а не включения («include»).
Отношение «include» было установлено от прецедента Enter Program of Study (Ввести программу обучения) к прецеденту Validate Program of Study (Проверить программу обучения). Отношение «include» означает, что первый из прецедентов всегда включает последний. Как только программа изучения введена, она проверяется на предмет конфликтов расписания, специальных согласований и т.д.
Рис. 4.9. Диаграмма прецедентов (Запись на университетские курсы)Рис. 4.9. Диаграмма прецедентов (Запись на университетские курсы)
Рис. 4.9. Диаграмма прецедентов (Запись на университетские курсы)
Рис. 4.9. Диаграмма прецедентов (Запись на университетские курсы)
Обратитесь к постановке задачи для системы Управление контактами с клиентами, приведенной а разделе 2.3.3, а также к требованиям, определенным в примерах 4.3 и 4.6 раздела 4.2.1. Наша задача состоит в том, чтобы установить прецеденты на основе анализа функциональныхтребований.
На диаграмме прецедентов для приложения Управление контактами с клиентами представлены три субъекта и пять прецедентов (рис. 4.10). Эта модель обладает интересной особенностью: субъекты связаны отношением обобщения. Менеджер по обслуживанию клиентов (Customer Services Manager) — “это нечто вродё' сотрудника по обслуживанию клиентов (Customer Services Employee), который в свою очередь “нечто вродё’ сотрудника (Employee). Обобщающая иерархия делает диаграмму более выразительной. Любое мероприятие, выполненное сотрудником, может также выполнить сотрудник по обслуживанию клиентов или менеджер по обслуживанию клиентов. Следовательно, менеджер по обслуживанию клиентов неявно входит в ассоциацию (и может инициировать) любой прецедент.
Прецедент создания задания (Create Task) “включает” прецедент планирования события (Schedule Event), как следствие того требования, что задание нельзя создать, не запланировав первое мероприятие. Отношение “расширяет” обозначает тот факт, что завершение мероприятия может инициировать изменения деталей, связанных с организацией или контактом.
Maintain ContactComplete EventCreate TaskMaintain ContactComplete EventCreate Task
Maintain ContactComplete EventCreate Task
Maintain ContactComplete EventCreate Task
Обратитесь к постановке задачи для системы Магазин видеопроката, приведенной вОбратитесь к постановке задачи для системы Магазин видеопроката, приведенной вПример 4.14.Пример 4.14.Puc. 4.10. Диаграмма прецедентов (Управление контактами с клиентами)
Обратитесь к постановке задачи для системы Магазин видеопроката, приведенной в
Обратитесь к постановке задачи для системы Магазин видеопроката, приведенной в
Пример 4.14.
Пример 4.14.
разделе 2.3.2, а также к требованиям, определенным в примерах 4.2 и 4.5 раздела 4.2.1. | Наша задача состоит в том, чтобы установить прецеденты на основе анализа функцио- < нальных требований. j Для одного из прецедентов напишите неформальную спецификацию, включающую еле- ‘
дующие разделы: “Резюме", “Субъекты”, “Предпосылки", "Описание", “Исключения" j и "Постусловия".:
На диаграмме прецедентов для приложения Магазин видеопроката представлены только два субъекта и шесть прецедентов (рис. 4.11). Второстепенные субъекты, наподобие клиента (Customer) или поставщика (Supplier), не показаны. Эти субъекты не инициируют ни одного прецедента. Все прецеденты инициирует работник (Employee). Между субъектами Scanning Device (устройство сканирования) установлено отношение “зависимостпгГ ^dependency), которому аналитик присвоил стереотип в виде фразы «depends on» (аависитот).
Табл. 4.4 является иллюстрацией того факта, что графическое представление прецедентов являет собой лишь один из аспектов полной модели прецедентов. Каждый прецедент диаграммы в дальнейшем должен быть задокументирован в репозитории CASE- средства. В частности, необходимо текстовое описание. В табл. 4.4 используется одна популярная структура для описательной спецификации прецедентов (разд. 2.2.2.4).
Таблица 4.4. Описательная спецификация прецедента “Прокат видео” (Магазин видеопроката)
Прецеденты
Прокат видео ' " “
Краткое описание
Клиент желает взять иа прокат видеокассету или диск, которые снимаются с полки магазина или были предварительно зарезервированы клиентом. При условии,, что у клиента нет неоплаченных счетов, сразу после внесения платы кассета выдается напрокат. Если кассета не возвращаете я вовремя, клиенту отправляется напоминание о просроченном возврате.
Субъекты
Employee (Сотрудник), Scanning Device (устройство сканирования)'
Окончание табл. 4.4
Прецеденты
Прокат видео
Предпосылки
В наличии имеются видеокассеты или диски, которые можно взять напрокат. У клиентов есть клубные карточки. Устройство сканирования работает правильно. Работники за прилавком , знают, как обращаться с системой.
Основной поток
Клиент может спросить работника о наличии видео (включая зарезервированные видеофильмы) или может взять кассету или диск с полки. Видеоноситель и членская;карточка сканируются и работнику не сообщается никаких сведений о неплатежах или задержках, так что он не задает клиенту соответствующих вопросов. Если клиент не нарушает правил, тогда он может взять максимум до восьми видеофильмов. Однако если статус клиента определен как "ненадежный’’, то его просят внести задаток за один период проката каждой кассеты или диска. После получения суммы задатка информация о наличии фильмов обновляется, и кассета или диск п редаются клиенту вместе с чеком на прокат. Клиент расплачивается наличными с помощью кредитной карточки или электронного перевода. Каждая запись о прокате хранит (под учетным номером клиента) дату выдачи и срок возврата видеофильма вместе с идентификатором работника. Для каждого видеофильма, сданного напрокат, создается отдельная запись.
Прецедент генерирует напоминание о просроченном возврате клиенту, если видеофильм не был возвращен в течение двух дней по истечении даты возврата, а Также повторное напоминание по истечении следующих двух дней (и в этот момент клиент помечается как “нарушитель’’)
Альтернативные потоки
У клиента нет членской карточки. В этом случае прецедент “Maintain Customer” (сопровождение клиентов) может быть активизирован для выдачи новой карточки.
Попытка взять напрокат слишком много видеофильмов. Видеофильмы не выдаются из-за нарушения клиентом правил. Видеоноситель или членская карточка не могут быть отсканированы из-за их повреждения.
Электронный перевод денег или платеж по кредитной карточке отклоняются.
Постусловия
Видеофильмы сданы напрокат, и база данных-соответствующим образом обновлена.
Решение для примера 4.15, приведенное на рис. 4.12, состоит из нескольких прецедентов. Субъекты непосредственно взаимодействуют с тремя прецедентами: планирования и осуществления следующего звонка (Schedule and Make Next Call), записи результатов звонка (Record Call Outcome) и отображения деталей звонка (Display Call Details). По-
следний прецедент может быть в свою очередь "расширен” до отображения подробностей о кампании (Display Campaign Details), отображения истории благотворителя (Display Supporter History) и отображения подробностей о призе (Display Prize Details). Прецедент обновления информации по благотворителю (Update Supporter) “расширяет” Display Supporter History. Запись заказа на билет (Record Ticket Order) и планирование повторного вызова (Schedule Callback) может "расширить” Record Call Outcome. Предполагается, что субъекты могут независимо связываться с прецедентами расширения, однако каналы связи для этих прецедентов явно не показаны.
Update Supporter
Рис. 4.12. Диаграмма прецедентов (Магазин видеопроката)
Моделирование видов деятельности
Диаграммы видов деятельности были введены в язык UML сравнительно недавно (разд. 2.2.3). Подобно традиционным потоковым диаграммам и структурным схемам, получившим распространение в рамках структурных методов для разработки процедурно-ориентированных программ, диаграммы видов деятельности представляют Поток логики управления в объектно-ориентированных программах (хотя и на более высоком уровне абстракции). Различие же заключается в возмржности представления с помощью диаграмм видов деятельности управления параллельными потоками наряду с последовательным управлением.
Модели видов деятельности широко используются в проектировании Однако они также служат в качестве отличного метода изображения вычислений или технологических процессов на уровне абстракции, который подходит для анализа. Граф i видов деятельности можно использовать для демонстрации различных уровней детализации вычислений.
Модели видов деятельности могут быть особенно полезны для определения потоков видов деятельности в процессе выполнения прецедентов. Поскольку модели видов деятельности не отображают объектов, которые осуществляют деятельность, граф видов деятельности можно построить даже в том случае, когда модель классов отсутствует или разрабатывается. В конце концов каждый вид деятельности определяется одной или несколькими операциями в одном или нескольких кооперирующихся классах. Детальная проработка такой кооперации может быть осуществлена с использованием диаграмм кооперации (разд. 6.2.2).
Выявление видов деятельности
Каждый прецедент можно моделировать с помощью одного или нескольких графов видов деятельности. Событие, источником которого служит субъект инициирующий прецедент, это то же самое событие, которое запускает выполнение графа видов деятельности. Процесс выполнения последовательно переходит от одного состояния вида деятельности к другому. Состояние вида деятельности считается завершенным, когда завершается его вычисление. Внешние инициируемые событиями прерывания, которые могут вызвать завершение состояния вида деятельности, допускаются только в исключительных случаях. Если ожидается, что подобные события могут происходить часто, то следует вместо этого воспользоваться диаграммой состояний.
Виды деятельности лучше всего выявлять на основе анализа предложений неформальной спецификации прецедентов (табл. 4.4). Каждая , фраза, содержащая глагол, может рассматриваться как потенциальный ВИД ^деятельности. Описание альтернативных потоков вводит в граф видов деятельности ветвление и разделение потоков. Они приводят к исключительным (непредвиденным) состояниям деятельности. Возможны также параллельные потоки управления.
Спецификация видов деятельности
После выявления состояний видов деятельности спецификация видов деятельности выглядит как довольно простой процесс соединения этих состояний линиями переходов. Параллельные потоки инициируются (разделяются) и сливаются, что отображается на диаграмме в виде жирной полосы, обозначающей синхронизацию потоков. Альтернативные потоки создаются (разветвляются) и объединяются, что отображается в виде ромбов ветвления.
Внешние события на графе видов деятельности обычно отсутствуют. Однако существует графический метод включения внешнйх событий в граф. Аналогично, суще-
ствуют графические обозначения для состояний потоков объектов для представления объектов, которые являются входными или выходными для вида деятельности.
Пример спецификации видов деятельности
Рис. 4.13. Диаграмма видов деятельности для прецедента “Rent Video”Рис. 4.13. Диаграмма видов деятельности для прецедента “Rent Video”(Магазин видеопроката)(Магазин видеопроката)
Рис. 4.13. Диаграмма видов деятельности для прецедента “Rent Video”
Рис. 4.13. Диаграмма видов деятельности для прецедента “Rent Video”
(Магазин видеопроката)
(Магазин видеопроката)
На рис. 4.13 представлена диаграмма видов деятельности для прецедента “Rent Video”. Нет ничего удивительного в том, что диаграмма отражает неформальную спецификацию прецедента (табл. 4.4). Обработка начинается со сканирования клубной карточки клиента или видеоносителя. Эти два вида деятельности рассматриваются независимо друг от друга (что показано с помощью символа разделения).
Моделирование взаимодействий
Диаграммы последовательностей и диаграммы кооперации относятся к диаграммам взаимодействия. Они отражают характер взаимодействия объектов между собой, которое необходимо для выполнения прецедента, операции или другой поведенческой компоненты.
Диаграммы последовательностей показывают обмен сообщениями между объектами, упорядоченными в виде временной последовательности. Диаграммы кооперации выделяют отношения между объектами, по которым происходит обмен сообщениями. Мы считаем диаграммы последовательностей более полезными для анализа, а диаграммы кооперации — для проектирования.
Поскольку' модели взаимодействия ссылаются на объекты, они требуют, чтобы по меньшей мере первая итерация моделирования состояний была завершена, а основные классы объектов определены. Хотя взаимодействия влияют на состояния объектов, диаграммы взаимодействия не отражают в явном виде изменений состояния объектов. Это относится к области спецификации изменения состояний и диаграммам состояний (разд. 2.2.6 и 4.4).
Диаграммы взаимодействия можно использовать для определения операций (методов) классов (разд. 2.2.5 и 4.3.4). Любое сообщение, направляемое объекту на диаграмме взаимодействия, должно быть обслужено некоторым методом, определенным в классе этого объекта.
Выявление последовательностей сообщений
Выявление последовательностей сообщений является логическим продолжением моделирования видов деятельности. Виды деятельности, представленные на соответствующей диаграмме, отображаются на сообщения диаграммы последовательностей. Если уровни абстракции, используемые для построения модели видов деятельности и модели последовательностей, совпадают, то осуществить отображение видов деятельности на сообщения довольно просто.
Спецификация последовательностей сообщений
При спецификации сообщений полезно проводить различие между сообщением, представляющим собой сигнал, и сообщением, которое являет собой вызов операции [76]. Сигнал означает асинхронное взаимодействие объектов. Отправитель может продолжить выполнение потока сразу после отправки сигнального сообщения. Вызов означает синхронное обращение к операции с условием возврата управления отправителю. Возвращаемое сообщение может возвращать вызывающему объекту некоторые значения либо просто уведомлять его об успешном завершении операции. В последнем случае, возвращаемое сообщение отображать на диаграмме последовательностей не обязательно.
Пример спецификация последовательностей
На рис. 4.14 показана диаграмма последовательностей для приведенного выше сценария. Субъект Data Entry Person (Лицо, вводящее данные) инициирует прецедент, отправляя сообщение с запросом объекту граничного класса ProgramEntryWindow (Окно программы ввода) для того, чтобы добавить студента (обозначенного аргументом std) к списку записавшихся на курс (аргумент crs) в данном семестре (аргумент sem).
№»3№1ИЬ*5' 4 * ■ Л Л 31 ** «R** wsww ■ №№.4. .д; ИР^&Й?1^* ?■ @я*еж
; Обратитесь к примерам 4.9 и 4 12, а также к прецеденту “Enter Program of Study", пока- i занному на рис. 4.9. Наша задача состоит в том, чтобы построить диаграмму последова- | тельностей для этого прецедента.
; Мы не касаемся здесь вопросов проверки корректности введенной программы обуче- { ния. Проверке обязательных условий, наличия конфликтов в расписании, специальных j разрешений посвящен другой прецедент (“Validate Program of Study”). Наша задача со- [ стоит только в том, чтобы проверить, действительно ли в текущем семестре предлага- f ется курс, на который желает записаться студент, и открыта ли еще на него запись (есть
J ли свободные места),
: Data Entry Person: Data Entry Person: ProgramEntryWindow: ProgramEntryWindowaStudent: StudentaStudent: StudentaCourse:CourseaCourse:CourseaCourseOffering:CourseofferingaCourseOffering:CourseofferingЛ add(std,crs,sem)J.Л add(std,crs,sem)J.areYouValid(out s_check)areYouValid(out s_check)
: Data Entry Person
: Data Entry Person
: ProgramEntryWindow
: ProgramEntryWindow
aStudent: Student
aStudent: Student
aCourse:Course
aCourse:Course
aCourseOffering:Courseoffering
aCourseOffering:Courseoffering
Л add(std,crs,sem)J.
Л add(std,crs,sem)J.
areYouValid(out s_check)
areYouValid(out s_check)
[s_check=‘no’]destroy
areYouOpen(out c_check)
areYouOpen(out ccheck)
[c_check=‘no']destroy
addCourse(crsOID) |
BddStudent(stdOID)BddStudent(stdOID)i BddStudent(stdOID) ।i BddStudent(stdOID) ।
BddStudent(stdOID)
BddStudent(stdOID)
i BddStudent(stdOID) ।
i BddStudent(stdOID) ।
Puc. 4.14. Диаграмма последовательностей для прецедента “Enter Program of Study (Запись на университетский курсы)
Объект класса ProgramEntryWindow проверяет с помощью объекта aStudent, имеет ли право студент записаться (например, внес ли студент s_check соответствующую плату). Выходной аргумент возвращает значение “yes” или “по” объекту : ProgramEntryWindow. Если возвращается значение “по”, запись не может продолжаться, и объект : ProgramEntryWindow отправляет автосообшение самому себе, чтобы уничтожить (destroy) себя (операция деструктора). Запись условия в квадратных скобках говорит о том, что операция деструктора является необязательной.
Использование автосообщения для указания на необходимость уничтожения объекта является просто сокращенной записью. В действительности объект-экземпляр не может уничтожить себя. Сообщение об уничтожении (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 и areYoudpen, представляющих собой запросы на возможность записи и наличие мест на курсе.
Моделирование открытых интерфейсов
Открытый интерфейс (public interface) класса определяется набором операций, предлагаемых классом в качестве услуг другим классам в системе. Подобные операции объявляются с открытой видимостью. Объекты могут кооперироваться для выполнения прецедентов только посредством открытых интерфейсов.
Открытые интерфейсы впервые определяются ближе к окончанию этапа анализа, когда спецификации состояний и поведения в значительной степени определены. В ходе анализа мы определяем только сигнатуру каждой открытой операции (имя операции, список формальных аргументов, тип возвращаемого значения). В ходе проектирования мы даем определение алгоритмам для метода, реализующего операцию.
. Выявление операций классов
Операции классов лучше всего определять на основе диаграмм последовательностей. Каждое сообщение в модели последовательностей, отличное от возвращаемого
значения, должно быть обслужено операцией в объекте-приемнике (разд. 2.2.5.2). Если модели последовательностей полностью построены, определение открытых операций представляется автоматической задачей.
Однако на практике диаграммы последовательностей — даже если они разработаны для всех прецедентов — могут не обеспечить достаточного уровня детализации, позволяющего выявить все открытые операции. Кроме того, диаграммы последовательностей для операций, которые пересекают границы прецедентов, могут отсутствовать (например, когда деловые операции охватывают более одного прецедента).
Поэтому при выявлении операций могут оказаться полезными вспомогательные методы. Один из таких методов проистекает из того соображения, что объекты отвечают за собственную “судьбу” и поэтому они должны поддерживать четыре элементарных операции.
“Создать” (Create).
“Читать” (Read).
“Обновить” (Update)4.
“Удалить” (Delete).
Этот набор операций известен как CRUD-операции (разд. 3.5.2.1). CRUD-операции позволяют другим объектам отправлять сообщение объекту’ с требованием выполнить следующие действия.
Создать новый экземпляр объекта.
Получить доступ к состоянию объекта.
Модифицировать состояние объекта.
Объекту уничтожить самого себя.
Спецификация операций классов
На этом этапе ЖЦ разработки ПО необходимо модифицировать диаграмму классов, чтобы ввести в модель сигнатуры операций. Здесь можно также определить область действия операций. По умолчанию предполагается использование области действия экземпляра (операция применяется к объектам-экземплярам). Область дейст- вия-класс (статическая) должна быть объявлена явно (указанием символа “$” перед именем операции). Область действия-класс устанавливает, что операция применима к объектам классам (разд. 2.1.6).
Другие свойства операции, такие как параллельность, полиморфное поведение и спецификация алгоритма, задаются позже в процессе проектирования.
Пример спецификации операций классов
О НПрЙ^ар^Т&13ЭД^£' :^>U .
■ Обратитесь к примерам 4.9. и 4.17, а также классам Course и Courseoffering, приве- ;
I денным на рис. 4.6. Объекты этих двух классов использовались в диаграмме последова- ■ t тельностей, показанной на рис. 4.14.
; Наша задача заключается в том, чтобы получить операции на основе диаграммы после- ; довательностей и ввести их в классыCourse и Courseoffering.
Операции, заданные в расширенной модели классов на рис. 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) объектов.
Спецификация изменения состояний
Состояние объекта в определенный момент времени определяется значениями его атрибутов, включая атрибуты отношения. Спецификация состояний, помимо прочего, определяет атрибуты класса. Спецификация поведения определяет операции класса, некоторые из которых дают побочные эффекты (т.е. они изменяют состояние объекта). Однако для понимания того, каким образом объект может изменять свое состояние во времени, нам необходим более целенаправленный взгляд на систему. Подобный взгляд может обеспечить спецификация изменения состояний.
Значение спецификации изменения состояний изменяется в зависимости от области приложения. Моделирование изменения состояний для бизнес-приложений значительно менее критично, чем инженерных приложений и приложений реального времени. Многие инженерные приложения и приложения реального времени полностью определяются изменением состояний объектов. При моделировании подобных систем необходимо с первого дня сосредоточиться на изменении состояний. Что случится, если температура окажется слишком высокой? Что будет, если клапан не закроется? Что произойдет, если контейнер переполнится? И т.д.
В этом учебнике мы преимущественно сосредоточили свое внимание на бизнес- приложениях, для которых изменения состояния наблюдаются менее часто. Поэтому моделирование изменения состояний обычно осуществляется ближе к окончанию этапа анализа (и продолжается со значительно большей глубиной на этапе проекта-
рования). Многие спецификации изменения состояний определяют исключительные условия в системе. Естественно, что исключения из обычного поведения системы моделируются после спецификации нормального поведения.
Моделирование состояний объектов
Моделирование состояний объектов осуществляется с помощью диаграмм состояний. Граф состояний (автомат) — это граф состояний и переходов. Модели состояний строятся для каждого класса, проявляющего интересное для аналитика динамическое поведение. Не все классы диаграммы классов относятся к этой категории.
Диаграммы состояний можно также использовать для описания динамического поведения других моделируемых элементов, например, прецедентов, коопераций или операций. Это, однако, встречается нечасто, и некоторые CASE-средства могут не поддерживать подобные функциональные возможности.
Выявление состояний объектов
Процесс исследования состояний объектов основан на анализе содержимого атрибутов классов и выявлении того, какие из этих атрибутов представляют особый интерес с точки зрения прецедентов. Не все атрибуты влияют на изменения состояний.
Например, модификация телефонного номера клиентом не изменяет состояния объекта Customer. У клиента по-прежнему имеется телефон, а номер телефона не существенен. Однако удаление номера телефона может трактоваться как изменение состояния с точки зрения некоторых прецедентов. Больше связаться с клиентом по телефону нельзя. .
Аналогично, изменение номера телефона, которое включает изменение кода региона может представлять интерес как изменение состояния, поскольку указывает па то, что клиент сменил свое географическое местоположение, и это изменение может быть необходимо зафиксировать и отразить в диаграмме состояний.
Спецификация состояний объектов
Основные обозначения языка UML, касающиеся спецификации диаграмм состояний, были введены в разделе 2.2.6. Для успешного применения этой системы обозначений аналитик должен понимать взаимосвязи между различными понятиями, какие сочетания понятий являются неестественными или недопустимы и какие сокращения возможны в рамках предлагаемой нотации. Применение CASE-средств может быть связано с определенными ограничениями в представлении диаграмм состояний, но вполне возможны и некоторые любопытные расширения.
Переходы между состояниями активизируются при появлении определенных событий гит выполнении определенных усилий. Это означает, например, что линия перехода не нуждается в метке, указывающей гшя события. Само условие (записываемое в квадратных скобках) активизирует переход всякий раз, когда вид деятельности в состоянии завершен и условие принимает значение "истина”.
В типичной ситуации переход запускается сигнальным событием или событием вызова. Сигнальное событие устанавливает явную, асинхронную однонаправленную связь между двумя объектами. Событие вызова устанавливает синхронную связь, в которой вызывающий объект ожидает ответа. Существует еще два типа пусковых событий: событие изменения и временное событие. В частности, временное событие, запускающее переход, основано на абсолютном или относительном понятии времени и является очень полезным в некоторых моделях.
Еще одно соображение, касающееся моделирования состояний, связано с возможностью спецификации входных действий внутри пиктограммы состояния или во входящем переходе. Аналогично, выходное действие можно поместить внутри пиктограмм состояний или в исходящих переходах. Хотя это и не затрагивает семантики, выбор используемого метода может сказаться на удобстве восприятия модели [74].
Пример спецификации диаграммы состояний
^ Пример 4И 9. Магазин видеопрога .^ Пример 4И 9. Магазин видеопрога .ttebwws Л» &S* ■ м«$ttebwws Л» &S* ■ м«$
^ Пример 4И 9. Магазин видеопрога .
^ Пример 4И 9. Магазин видеопрога .
ttebwws Л» &S* ■ м«$
ttebwws Л» &S* ■ м«$
Обратитесь к примеру 4.9 и рассмотрите класс MovieTitle (рис. 4.7). Наша задача со- ? ’ стоит в спецификации диаграммы состояний для класса MovieTitle.
Диаграмма состояний для класса MovieTitle приведена на рис. 4.16. Диаграмма иллюстрирует различные способы спецификации переходов. Переходы между состояниями Available (В наличии) и Not in Stock (Нет в запасе) задают параметризованные имена событий наряду с именами действий и защитными условиями. С другой стороны, переход из состояния Reserved (Забронировано) в Not Reserved (Не забронировано) лишен явного пускового события. Этот переход запускается посредством завершения вида деятельности в состоянии Reserved, в результате которого условие отказа в бронировании [no more reserved] принимает значение “истина”.
MovieTitleMovieTitleРис. 4.16. Диаграмма состояний для класса “Movie Title” (Магазин видеопроката)Рис. 4.16. Диаграмма состояний для класса “Movie Title” (Магазин видеопроката)
MovieTitle
MovieTitle
Рис. 4.16. Диаграмма состояний для класса “Movie Title” (Магазин видеопроката)
Рис. 4.16. Диаграмма состояний для класса “Movie Title” (Магазин видеопроката)
Резюме
Эта глава является ключевой для всей книги — здесь показан UML в действии. Разбор примеров, введенных в главе 2, послужил в качестве иллюстративного материала. В дело были пущены все часто используемые UML-модели. Девиз этой главы мог бы звучать так: в сфере моделей анализа ИС однозначных решений типа “черное-белое”, “нуль-единица”, "истина-ложь" не существует. Для каждой проблемы существует множество потенциальных решений. Фокус состоит в том, чтобы придти к решению, которое удовлетворяет требованиям заказчика и способно работать.
■ Спецификация состояний описывает мир ИС со статической точки зрения классов, содержания их атрибутов и их отношений. Существует много методов выявления классов, но ни один из них не дает единого рецепта. Практическим ответом на проблему выявления классов служит комплекс методов, соответствующий знаниям и опыту аналитика. В UML классы задаются с помощью диаграмм классов. Диаграммы позволяют наглядно представить классы и три типа отношений между ними: ассоциации, агрегации и обобщения.
■ Спецификация поведения описывает мир ИС с операционной точки зрения (для того, чтобы не использовать перегруженный термин — функциональная точка зрения). Движущей силой спецификации поведения и, конечно, анализа требований и проектирования системы в целом выступают прецеденты. Диаграммы прецедентов дают только наглядное представление — истинная сила прецедентов заключается в их неформальных спецификациях. Остальные поведенческие диаграммы являются производными от моделей прецедентов. Они включают диаграммы видов деятельности, диаграммы взаимодействия и введение операций в классы.
■ Спецификации изменения состояний описывают мир ИС с динамической точки 'зрения. Объекты “бомбардируются” событиями, и некоторые из этих событий вызывают изменения состояний объектов. Диаграммы состояний позволяют моделировать изменения состояний.
Щ Вопросы
Обсудите, каким образом функциональные требования и требования к данным, выявленные на этапе установления требований, связаны с моделями состояний, поведения и изменения состояний, разрабатываемыми на этапе спецификации требований.
Приведите доводы за и против использования CASE-средств для спецификации требований.
Объясните, в чем заключаются основные различия четырех подходов к выявлению классов.
Обсудите и сравните процессы, связанные с выявлением и спецификацией атрибутов классов и операций классов. Как следует моделировать атрибуты и операции: в параллель или по отдельности? Почему?
Обратитесь к модели классов на рис. 4.7 (пример 4.10). Объясните, почему атрибут MovieTitle.is_in_stock моделируется как производный атрибут, а атрибут VideoMedium.percentage_excellent_condition — как статический.
Вб. Использование тернарных и производных ассоциаций в моделях анализа нежелательно. Почему? Приведите примеры.
Обратитесь к модели классов на рис. 4.5 (пример 4.8). Рассмотрите верхнюю часть модели, в которой определяются классы и ассоциации между классами PostalAddress,
CourierAddress, Organization и Contact. Предложите альтернативные пути моделирования этих же требований. Можно ли придать модели большую гибкость, чтобы ее можно было приспособить к возможным изменениям в требованиях? Приведите доводы за и против альтернативных решений.
Приведите примеры каждого из типов агрегаций: Безраздельно обладает. Обладает, Включает и Участник.
Обратитесь к модели классов на рис. 4.6 (пример 4.9). Объясните, как изменится семантика модели, если класс AcademicRecord, связанный с ассоциацией takes, моделировать как “ассоциацию в роли класса”?
В10. Наследование без полиморфизма возможно, но не очень полезно. Почему? Приведите примеры.
В11. Какие из моделей UML полезны при спецификации поведения? Объясните, в чем заключаются сильные стороны каждой из этих моделей и каким образом они взаимосвязаны при определении поведения системы?
В12. Объясните, в чем состоит различие прецедентов и деловых функций (или деловых транзакций)?
Приведите пример отношений «include» и «extend» между прецедентами. В чем их основное отличие?
Приведите пример класса с несколькими атрибутами. Обсудите, какие из атрибутов могут инициировать переход между состояниями, а квкие из атрибутов индифферентны к изменениям состояний?
Q] Упражнения
/> - : V ^^Й^,,., ,.. ^.-^ У'^-^-^' •:^*-»V1'^*-'<'^,Ay-^v;^"^^««►^^Ap^y-t ... »>>t . ■■ .«„.у .^ a^^i^-^-m ^ ^*«У ..<■ ^^м
Д ;ф*1Й1 NH$HISу?1 ^^
Рассмотрите следующие дополнительные требования к приложению Запись на университетские курсы.
}таточно). Студент, который не смог удовлетворительно пройти курс, может попы- -
jтаться сделать это вновь. Для записи на курс в третий раз или в случае требования
I освобождения от обязательных курсов необходимо получить согласие представите- । ля соответствующего деканата.
j 8. Если студенты записываются на те учебные курсы, которые в совокупности дают за
; год менее чем 18 условных очков, эти студенты относятся к квтегории студентов
I "вечерней” формы обучения.
• 9. Для того, чтобы получить возможность записаться на программу курсов, которые в
i данном семестре дают в совокупности более 14 условных очков, требуется специ- 1
I альное разрешение..
jI
10.3а каждым курсом обучения закреплен ответственный преподаватель, однако к нему
| могут быть привлечены дополнительные преподаватели. В каждом семестре за курс $ может отвечать другой преподаватель, а каждый курс в течение семестра могут вес- > s ти разные преподаватели.
' Рассмотрите следующие дополнительные требования к приложению Магазин видеопроката.
За кассеты и диски, возвращенные позже срока, взимается дополнительная плата за период, превышающий срок проката. Каждый видеоноситель обладает уникаль-
-, ным идентификационным номером.
2. Фильмы заказываются у поставщика, который, в общем случае, может поставить кассеты :и диски в течение одной недели. Обычно один заказ делается на несколько фильмов.
Забронировать можно те фильмы, которые заказаны у поставщика и/или все копии ■ которых находятся в прокате. Можно также забронировать те фильмы, которых нет в ; запасе и которые не заказаны у поставщика; при этом с клиента требуется задаток ; за один период проката.
Клиент может также сделать несколько предварительных заказов, однако для каждо- ; го звбронированного фильма готовится отдельный запрос на бронирование. Брони'рование может быть отменено из-за отсутствия реакции со стороны клиента, более
точно, в течение одной недели с момента, когда клиенту было сообщено о возмож
ности взять фильм напрокат. Если за фильм был уплачен задаток, он записывается • на счет клиента.
5. База данных хранит обычную информацию о поставщиках и клиентах, т.е. адреса, 1 телефонные номера и т.д. В каждом заказе поставщику указываются заказываемые фильмы, их количество, форматы кассеты/диска, а также дата ожидаемой доставки, отпускная цена, возможные скидки и т.д.
6. Когда кассета возвращается клиентом или поступает от поставщика, вначале удов- i летворяются предварительные заказы. Работники магазина устанавливают контакт с j клиентами, сделавшими предварительный заказ. Для правильной обработки брони- 5 рования фильмов информация, связанная с бронированием, обновляется дважды: (после установления контакта с клиентом, когда ему сообщается, что
“забронированный фильм пришел”, и после сдачи фильма клиенту напрокат. Эти
шаги гарантируют правильное проведение операции бронирования.
■ 7. Клиент может взять несколько кассет или дисков, однако каждому взятому видеоно- > сителю ставится в соответствие отдельная запись. Для каждого выдаваемого напро- • кат фильма фиксируются дата и время выдачи, установленный и фактический срок , возврата. Позже запись о покате обновляется, чтобы отразить факт возврата ви! деофильма и факт окончательного платежа (или возврата денег). Кроме того, запись $ хранит информацию о продавце, отвечающем за прокат фильма. Детальная инфор-
’мация о клиенте и по прокату хранится в течение года, чтобы можно было легко оп- >
;ределить уровень доверия к клиенту. Старая информация по прокату сохраняется в i
течение года в целях проведения аудита.i
; 8. Все операции выполняются с использованием наличности, электронного перевода ;
5 денег или кредитных карточек. От клиентов требуется внести плату за прокат при J
; выдаче кассет/дисков.;
', 9. Если кассета/диск возвращены позже установленного срока (или не могут быть воз- 8 , вращены по каким-либо причинам) плата снимается либо со счета клиента, либо :принимается непосредственно от клиента.
: 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.
Воспользуйтесь расширенной диаграммой последовательностей для введения новых операций в релевантные классы, включая два класса, приведенные на рис. 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, а также итеративным и наращиваемым процессом объектно-ориентированной разработки ПО.
Углубленное моделирование классов
Концепции моделирования анализа, которые рассматривались до сих пор, были достаточны для выработки завершенных моделей анализа. Однако обеспечиваемый этими концепциями уровень абстракции не исчерпывает всех возможных деталей, допустимых в рамках моделирования анализа (т.е. деталей, которые не касаются ап- паратных/программных решений, но обогащают семантику модели). UML включает нотацию для ряда дополнительных концепций, о которых мы упоминаем только вскользь или которых не касаемся вообще.
Дополнительные концепции моделирования включают стереотипы, ограничения, производную информацию, видимость, квалифицированные ассоциации, ассоциативные классы, параметризованные классы и некоторые другие. Эти концепции необязательны. Многие модели могут быть вполне приемлемы без них. Их применение требует осторожности и точности, так чтобы любой, кто попробует разобраться с моделями впоследствии, мог без труда понять намерения разработчика.
Стереотипы
Стереотип (stereotype) расширяет существующий элемент моделирования UML. Вносит некоторые изменения в семантику существующего элемента. По существу не является новым элементом моделирования и также не изменяет структуру UML, а только обогащает содержание существующей нотации. Он позволяет расширить и настроить метод. Существуют различные способы применения стереотипов.
Обычно стереотипы помечены в модели с помощью имени, заключенного в особые скобки (которые называются во французском языке guillemets и выглядят как двойные угловые кавычки), например, «global», «РК», «include» (Следует иметь в виду, что эти кавычки — один символ, а не два. Прим. ред.). Возможно также представлять стереотип с помощью пиктограммы.
Некоторые распространенные стереотипы являются встроенными— они заранее определены в UML. Некоторые CASE-средства включают готовые пиктограммы для встроенных стереотипов. Большинство CASE-средств обеспечивают возможность создания новых пиктограмм по желанию аналитика. На рис. 5.1 показан пример класса, обозначенного как стереотип с помощью пиктограммы, метки, и тот же класс, не являющийся стереотипом.
CustomerCustomer«Actor»Customer«Actor»CustomerCustomerCustomerСтереотип"пиктограмма"Стереотип"пиктограмма"Стереотип“метка"Стереотип“метка"Не стереотипНе стереотип
Customer
Customer
«Actor»Customer
«Actor»Customer
Customer
Customer
Стереотип"пиктограмма"
Стереотип"пиктограмма"
Стереотип“метка"
Стереотип“метка"
Не стереотип
Не стереотип
Рис. 5.1. Пиктограммы и метки стереотипов
Ограничение, гласящее, что стереотип расширяет семантику, но не структуру UML, довольно несущественно. Главная отличительная черта любой объектноориентированной системы заключается в том, что она полностью состоит из объектов— класс является объектом, атрибут также является объектом, метод — также объект и т.д. Следовательно, превращение класса в стереотип может привести в итоге к созданию нового элемента моделирования, который вводит новую категорию объектов.
Например, в разд. 7.6.1 и 9.2.1 показано, как можно использовать стереотипы для создания нового метода моделирования — диаграмм навигации по окнам, диаграмм навигации по программе. При использовании подобного способа стереотипы расширяют UML для конкретной цели. А цель эта зачастую состоит в том, чтобы работать моделированием проектирования, а не моделированием анализа. Модели проектирования согласуются с платформой реализации. Следовательно, они должны работать с элементами моделирования, надлежащим образом представляя эту платформу.
Целевой набор стереотипов, направленный на решение вопросов моделирования проектных решений, называется профилем (profile). В будущем стандарты UML могут включать профили для распространенных проектных решений, таких как базы данных или CORBA (Common Object Request Broker Architecture — Общая архитектура брокера объектных запросов).
Ограничения
Стереотипы часто путают с ограничениями. Конечно, иногда различие между этими двумя понятиями провести довольно трудно. Зачастую стереотип используется для введения в модель нового ограничения— того, которое имеет смысл для моделирования, но не поддерживается непосредственно в UML.
С каждым элементом моделирования может быть связано ограничение, либо он может быть превращен в стереотип. На диаграмме модели показывают только простые ограничения. Их показывают в виде текста, заключенного в фигурные скобки (или в виде символа примечания — см. разд. 5.1.3), и они графически и семантически ограничены модельным элементом. Более доскональные ограничения (слишком большие для графической модели) хранятся в репозитории CASE-системы обычно как документ, созданный некоторым текстовым процессором.
з Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Вернитесь к той части требования 2, которая ; гласит: “Все билеты пронумерованы. В рамках кампании все билеты обладают уникаль- . ными номерами."4 В решении к примеру 4.7 (рис. 4.4) мы не зафиксировали приведенное выше ограниче- ; ние (недостает включения атрибута campaign_code (вместе с ticket_number) в классз Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Вернитесь к той части требования 2, которая ; гласит: “Все билеты пронумерованы. В рамках кампании все билеты обладают уникаль- . ными номерами."4 В решении к примеру 4.7 (рис. 4.4) мы не зафиксировали приведенное выше ограниче- ; ние (недостает включения атрибута campaign_code (вместе с ticket_number) в класс- CampaignTicket как часть составного первичного ключа).
з Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Вернитесь к той части требования 2, которая ; гласит: “Все билеты пронумерованы. В рамках кампании все билеты обладают уникаль- . ными номерами."
4 В решении к примеру 4.7 (рис. 4.4) мы не зафиксировали приведенное выше ограниче- ; ние (недостает включения атрибута campaign_code (вместе с ticket_number) в класс
з Обратитесь к примеру 4.7 (разд. 4.2.1.2.3). Вернитесь к той части требования 2, которая ; гласит: “Все билеты пронумерованы. В рамках кампании все билеты обладают уникаль- . ными номерами."
4 В решении к примеру 4.7 (рис. 4.4) мы не зафиксировали приведенное выше ограниче- ; ние (недостает включения атрибута campaign_code (вместе с ticket_number) в класс
jj; Наша задача состоит в том чтобы, смоделировать ограничение на диаграмме классов.
j
j
(номера билетов ticket_number уникальны только
а рамках своей компании)
Рис. 5.2. Ограничение для класса (Телемаркетинг)
На рис. 5.2 представлено простое расширение модели классов, позволяющее показать ограничение. Ограничение связано с классом CampaignTicket. В отчете, выработанном любым CASE-средством, ограничение будет приведено вместе с другими свойствами класса.
Обратитесь к примеру 4.8 (разд. 4.2.2.3). Предположим, что было выявлено новое тре- ; бование, которое не было предусмотрено в системе: планирование мероприятий со- [
грудниками для себя. Это значит, что сотрудник, который создал мероприятие ; (Employee. created), не должен быть тем же сотрудником, который отвечает за выпол- 1 нение мероприятия (Employee. due). > Расширьте соответствующую часть модели классов (рис. 4.5) таким образом, чтобы • включить новое требование. "
Решение для этого примера (рис. 5.3) имеет своим результатом ограничение на ассоциативные связи, что показано в виде прерывистой стрелки-указателя зависимости, проведенной от ассоциации created к ассоциации due. Ограничение привязано к стрелке.
createdcreatedcompletedcompletedРис. 5.3. Ограничение на ассоциации (Управление контактами с клиентами)Рис. 5.3. Ограничение на ассоциации (Управление контактами с клиентами)
created
created
completed
completed
Рис. 5.3. Ограничение на ассоциации (Управление контактами с клиентами)
Рис. 5.3. Ограничение на ассоциации (Управление контактами с клиентами)
Примечания и дескрипторы
Если описание ограничения слишком длинно или же ограничение должно быть выражено с использованием трех или более графических символов, можно воспользоваться таким понятием UML, как примечание (note). Графически “примечание представляет собой прямоугольник с загнутым правым верхним краем” [76].
Символ примечания может содержать текст для выражения ограничения, однако, в общем случае, он может содержать любую информацию. Чтобы показать, что примечание является ограничением, его необходимо дополнительно обозначить как стереотип с помощью ключевого слова «constraint».
Подобно примечаниям, дескрипторы (tag) представляют произвольную текстовую информацию в модели, в том числе, ограничения. Аналогично ограничениям дескрипторы записываются внутри фигурных скобок и принимают следующий вид
tag - значение,например:
(author = lea, status = 2nd iteration).
Аналогично стереотипам и ограничениям некоторые дескрипторы предопределены в UML. Обычно дескрипторы используются для отображения информации по управлению проектом.
! Обратитесь к примеру 4.8 (разд. 4.2.2.3) и приведенному выше примеру 5.2. Предполо- | жим, что было выявлено новое требование, которое не было предусмотрено в системе: * сотрудник, который создал задание, должен также создать — в этой же транзакции —- : первое мероприятие для этого задания.
; Расширьте соответствующую часть модели классов (рис. 4.5 и 5.3) таким образом, чтобы : аключить новое требование. Используйте примечание ограничения. Также отобразите на диаграмме информацию о том, что аналитик, разработавший диаграмму — les (вероятно,
i подразумевается автор — Лешек), а диаграмма представляет собой вторую итерацию.
На рис. 5.4 показана расширенная модель. Для представления информации по проекту используется дескриптор в левом верхнем углу диаграммы. Для представления ограничения на трех ассоциациях используется примечание. Примечание обозначено как стереотип с помощью слова «constraint», чтобы подтвердить, что примечание — это ограничение.
completedcompletedРис. 5.4. Примечание и дескриптор как ограничения (Управление контактами с клиентами)Рис. 5.4. Примечание и дескриптор как ограничения (Управление контактами с клиентами)
completed
completed
Рис. 5.4. Примечание и дескриптор как ограничения (Управление контактами с клиентами)
Рис. 5.4. Примечание и дескриптор как ограничения (Управление контактами с клиентами)
Видимость и инкапсуляция
Концепция видимости (visibility) и связанное с ней понятие инкапсуляции (encapsulation) были впервые рассмотрены в разд. 2.1.2.1.2 и 2.1.2.2.2. При этом было только обозначено различие между открытой и закрытой видимостью атрибутов и операций. Третий предопределенный в UML тип видимости — защищенная (protected) — не рассматривался.
Точно так же не рассматривались различные тонкие взаимные влияния между видимостью и наследованием. Кроме того, не были рассмотрены популярные и удобные (кое-кто может возразить — неудобные) методы преодоления инкапсуляции объектов с помощью дружественных операций.
В UML в качестве стандартных обозначений видимости приняты следующие знаки: + (для открытой), # (для защищенной ) и - (для закрытой) видимости. Знаки помещаются перед именем свойства. CASE-средства часто заменяют эти довольно тусклые обозначения. На рис. 5.5 приведен пример более привлекательной нотации.
Visibility ~Blprivate|protected|MpublicQprivateOMore cted()j|publlc()
Puc. 5.5. Обозначение видимости с помощью CASE-средства
Защищенная видимость
Ситуация, при которой закрытые свойства (атрибуты и операции) базового класса доступны только объектам базового класса, иногда связана с неудобствами. Во многих случаях объектам производного класса (подкласса базового класса) необходимо разрешить доступ к закрытым свойствам базового класса.
Рассмотрим иерархию классов, где Person— это базовый класс, a Employee — производный класс. Если Joe — объект класса Employee, то — по определению обобщения — Joe должен иметь доступ к свойствам (по меньшей мере к некоторым атрибутам) класса Person (например, к такому как дата рождения — date_of_birth).
Чтобы дать возможность производному классу осуществлять свободный доступ к свойствам его базового класса, эти (в противном случае — закрытые) свойства необходимо определить в базовом классе как защищенные (protected). (Вспомним из разд. 2.1.2.1.2, что видимость применяется по отношению к классам. Если Betty — еще один объект класса Employee, то он должен иметь доступ к любому свойству Joe: открытому, защищенному или закрытому.)
Подобный сценарий справедлив для большинства известных объектноориентированных сред программирования, примерами могут служить C++ и Java [25]. Язык UML не составляет исключения в этом вопросе. Здесь просто утверждается: “Видимость является частью отношения между элементом и содержащим его контейнером. Контейнер может быть пакетом, классом или другим представителем пространства имен” [76].
| Обратитесь к постановке задачи 4 (разд. 2.3.4) и примеру 4.7 (разд. 4.2.1.2.3). Поста! новка задачи содержит следующее замечание: “Эти схемы включают специальные при- I зовые кампании для вознаграждения приверженцев, закупающих лотерейные билеты в ' массовом количестве, для привлечения новых жертвователей и т.д.”. Это замечание
еще не нашло отражения а модели.
Предположим, что одна из призовых кампаний включает “билетные книжки": если бла- j готворитель покупает целую книжку билетов, ему бесплатно вручается дополнительный | билет основной кампании.
| Наша задача состоит в выполнении следующих действий. '
| ■ Обновить модель класса, включив в нее класс BonusCampaign.
- ■ Изменить видимость атрибутов класса Campaign (рис. 5.2) таким образом, чтобы они > были видимы классу BonusCampaign за исключением атрибута date_start. Сделать ат- । рибуты campaign_code и campaign_title видимыми для остальных классов модели.
I ■ Добавить в класс Campaign следующие вычислительные операции: computeTicketsSold | (проданные билеты), computeTicketsLeft (остаток билетов), computeDuration, I(продолжительность [кампании]), computeDaysLeft (оставшиеся дни).|
i ■ Осознать, что у внешних классов нет нужды в атрибуте computeTicketsSold. Им тре- j i буется знать только атрибут computeTicketsLeft. Кроме того, computeDuration ис- । |пользуется только операцией Campaign.computeDaysLeft.I
J ■ Класс BonusCampaign хранит атрибут ticket_book_size (величина билетной книжки), а ; $операция доступа к нему называется booksize.{
Рис. 5.6. Видимость свойств класса (Телемаркетинг)Рис. 5.6. Видимость свойств класса (Телемаркетинг)
Рис. 5.6. Видимость свойств класса (Телемаркетинг)
Рис. 5.6. Видимость свойств класса (Телемаркетинг)
На рис. 5.6 показана модель классов, соответствующая приведенному выше пояснению. Стереотип «protected» на линии обобщения рассматривается в следующем разделе. Операция computeTicketsSold в классе Campaign является закрытой. Операция computeDuration в классе Campaign является защищенной. Остальные две операции в классе Campaign — открытые. Операция bookSize специфична для класса BonusCampaign и является открытой.
Видимость унаследованных свойств классов
Как декларируется в UML, характеристика видимости применяется к объектам на различных уровнях детализации. Обычно имеется в виду, что видимость применяется к эммента^тым объектам — атрибутам и операциям. Однако видимость можно задать и по отношению к другим “контейнерам". Это приводит к полной неразберихе с правилами замещения.•
Рассмотрим, к примеру, распространенную ситуацию, когда видимость определяется в иерархии наследования на уровне базового класса и на уровне свойств базового класса. Пусть, скажем, класс В — подкласс класса А. Класс А содержит смесь атрибутов и операций — некоторые из них являются открытыми, другие — закрытыми, а остальные — защищенными. Вопрос звучит так: “К какому типу видимости относятся унаследованные свойства в классе В?”
Ответ на этот вопрос зависит от уровня видимости, установленного базовому классу А при объявлении его в производном классе В. Базовый класс можно объявить открытым (class В: public А), защищенным (class В: protected А) или закрытым (class В: private А).
Типичное разрешение приведенного выше сценария выглядит следующим образом [38].
Закрытые (private) свойства (атрибуты и операции) базового класса А не видимы для объектов класса В вне зависимости от того, как базовый класс определен в В.
Если базовый класс А определен как public, видимость унаследованных свойств в производном классе В не изменяется (открытые (public) остаются открытыми, а защищенные (protected) — защищенными).
Если базовый класс А определен как protected, видимость унаследованных свойств в производном классе В изменяется на protected.
Если базовый класс А определен как private, видимость унаследованных свойств с типом видимости public и protected в производном классе В изменяется на private.
| Обратитесь к приведенному выше примеру 5.4. Предположим, что стереотип I «protected» на линии обобщения означает, что класс Campaign определен в
г Bonuscampaign как защищенный:
] class BonusCampaign: protected Campaign
= Определите уровень видимости свойств унаследованного класса в классе
| Bonuscampaign. Поясните ваше решение.
Если базовый класс определен как защищенный (protected), его открытые (public) свойства в производном классе изменятся на защищенные. Защищенные свойства останутся защищенными. Закрытые свойства не будут доступны производному классу (они никогда не доступны).
На рис. 5.7 и 5.8 представлены диалоговые окна CASE-репозитория, которые, соответственно, отображают атрибуты и операции класса Bonuscampaign после вступления в силу эффекта наследования.
Рис. 5.7. Унаследованные атрибуты в классе BonusCampaign (Телемаркетинг)
Рис. 5.8. Унаследованные операции в классе BonusCampaign (Телемаркетинг)
Дружественные классы и операции
В некоторых случаях функции (или даже классу в целом) требуется предоставить непосредственный доступ к свойствам другого класса независимо от уровней видимости этих свойств. Подобная ситуация возникает, когда два класса тесно связаны и операции одного из классов зависят от свойств другого класса. В качестве типичного примера можно привести два класса: 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, которая устанавливает, остались ли какие-то билеты, чтобы заказ ’ « благотворителя мог быть удовлетворен. Существенно, что этв операция имеет прямой i I доступ к свойствам класса Campaign (таким как num_tickets и num_tickets_sold). ; ) Наша задача состоит в том, чтобы объявить операцию getTicketsbeft дружественной | J к классу Campaign. ,
Решение в терминах UML для нашего примера показано на рис. 5.9. Операция getTicketsbeft расположена внутри класса CallScheduled. Напомним, что в языке программирования, используемом для реализации, операция getTicketsbeft объявляется дружественной внутри класса Campaign (поскольку именно класс Campaign определяет, кто будет другом), азатем полностью определяется в классе CallScheduled
Отношение зависимости фиксирует тот факт, что класс Campaign предоставляет некоторый дружественный статус классу CallScheduled. Из нотации не совсем ясно, распространяется ли дружественный статус на весь класс или на некоторые операции класса (и на какие именно).
Рис. 5.9. Дружественность (Телемаркетинг)
Производная информация
Производная информация (derived information) представляет собой разновидность ограничения, которое наиболее часто применяется к атрибуту или ассоциации. Производная информация вычисляется на основе других элементов модели. Строго говоря, производная информация является избыточной — при необходимости ее можно вычислять.
Хотя производная информация не обогащает семантику модели анализа, она придает модели большую четкость (поскольку в модели явно находит отражение факт возможности вычисления некоторой величины). Решение о том, приводить или нет в модели анализа производную информацию, довольно произвольно и должно последовательно распространяться на модель в целом.
Владение производной информацией имеет большее значение для проектных моделей, в которых требуется учет возможностей оптимизации доступа к информации. Применительно к проектным моделям можно также принять решение о том, хранить ли производную информацию (после ее вычисления) или же динамически вычислять ее каждый раз, когда в ней возникает необходимость. Это не новое свойство— в прежних сетевых базах данных оно было известно как актуальные (т.е. хранимые) или виртуальные данные.
В языке UML производная информация обозначается с помощью символа косой черты (/), помещенного перед именем производного атрибута или ассоциации.
Производный атрибут
Мы уже использовали производные атрибуты ранее в нескольких примерах диаграмм, правда, не приводя никаких объяснений. Например, атрибут num_tickets_sold на рис. 5.2— производный. Расширенная диаграмма для этого рисунка показана ниже (рис. 5.10).
Значение атрибута num_tickets_sold вычисляется с помощью операции computeTicketsSold. Выполнение операции следует агрегативной связи с классом CampaignTicket (Билеты, используемые в кампании) и проверяет статус каждого билета— ticket status. Если статус билета— ticket status — принимает значение “продан", то к счетчику проданных билетов прибавляется единица. После обработки всех билетов выводится текущее значение количества проданных билетов num_tiсkets_sо1d.
{номера билетов ticket_number уникальны только
в рамках своей компании}
Рис. 5.10. Производный атрибут (Телемаркетинг)
Производная ассоциация
Производная ассоциация — более спорная тема. Типичным случаем производной ассоциации можно считать ассоциацию, образованную тремя классами, уже соединенными двумя ассоциациями, при этом третья ассоциативная связь замыкает контур. Зачастую необходимость в третьей ассоциации возникает в связи с требованием семантической корректности модели (это известно как коммутативность контура). Если
третья ассоциация не представлена в модели явно, она может быть выведена из двух других ассоциативных связей.
> Обратитесь к наставлению по Internet-магазину в главе 2 и к диаграмме классов на ; рис. 2.32 (разд. 2.2.4.6). Рассмотрите часть модели, включающую классы Customer, • order и Invoice.
Существует ли возможность ввести производную ассоциацию в модель? Если да, то до- ( бавьте ее к диаграмме.
Да, между классами Customer и Invoice возможно ввести производную ассоциацию. На приведенном ниже рис. 5.11 она обозначена именем /Custlnv. Эта ассоциация выводится, благодаря слегка необычному бизнес-правилу, по которому кратность ассоциации между классами Order и Invoice равна “один к одному".
Рис. 5.11. Производная ассоциация (Internet-магазин)
Производная ассоциация не вносит в модель какой-либо новой информации. Всегда можно связать клиента (Customer) с определенным заказом (Order), отыскав один заказ для каждой счет-фактуры (Invoice), азатем одного клиента для каждого заказа.
Квалифицированная ассоциация
К концепции квалифицированной ассоциации (qualified association) в среде специалистов по моделированию относятся по-разному. Некоторые охотно пользуются этим понятием, другие не воспринимают его вовсе. Можно ли построить полную и достаточно выразительную модель классов без использования квалифицированной ассо-
циации — вопрос спорный. Однако если уж квалифицированная ассоциация используется, то использовать ее при построении моделей классов следует последовательно.
По одну сторону линии бинарной квалифицированной ассоциативной связи имеется “отделение” для атрибута (квалификатора (qualifier)) (ассоциация может быть квалифицирована по обоим концам связи, но это довольно редкий случай). Это "отделение” содержит один или более атрибутов, которые служат в качестве ключа индекса для прослеживания ассоциативной связи от квалифицируюгцего класса (qualified class) посредством квалификатора до целевого класса (target class) на противоположном конце ассоциации.
Например, ассоциация между классами Flight (Рейс) и Passenger (Пассажир) имеет кратность “многие ко многим”. Однако, если класс Flight квалифицировать с помощью атрибутов seat_nuiriber (место) и departure (отправление), то кратность ассоциации снижается до значения “один к одному" (рис. 5.12). Составной ключ индекса, введенный с помощью квалификатора (flight_number + seat_number + departure), может быть связан только с одним объектом Passenger либо не связан вообще ни с одним объектом этого класса.
Рис. 5.12. Квалифицированная ассоциация
При прослеживании связи в прямом направлении кратность ассоциации представляет количество целевых объектов, связанных с составным ключом (квалифицированный объект + значение квалификатора). При прослеживании связи в обратном направлении кратность ассоциации описывает количество объектов, обозначенных составным ключом (квалифицированный объект + значение квалификатора) и связанных с каждым целевым объектом [76].
Уникальность в идентификации объектов, вводимая за счет использования квалификаторов, зачастую представляет собой важную семантическую информацию, которую невозможно эффективно получить другими способами (такими как ограничение или добавление дополнительных атрибутов в целевой класс). В общем случае дублировать атрибут квалификации в целевом классе нежелательно.
’ Обратитесь к наставлению по lntemet-магазину в главе 2 и к диаграмме классов на рис. 2.32 ; (разд. 2.2.4.6). Рассмотрите часть модели, включающую классы Order и Computer.;
Измените ассоциацию между классами Order и computer на составную ассоциацию I для явного представления ограничения: “в каждом заказе на компьютер отводится одна ; позиция заказа".f
Как мы помним, компьютер заказывается после того, как клиент составит спецификацию на него. Каждая такая конфигурация может быть обозначена уникальным номером. Стандартной конфигурации также можно присвоить уникальный номер. Поэтом}' атрибут номера конфигурации configuration_number представляет собой квалификатор для объекта-заказа Order. Составной ключ (order_number + configuration_number) связывает заказсодним объектом Computer (рис. 5.13).
Order border number: String border date: Date Uship address: String jrdertotal: Currency Blorder status: String ^salesperson name: String
| configurationjd: Integer]
. 1
Computer ,
Blcomputer name: String
■getConf()
Puc. 5.13. Квалифицированная ассоциация Цп1етеЬмагазин)
Ассоциативный класс или материализованный класс
В разделе 2.1.3.4 мы рассмотрели и привели пример ассоциативного класса— ассоциации, которая сама является классом. Ассоциативный класс обычно используется в тех случаях, когда между двумя классами существует ассоциация “многие ко многим” и каждый экземпляр ассоциации (связь) обладает собственными значениями атрибутов. Чтобы обеспечить возможность хранить эти атрибуты, требуется класс — ассоциативный класс.
На первый взгляд простая концепция ассоциативного класса таит в себе хитрое ограничение. Рассмотрим ассоциативный класс С между классами А и В. Ограничение состоит в том, что для каждой пары связанных экземпляров классов А и В может существовать только один экземпляр класса С.
Если подобное ограничение неприемлемо, специалист по моделированию должен материализовать ассоциацию, заменив класс С обычным классом D [76]. Материализм ванный класс [reified class') D допускает две бинарные ассоциации с классами А и В. Класс D не зависит от классов А и В. Каждый экземпляр D обладает своей собственной идентичностью, так что при необходимости можно создать несколько экземпляров этого класса для того, чтобы установить связь между одними и теми же экземплярами классов А и В.
Постановка задачи для примера с базой данных сотрудников
Для объяснения различий между ассоциативным классом и материализованным классом нам потребуется специальный пример. Пример касается ведения учета текущей и прошлой зарплаты сотрудников. Конечно, различия между ассоциативным классом и материализованным классом чаще всего проявляются в контексте моделирования временной (хронологической) информации.
Каждому сотруднику в организации присвоен уникальный идентификатор emp_id. Имя сотрудника хранится в виде имени, фамилии и инициалов второго имени.
Каждому сотруднику в штатном расписании определен уровень его заработной платы. Для каждого уровня существуют вилки окладов, т.е. минимальная и максимальная зарплата. Вилки окладов для данного уроаня никогда не изменяются. Если возникает необ- t ходимость изменить минимальную или максимальную зарплату, создается новый уро- ! вень зарплаты. Кроме того, в организации хранятся начальная и конечная даты введения Г каждого уровня зарплаты.|
В организации хранятся все предыдущие значения зарплаты сотрудника, включая на- i чальную и конечную даты установления ему определенного уровня зарплаты. Любые ; изменения зарплаты сотрудника в рамках одного и того же уровня также фиксируются. [
Модель, использующая ассоциативный класс
При порождении объектов ассоциативного класса им — подобно объектам любого обычного класса— присваиваются уникальные идентификаторы (OID) (разд. 2.1.1.3). Помимо системных OID объекты можно также идентифицировать по значениям их атрибутов. В случае ассоциативного класса источником идентичности объекта являются атрибуты, которые обозначают ассоциированные классы (разд. 2.1.2.1.1). Значения других атрибутов не способствуют идентификации объекта.
Обратитесь к приведенной выше постановке задачи для примера База данных сотруд- ; ников. Постройте для нее модель классов. Используйте при этом ассоциативный класс, j
Рис. 5.14. Неадекватное использование ассоциативного класса (База данных сотрудников)
Постановка задачи для примера создает некоторые проблемы. Мы знаем, что нам требуется класс для хранения подробной информации о сотруднике (Employee), а также класс для хранения информации об уровнях зарплаты (SalaryLevel). Про-
блема состоит моделировании текущих назначений зарплаты работникам, а также хронологии этих назначений. На первый взгляд кажется естественным использовать ассоциативный класс SalaryHistoryAssociation.
На рис. 5.14 представлена модель классов, в которой использован ассоциативный класс SalaryHistoryAssociation. Подобное решение неадекватно. Идентичность объектов SalaryHistoryAssociation выводится на основании составного ключа, созданного с использованием ссылок на первичные ключи классов Employee и SalaryLevel (т.е. emp_idH level_id).
Никакие два объекта SalaryHistoryAssociation не могут иметь одинаковых составных ключей (т.е. одинаковых связей с объектами Employee и SalaryLevel). Это также означает, что проект диаграммы на рис. 5.14 не обеспечивает выполнение требования "Любые изменения зарплаты сотрудника в рамках одного и того же уровня также фиксируются”. Решение, показанное на рис. 5.14, не может рассматриваться как удовлетворительное— требуется более корректная модель.
Модель, использующая материализованный класс
Ассоциативный класс не может иметь дублирующихся ссылок на объекты ассоциированных классов. Материализованный класс независим от ассоциированных классов, и подобное ограничение на него не распространяется. Первичный ключ материализованного класса не использует атрибутов, обозначающих связанные классы.
Рис. 5.15. Лучшее решение на основе материализованного класса (База данных сотрудников)
Иерархия классов
Разработчики ПО знают, что трудность разработки небольшой системы не идет ни в какое сравнение с трудностью поставки крупномасштабного решения. Небольшие объектные системы зачастую легче понять, реализовать и развернуть. Для масштабных объектных решений характерны сложные сетевые структуры объектов, реагирующих на случайные события, которые вызывают переплетающиеся цепочки взаимосвязанных операций (методов). В отсутствие четкого архитектурного проекта и строго определенного процесса разработки крупные программные проекты вполне могут завершиться провалом.
Хорошо известный принцип когнитивной психологии — правило 7±2— гласит, что кратковременная память человеческого мозга может одновременно справиться приблизительно с девятью (7±2) предметами (графическими элементами, идеями, понятиями и т.д.). Нижняя граница, равная пяти (7-2), указывает на то, что работа, менее чем с пятью предметами, составляет тривиальную проблему.
Правила когнитивной психологии не в состоянии повлиять на тот факт, что нам необходимы большие системы, а большие системы сложны. Значительная часть этой сложности привнесена человеком, а не присуща самой системе (разд. 1.1.1).
Главным виновником тут выступает системное моделирование, которое допускает неограниченное взаимодействие объектов. В подобных системах объекты образуют сетевые структуры — “паутину” объектов, образованную перекрестными ссылками. Эти ссылки образуют пути передачи сообщений. Возможны обращения к нижележащим и вышележащим объектам. В сетевых структурах количество возможных путей взаимодействия между объектами с появлением в системе новых объектов растет экспоненциально. Как замечает Шиперски (Szyperski): “...объектные ссылки порождают связи над произвольными областями абстракции. Поэтому верный выбор уровней применительно к системной архитектуре становится проблематичным, если вообще возможным" [88].
Удачные системы организованы по иерархическому принципу — при этом сетевые структуры оказываются ограниченными и тщательно контролируются. Применение иерархических структур позволяет снизить степень сложности с экспоненциальной до полиномиальной. Они вносят в систему уровни (или слои) объектов и ограничивают взаимодействие между уровнями. В типичной иерархии непосредственно взаимодействуют только объекты соседних уровней. Таким образом удается скрыть сложность и разнести ее по разным уровням.
Сложность сетевых структур
Прежде чем приступить к рассмотрению сложности объектных систем, необходимо договориться о мере этой сложности. Как измерить сложность? Сложность разнообразна и принимает разные формы. Простой, но очень показательной мерой сложности может выступать количество соединений между классами. Соединение (connection) определяется как существование постоянной или временной связи между классами (разд. 2.1.1.3).
Каждое соединение обычно допускает двунаправленное взаимодействие классов, т.е. от А к В и от В к А. Рис. 5.16 иллюстрирует сложность сети, состоящей из семи классов. Между п классами существует п(п-1)/2 возможных соединений. Применение этой формулы к нашему случаю дает в итоге 21 соединение (42 пути взаимодействия).
Обратите внимание, что сложность измерялась по отношению к классам, а не объектам. В программах именно объекты, а не классы, пересылают сообщения другим объектам того же или другого класса. Это создает для программиста, ответственного за разработку логики программы и управление программными переменными и другими структурами, дополнительные трудности. Однако основная проблема заключается не в сложности отдельной программы, а в сложности всей системы программ.
Объект может отправить сообщение другому объекту лишь при наличии между ними постоянной или временной связи. Временные связи разрешаются в пределах однократного вызова программы, и поэтому они не усложняют систему в целом. С другой стороны, постоянные связи существуют только при наличии соединения (например, ассоциации), определенного в модели классов. Классы могут совместно и многократно использоваться во многих программах.
Рис. 5.16. Сложность сетевых структур
Сложность иерархических структур
Решение проблемы управления сложностью состоит в редукции сетевой структуры за счет группирования классов в виде иерархии классов. При этом подходе классы могут естественным образом упорядочиваться в виде уровней, которые подчеркивают иерархическое разбиение между уровнями, делая в то же время возможным взаимодействие внутри уровней наподобие сетевого.
Разделение на уровни иерархии дает возможность снизить сложность за счет ограничения количества возможных путей взаимодействия между объектами. Это снижение сложности достигается посредством разделения классов на уровни и разрешения непосредственного взаимодействия классов внутри уровня и между соседними уровнями.
Рис. 5.17 иллюстрирует сложность иерархии, составленной из семи классов, при этом классы сгруппированы в четыре уровня. По сравнению с сетевой структурой, показанной на рис. 5.16, сложность понизилась с 42 до 26 путей взаимодействия.
Пример на рис. 5.17 придуман в соответствии с четырьмя уровнями, предлагаемыми в нашем подходе BCDE, который рассматривается в разд.6.1.3.2. В иерархической структуре с большим количеством классов количество межуровневых соединений может вызывать затруднения. Для уменьшения сложности межуровневых соединений межу-
ровневые взаимодействия могут быть направлены через несколько специально предназначенных для этого классов-посредников. Это в еще большей степени снижает общую сложность системы.
Рис. 5.17. Сложность иерархических структур
Пакеты
Для представления групп классов (или других элементов моделирования, например, прецедентов) в языке UML предусмотрено понятие пакета (package) [76]. Пакеты служат для разделения логической модели прикладной программы. Они представляют собой кластеры (блоки) сильносвязанных классов, которые сами образуют некое единое целое, но слабо связаны с другими подобными кластерами [48].
Пакеты могут быть вложенными. Это позволяет осуществлять декомпозицию больших систем на подсистемы, модули и т.д. Например, пакет, обозначенный как стереотип «system», может содержать пакеты, обозначенные в виде стереотипа «subsystem». Внешний пакет обладает доступом к любому классу, который непосредственно содержится в его вложенных пакетах.
Классом может владеть только один пакет. Это не препятствует появлению класса в других пакетах или взаимодействию с классами в других пакетах. Используя объявление класса внутри пакета как закрытого, защищенного или открытого, можно контролировать взаимодействие и зависимости между классами в разных пакетах (разд.5.1.4).
Обозначение пакетов
Пакет изображается в виде пиктограммы папки (рис. 5.18). Вложенные пакеты изображаются внутри внешнего пакета. Для каждого пакета должна быть построена собственная диаграмма классов, определяющая все классы, принадлежащие пакету.
Пакеты могут быть связаны с двумя типами отношений: обобщением и зависимостью. В качестве отношения на рис. 5.18 показана зависимость. Из рисунка видно, что пакет NestedPackage зависит от пакета Package2. Точный характер зависимости не задается, за исключением, скажем, ситуации, когда изменения для Package2 могут потре-
бовать внесения изменений в пакет NestedPackage. Пожалуй, наиболее часто зависимость между пакетами обусловлена тем, что класс одного из пакетов отправляет сообщение классу другого пакета.
Рис. 5.18. Пакеты и зависимости
В языке UML определено несколько разных категорий отношения зависимости (например, зависимость по использованию, зависимость по доступу, зависимость по видимости). Мы считаем, что определение категории зависимости не приносит большой пользы для диаграмм анализа. Истинный характер каждой зависимости должен быть зафиксирован как описательное ограничение в CASE-репозитории для использования в проектных моделях.
Обратите внимание, что отношение обобщения между пакетами предполагает также зависимость. Эта зависимость направлена от пакета подтипа к пакету супертипа. Изменения в пакете супертипа вызывают изменения в пакете подтипа.
Диаграммы пакетов
Понятия диаграммы пакетов как таковой в UML не существует, тем не менее этот термин удобен для использования. Пакеты создаются в диаграмме классов или диаграмме прецедентов. В первом случае диаграмма пакетов представляет модель системы с точки зрения ее состояний. Во втором случае — с точки зрения поведения системы. После того, как пакет создан, назначение классов (или прецедентов) пакету должно быть предусмотрено в отдельной диаграмме классов (или диаграмме прецедентов).
Без сомнения, диаграмма пакетов для состояний описывает архитектурную основу системы. Поведенческая диаграмма пакетов служит только в качестве описания высокоуровневой функциональной структуры [15]. Диаграмма пакетов для состояний помогает в управлении масштабами и сложностью системы. Она также играет важную роль в качестве механизма доступа и конфигурационного управления, способствующего сотрудничеству разработчиков. /
На рис. 5.19 показаны три пакета и Отношения зависимости между ними. Пакет Enrolment зависит от пакетов Marking и Timetable.
Г?Г?
Г?
Г?
Более пристальный взгляд на приложение Запись на университетские курсы показывает, что система должна быть "осведомлена" о расписании занятий и степенях студентов, чтобы иметь возможность проверить обоснованность записи студентов в группы.
Нам неизвестно, существуют ли “расписание" (“marking") и "выставление оценок” (“timetable") в качестве отдельных программных модулей, в которые может быть помещена наша система записи на курсы. Если это не так, то система записи на курсы должна включать подобные модули.
Наша задача состоит в том, чтобы построить модель пакетов для приложения Запись на университетские курсы.
Рис. 5.19. Пакеты (Запись на университетские курсы)Рис. 5.19. Пакеты (Запись на университетские курсы)
Рис. 5.19. Пакеты (Запись на университетские курсы)
Рис. 5.19. Пакеты (Запись на университетские курсы)
Подход ВСЕ
Подход ВСЕ (Boundary-Control-Entity — граница-управление-сущность) представляет собой подход к объектному моделированию, основанный на трехфакторном представлении классов. Подходу ВСЕ до некоторой степени можно сопоставить хорошо известный подход MVC (Model-View-Controller— модель-представление- контроллер) [14], [И], [59]. В языке UML на классах предопределены три стереотипа: boundary (граница), control (управление) и entity (сущность) [76]. Это и определи ло выбор аббревиатуры ВСЕ.
Пограничные классы (boundary class') описывают объекты, которые представляют интерфейс между субъектом и системой. Они выделяют часть состояния системы и представляют ее пользователю в форме визуального отображения или звукового эффекта. Пограничные объекты часто сохраняются после однократного выполнения программы.
Управляющие классы (control class') описывают объекты, которые перехватывают входные события, инициированные пользователем, и контролируют выполнение бизнес-процесса. Управляющий класс представляет действия и виды деятельности прецедентов. Управляющие объекты зачастую не сохраняются После выполнения программы.
Классы-сущности (entity class') описывают объекты, которые представляют семантику сущностей, принадлежащих проблемной области. Они соотносятся со структурами данных системной базы данных. Объекты-сущности всегда сохраняются после выполнения программы и участвуют во многих прецедентах.
Как показано на рис. 5.20, в верно спроектированной иерархии пакетов субъект может взаимодействовать только с пограничными объектами из пакета Boundarypackage, объекты-сущности из пакета Entitypackage могут взаимодействовать только с управляющими объектами из ControlPackage и управляющие объекты из ControlPackage могут взаимодействовать со объектами любого типа [ 15].
Рис. 5.20. Соединение объектов в иерархии пакетов ВСЕ
Пограничные классы соответствуют классам, представленным в разработанном GUI-интерфейсе. Пограничные объекты зависят от объектов-сущностей (через некоторые управляющие объекты). Объекты-сущности распространяют изменения на свои состояния, так что пограничные объекты могут обновить отображение GUI- интерфейса. Говорят, что “пограничный слой” (экран) поврежден, если он временно не синхронизирован с состоянием соответствующих сущностей проблемой области.
Управляющие объекты манипулируют взаимодействиями между событиями, инициированными пользователями, и воздействуют на объекты-сущности и пограничные объекты. В частности, каждому пограничному объекту, который допускает взаимодействие, должен быть поставлен в соответствие связанный с ним управляющий объект. Поэтому некоторые типы архитектуры ПО объединяют две функции в одном классе. В качестве примера можно привести библиотеку MFC (Microsoft Foundation Classes— библиотека базовых классов Microsoft).
Подход ВСЕ— это “способ мышления”, который воплощает в себе лучшие достижения практики разработки ПО. Поэтому он должен быть составной частью любого объектно-ориентированного метода разработки приложений вне зависимости от того, подкрепляется ли он базовой платформой реализации.
• Основным преимуществом подхода ВСЕ является группирование классов в виде иерархических уровней. Это способствует лучшему пониманию модели и уменьшает ее сложность. Это также позволяет снизить риск создания классов, которые берут на себя слишком много функций, классов-“монстров”, контролирующих работу всей системы. Хороший объектно-ориентированный проект отличает равномерное распределение “системного интеллекта” по всем классам.
: Дополнительным преимуществом подхода ВСЕ является его увязка с трехзвенной моделью клиент/сервер, которая отделяет управление данными (объекты-сущности) от представл. ния (пограничные объекты) посредством промежуточного слоя логики приложения (управляющие объекты). Сервер баз данных может даже быть реализован не на объектно-ориентированной, а на реляционной СУБД.
Следует, однако, подчеркнуть, что пакет EntityPackage описывает классы- сущности, которые располагаются в памяти клиентской программы, а не на сервере ба-
зы данных. Затем постоянные бизнес-объекты запоминаются в виде записей реляционных таблиц. Чтобы осуществить отображение классов-сущностей в реляционную память СУБД и для хранения другой релевантной информации о структурах баз данных, требуется отдельный уровень (слой) классов, которые организованы в виде пакета, предназначенного для работы с базой данных — DatabasePackage (разд.6.1.3.2).
Углубленное моделирование обобщения и наследования
Существует три основных вида отношений между классами: ассоциация, агрегация и обобщение. Внимательный читатель мог заметить, что полезность обобщения для моделей анализа была подвергнута сомнению. Обобщение— полезная и мощная концепция, однако, она также может стать источником множества проблем из-за сложности механизмов наследования, в частности, в крупных программных проектах.
Понятия обобщения и наследования связаны, но не идентичны. Важно понимать разницу между ними. Ценой неточности в определении этих понятий является часто явно демонстрируемое в литературе недопонимание их различия. Конечно, до тех пор, пока это различие не осознано, легко впасть в бессмысленную и безосновательную дискуссию, касающуюся доводов за и против обобщения и наследования.
Обобщение— это семантическое отношение между классами. Оно устанавливает, что интерфейс подкласса должен включать все (открытые и защищенные) свойства суперкласса. Наследование— это “механизм, с помощью которого более специфические элементы вбирают в себя структуру и поведение, определенные более общими элементами” [76].
Обобщение и подставимость
С точки зрения семантики моделирования обобщение вводит в модель дополнительные классы, разделяет их на общие и более специфические классы и устанавливает отношения суперкласс-подкласс. Хотя обобщение и вводит новые классы, оно может уменьшить общее количество отношений ассоциации и агрегации в модели.
Исходя из требуемой семантики, ассоциативная или агрегативная связь класса может указывать на наиболее общий класс иерархии обобщения (см. диаграммы классов на рис. 2.31 и 4.7). Поскольку подкласс может быть подставлен вместо его родительского класса, объекты подкласса связаны всеми отношениями ассоциации и агрегации суперкласса. Это позволяет зафиксировать ту же семантику модели с помощью меньшего количества отношений ассоциации/агрегации. Хорошая модель подразумевает верный выбор компромисса между глубиной обобщения и уменьшением количества отношений ассоциации/агрегации, являющегося следствием обобщения.
При продуманном использовании обобщение способствует повышению уровня выразительности, понятности и абстрактности системных моделей. Источником преимуществ обобщения служит принцип подставимости (.substantiabilit)')— объект подкласса может быть использован вместо объекта суперкласса в любом месте программы, где объект подкласса имеет доступ к объекту суперкласса. Однако, к сожалению, существуют такие способы использования механизма наследования, которые могут свести на нет все преимущества принципа подставимости.
Наследование или инкапсуляция
• Инкапсуляция требует, чтобы доступ к атрибутам объекта был возможен только через операции интерфейса объекта. Результатом применения инкапсуляции является высокая степень независимости данных, так что изменения, затрагивающие инкапсулированные структуры данных, не требуют внесения изменений в существующие программы. Но в какой мере идея инкапсуляции осуществима в приложениях?
В действительности инкапсуляция ортогональна наследованию и возможностям запросов, и поэтому необходимо достижение определенного компромисса между инкапсуляцией и последними двумя свойствами. На практике, объявить все данные как закрытые невозможно.
Наследование подрывает основы инкапсуляции, разрешая подклассам осуществлять непосредственный доступ к защищенным атрибутам. Для вычислений, охватывающих объекты, принадлежащие различным классам, может потребоваться, чтобы различные классы были дружественными друг другу, что приводит к еще большему нарушению инкапсуляции. Иногда должны использоваться статические атрибуты, являющиеся глобальными по отношению ко всем объектам класса. И, поскольку всем ясно, что инкапсуляция касается понятия класса, а не объекта — в большинстве программных сред (за исключением языка Smalltalk) объект не может скрыть ничего от другого объекта того же класса.
Наконец, пользователи, осуществляющие доступ к базам данных с помощью средств языка SQL’или SQL-подобных языков незапланированных запросов, вполне справедливо ожидают, что им придется обращаться в запросах непосредственно к атрибутам, а не испытывать необходимость работать с методами доступа к данным, которые делают формирование запросов более трудным и более подверженным ошибкам. Это требование особенно справедливо в отношении приложений хранилищ данных, связанных с интерактивной аналитической обработкой запросов (OLAP — OnLine Analytical Processing).
Приложения должны разрабатываться таким образом, чтобы достичь требуемого уровня инкапсуляции и при том соблюсти компромисс в отношении наследования, незапланированных запросов и вычислительных требований.
Наследование интерфейса
' Когда обобщение используется с целью обеспечения подставимости, оно может служить синонимом понятия наследование интерфейса (порождения подтипа, наследова- * ния типа). Это, так сказать; “безопасный” вид наследования. Подкласс наследует типы атрибутов и сигнатуру операций (имя операции плюс формальные аргументы). Говорят,'что подкласс'поддерживает интерфейс Суперкласса. Реализация унаследованных операций откладывается на более позднее время.
Обычно интерфейсы объявляются посредством абстрактного класса. Можно сказать, с ’ЬдНой Оговоркой, "Что интерфейс является абстрактным классом. Оговорка состоит в •ТОм, Что абстрактный1 класс МоЛсеТ обеспечить частичную реализацию для некоторых операций, в то время как чистый интерфейс откладывает определение всех операций.
На рис. 5.21 Представлен фрагмент модели классов для приложения Телемаркетинг, который демонстрирует наследование интерфейса. Computer — это абстрактный Класс. Объекты этого класса не могут быть объектами-экземплярами. Операция getConf () получает две различные реализации: одну в классе ConfiguredComputer, а другую в Standardcomputer.
На рис. 5.22 показан альтернативный способ представления наследования интерфейса с использованием символа “леденца на палочке” для обозначения поддерживаемого интерфейса. Это отношение “леденец на палочке”, исходящее из подкласса (конкретизированного класса) к абстрактному классу, формально называется отношением реализации (realization relationship).
Рис. 5.21. Наследование интерфейса
ComputerHcomputer name: String
^getConf()
Рис. 5.22. Использование отношения реализации для представления наследования интерфейса
Наследование реализации.
Как было отмечено в предыдущем разделе, использование обобщения может подразумевать подставимость с последующей ее реализацией за счет наследования интерфейса. Однако использование обобщения может также подразумевать (сознательно или нет) повторное использование программного кода (code reuse) с последующей его реализацией за счет наследования реализации. Это очень мощная, иногда даже опасная по силе, интерпретация обобщения. Кроме того, эта интерпретация обобщения принята “по умолчанию".
Наследование реализации-г называемое также выведением подкласса, наследованием кода или наследованием класса — объединяет свойства суперкласса в подклассах и позволяет при необходимости замещать их новыми реализациями. Замещение (overriding) может означать включение (вызов) метода суперкласса в метод подкласса и расширение его за счет введения "новых функциональных возможностей. Оно также может означать полную замену метода суперкласса методом подкласса. Наследование реализации допускает совместное использование описаний свойства, повторное использование программного кода и полиморфизм.
При использовании в процессе моделирования обобщения необходимо четко отдавать себе отчет в том, какой именно вид наследования подразумевается. Использование наследования интерфейса безопасно только в том случае, если оно касается наследования фрагментов контракта — сигнатуры операций. Наследование реализации касается наследования кода — наследования фрагментов реализации [88], [34]. Если его тщательно не контролировать и не ограничивать, наследование реализации может принести больше вреда, чем пользы. Теперь мы приступим к обсуждению доводов за и против наследования реализации.
Правильный способ использования наследования реализации — наследование посредством расширения
Что касается увязки наследования с обобщением и надлежащего использования наследования реализации, язык 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).
Расширяющее наследование требует внимательного отношения к использованию замещения свойств. Допустимым считается только придание свойствам большей определенности (например, ограничение допустимых значений или более эффективная реализация операции), но никак не изменение значения свойства. Если замещение приводит к изменению значения свойства, объект подкласса не может быть больше подставлен вместо объекта суперкласса.
Проблематичный способ использования наследования реализации — наследование посредством ограничения
При использовании расширяющего наследования определение подкласса расширяется за счет введения новых свойств. Однако наследование можно также использовать в качестве ограничивающего механизма, посредством которого некоторые унаследованные свойства подавляются (замещаются) в подклассе. Подобное наследование называется наследованием посредством ограничения или ограничивающим наследованием (restriction inheritance [74].
На рис. 5.24 приведены два примера ограничивающего наследования. Поскольку наследование нельзя блокировать выборочно, класс окружностей Circle должен унаследовать свойства главной и дополнительной осей— mlnor_axis и major_axis— от эллипса Ellipse и заменить их атрибутом диаметра diameter. Аналогично, подкласс Penguin (Пингвин) должен унаследовать способность летать (операцию fly) от класса птиц Bird и заменить ее на операцию плавания swim
(пожалуй, полет на “отрицательной" высоте можно с некоторой натяжкой трактовать как плавание).
Ограничивающее наследование проблематично. С точки зрения обобщения подкласс не включает все свойства суперкласса. Объект суперкласса по-прежнему может быть заменен на объект подкласса при условии, что тот, кто использует объект, знает о замещенных (подавленных) свойствах.
При ограничивающем наследовании свойства класса используются (с помощью наследования) для реализации другого класса. Если замещение не носит всеобъемлющего характера, ограничивающее наследование может принести определенные выгоды. Однако, в общем случае ограничивающее наследование вызывает проблемы при сопровождении.
Рис. 5.23. Расширяющее наследование
Рис. 5.24. Ограничивающее наследование
Неверный способ использования наследования реализации — наследование по удобству
. Если в процессе системного моделирования оказывается, что наследование нельзя отнести к расширяющему или ограничивающему, оно воспринимается как “плохая новость". Подобный тип наследования встречается в тех случаях, когда два или более классов обладают аналогичными реализациями, но при этом отсутствует отношение таксономии между понятиями, представленными этими классами. Один из классов произвольно выбирается в качестве прообраза другого. Этот вид наследования называется наследование по удобству (convenience inheritance) [54], [74].
На рис. 5.25 приведено два примера наследования по удобству. Класс дуг LineSegment определен как подкласс класса точек Point. Ясно, что дуга— это не точка, и поэтому в данном случае обобщение в том виде, как оно было определено ранее, неприменимо. Однако наследование все же можно использовать. Конечно, для класса Point можно определить атрибуты координат xcoordinate и y_coordinate и операцию перемещения Move. Класс LineSegment может унаследовать эти свойства и может определить дополнительную операцию изменения размеров Resize. Операцию Move необходимо заместить. Аналогично, во вторюм примере класс автомобилей Саг наследует свойства класса мопедов Motorbike и добавляет некоторые новые свойства.
. Рис. 5.25. Наследование по удобству
., Наследование по удобству неприемлемо- Оно семантически некорректно. И приводит к масштабному замещению. Принцип подставимости, как правило, не работает, поскольку объекты не принадлежат к подобным типам (дуга (LineSegment) — не точка (Point:); автомобиль (Саг) — не мотоцикл (Motorbike)).
На практике, и к большому сожалению, разработчики часто используют наследование по удобству, поскольку многие объектные среды программирования поощряют неразборчивость при использовании наследования реализации. Многие языки оснащены неисчислимыми средствами “усиления программирования” с помощью наследования, в то время как поддержка других свойств объектов (в особенности агрегации) отсутствует.
Недостатки наследования реализации
Сказанное выше вовсе не означает, что запрещение использования наследования по удобству служит гарантией успеха. Использование наследования реализации — рискованное дело по многим меркам. При отсутствии надлежащего контроля и управления наследование может использоваться чрезмерно или неверно и может создать проблемы, которые требуют первоочередного решения. Это особенно справедливо для разработки крупномасштабных систем, которые включают сотни классов и тысячи объектов, отличаются динамизмом изменения состояний объектов и эволюционным характером структур классов (как, например, в случае типичных бизнес- приложений).
Основные факторы риска связаны со следующими перечисленными ниже концептуальными трудностями [88].
Изменчивость базового класса.
Замещение и обратные вызовы.
Множественное наследование реализации.
Изменчивый базовый класс
Проблема изменчивости базового класса (суперкласса) касается ситуации, при которой подклассы достигли определенного уровня зрелости и надежности, в то время как реализация их суперкласса (или суперклассов при множественном наследовании) продолжается. Это серьезная проблема в любом случае, а в особенности в ситуации, когда суперкласс можно получить из внешних источников, находящихся вне контроля бригады разработчиков системы.
Рассмотрим ситуацию, при которой суперклассы, которым наследует ваше приложение, образуют часть операционной системы, СУБД или GUI-интерфейса. Если для разработки вашего приложения вы приобретаете объектную СУБД, в действительности вы покупаете библиотеку для реализации типичных функций СУБД, таких как сохранение постоянных объектов, управление транзакциями, обеспечение параллельности, восстановление после сбоев и т.д. Если разрабатываемые классы являются потомками библиотеки классов, то последствия от внедрения новой версии библиотеки непредсказуемы (если при разработке модели наследования для приложения не выказать предусмотрительности, то это несомненно так и есть).
С проблемой изменчивости базового класса трудно справиться, не объявив открытые интерфейсы неизменяемыми или, по меньшей мере, не установив контроля над наследованием реализации из суперклассов. Изменения в реализации суперклассов (для которых может даже отсутствовать исходный текст программ) непредсказуемым образом воздействуют на подклассы прикладной системы. Это справедливо даже тогда, когда интерфейс суперкласса остается неизменным. Ситуация может еще более усугубиться, если изменения также сказываются на интерфейсах. Вот примеры подобных ситуаций [88].
Изменение сигнатуры метода.
Разделение метода на два или более новых методов.
Объединение существующих методов в виде более крупного метода.
Практический вывод из сказанного можно сформулировать следующим образом. Чтобы справиться с проблемой изменчивости базового класса, разработчики, проектирующие суперкласс, должны заранее иметь представление о том, как будут действовать люди при повторном использовании суперкласса сегодня и в будущем. Конечно, узнать это, не прибегая к помощи гадалок, нельзя. Как гласит шутка, начертанная в виде лозунга на бампере автомобиля: “сумасшествие не наследуется, оно достается вам от ваших детей” [29]. В разд.5.4 рассматриваются некоторые альтернативные методы объектной разработки, которые, не будучи основаны на наследовании, все же обеспечивают требуемые функциональные возможности объектов.
Замещение и обратные вызовы
Наследование реализации допускает выборочное замещение унаследованного программного кода. Ниже перечислены пять методов, с помощью которых метод подкласса может повторно использовать код его суперкласса.
Подкласс может наследовать интерфейс и реализацию метода без внесения каких-либо изменений в реализацию.
Подкласс может наследовать код и включить его (вызвать его) в свой собственный метод с той же сигнатурой.
Подкласс может наследовать код и затем полностью заместить его новой реализацией с той же сигнатурой.
Подкласс может наследовать пустой код (т.е. декларация метода отсутствует), а затем ввести реализацию для метода.
Подкласс может наследовать только интерфейс метода (т.е. мы имеем случай наследования интерфейса), а затем ввести реализацию для метода.
Из этих пяти методов первые два доставляют наибольшие трудности в случае склонности программного кода базового класса к эволюции. Пятый метод выказывает полное безразличие к наследованию. Последние два метода представляют особые случаи — четвертый случай тривиален, а пятый не касается наследования реализации.
Обратитесь к приложению Телемаркетинг и, а частности, к примеру 5.4 (разд. 5.1.4.1). • Модифицируйте отношение обобщения между классами Campaign и Bonuscampaign таким образом, чтобы включить операции, которые служат примером первых трех методов повторного использования, перечисленных выше.
На рис. 5.26 приведен особый вариант отношения обобщения между классами Campaign и BonusCampaign, призванный продемонстрировать три метода повторного использования. Этим методам соответствуют следующие операции: getDateClose (получить дату завершения [кампании]), printTicketDetails (отпечатать подробную информацию о билете) и computeTicketsLeft (подсчитать количество оставшихся билетов).
Реализация операции getDateClose() наследуется классом BonusCampaign и повторно используется им без изменений (это первый метод из приведенного выше списка).
Две оставшиеся операции замещаются в классе BonusCampaign. На модели этот факт отражается за счет дублирования имен операций в BonusCampaign. Предполагается, что операция printTicketDetails представляет второй метод, т.е. метод BonusCampaign .printTicketDetails () вызывает унаследованный метод Campaign.printTicketDetails (), скажем, для печати общего количества билетов, участвующих в кампании. Затем.он выводит на печать специфическую информацию о призовых билетах, такую как количество билетных книжек и объем книжек.
Рис. 5.26. Наследование и замещение (Телемаркетинг)
Теперь предположим, что операция computeTicketsLeft () представляет третий метод повторного использования. Метод BonusCampaign.computeTicketsLeft() является наследником (поскольку это предусмотрено) метода Campaign. compute TicketsLeft (), азатем полностью замещает унаследованный код.
Пример 5.12 демонстрирует влияние замещения на проблему изменчивости базового класса. Он также показывает, что наследование реализации приводит к возникновению сетеобразных структур для путей взаимодействия между объектами, которые, как было показано ранее, отличаются неустойчивостью в больших системах (разд.5.2). При использовании наследования реализации передача сообщений может возникать повсеместно. Помимо простых прямых вызовов сверху-вниз (down-calls) по иерархии наследования, имеют место также и обратные вызовы (вызовы снизу-вверх) (callbacks (upcalls)) (разд.6.2.2.8).
Как замечает Шиперский [88]: “В соединении с наблюдаемым состоянием это приводит к семантике замкнутых вызовов, близкой той, которая характерна для параллельных систем. Произвольный граф вызовов, формируемый сетью взаимодействующих объектов, разрушает классическую схему иерархии уровней и делает замкнутые вызовы нормой.”
Ради справедливости следует заметить, что обратные вызовы возможны не только между объектами, связанными отношениями наследования, а всюду, где существуют ссылки между объектами. Вновь приведем замечание Шиперского [88]: “При наличии объектных ссылок ... всякий вызов метода может рассматриваться как потенциальный вызов снизу-вверх, каждый метод может быть потенциально связан с обратным вызовом”. Наследование только вносит свой вклад в общую проблему, но, надо заметить, вклад существенный.
Множественное наследование реализации
Множественное наследование было введено в разд.2.1.5.2.1, однако, до сих пор мы не проводили различия между множественным наследованием интерфейса (множественным наследованием от супертипов) и множественным наследованием реализации (множественным наследованием от суперклассов). Множественное наследование интерфейса допускает слияние контрактов интерфейсов. Множественное наследование реализации позволяет объединить фрагменты реализации.
Множественное наследование реализации в действительности не создает каких-либо дополнительных проблем наследования реализации. Оно скорее усугубляет проблемы, вызванные изменчивостью базового класса, замещением и обратными вызовами. Помимо требования блокировать наследование любых дублирующихся фрагментов (когда два или более суперкласса определяют одну и ту же операцию), оно может также вызвать необходимость переименовать операции всякий раз, когда повторяющиеся имена совпадают (а в действительности должны обозначать разные операции).
В этом контексте стоит напомнить о присущим системам росте сложности из-за множественного наследования — росте, вызванном отсутствием поддержки множественной классификации в объектных системах (разд.2.1.5.2.2). Любые ортогональные ветви наследования, сходящиеся в одном суперклассе, должны объединяться в дереве наследования на более низком уровне иерархии с помощью специально созданных "объединяющих" классов (см. пример в разд.2.1.5.2.2).
Углубленное моделирование агрегации и делегирования
Агрегация представляет собой третий метод связывания классов в моделях анализа (разд.2.1.4). В сравнении с двумя другими методами (традиционной ассоциацией и обобщением) агрегации уделялось меньше всего внимания. Тем не менее агрегация представляет собой наиболее мощный из известных нам методов управления сложностью больших систем с помощью распределения классов по иерархическим уровням абстракции.
Агрегация (и ее боле сильный вариант— композиция^ — отношение включения. Составной класс содержит один или более компонентных классов. Компонентный класс является элементом одного или более составных классов. Компонентные классы являются элементами их составных классов (хотя элементы ведут свое собственное существование). Хотя агрегация получила признание как фундаментальная концепция моделирования, по меньшей мере, одновременно с обобщением, в объектно-ориентированном анализе и проектировании ей уделяется лишь незначительное внимание (за исключением областей приложений наподобие систем мультимедиа).
В средах программирования (включая большинство объектных СУБД) агрегация реализуется так же, как традиционная ассоциация — с помощью запроса ссылок между составными и компонентными объектами. Хотя структура времени компиляции для агрегации аналогична структуре ассоциации, во время выполнения они ведут себя по- разному. Агрегация обладает более строгой семантикой, и ответственность за то, чтобы структуры времени выполнения удовлетворяли этой семантике, лежит (к сожалению) на программисте.
Расширение семантики агрегации
Хотя современные среды программирования игнорируют агрегацию, методы разработки объектных приложений включают агрегацию среди прочих возможностей моделирования, однако отводят ей последнее место. Кроме того (или вследствие недостаточной поддержки в средах программирования), методы разработки объектных приложений не стремятся придать агрегативным конструкциям строгую семантическую интерпретацию, зачастую трактуя их просто как особую форму ассоциации.
Как рассматривалось в разд.4.2.3, можно выделить четыре возможных семантики для агрегации [55].
Агрегация типа “Безраздельно обладает".
Агрегация типа "Обладает".
Агрегация типа “Включает".
Агрегация типа “Член”.
UML признает только две семантики агрегации, а именно агрегацию (ссылочная семантика) и композицию (семантика значений) (разд.2.1.4). Теперь будет показано, каким образом можно использовать существующую нотацию UML для представления четырех видов агрегации, указанных выше.
4.1.1. Агрегация типа “Безраздельно обладает”
Агрегацию типа Безраздельно обладает можно представить в UML как композицию- стереотип, обозначенную с помощью ключевого слова «ExclusiveOwns» и дополнительно ограниченную с помощью ключевого слова (замороженный) [25]. Ограничение frozen применяется к компонентному классу. Оно констатирует, что объект компонентного класса не может быть заново соединен ( в течение своего ЖЦ) с другим составным объектом. Компонентный объект может быть удален вовсе, но не может переключиться на другого владельца.
На рис. 5.27 показано два примера агрегации типа Безраздельно обладает. Левая часть рисунка представляет пример моделирования агрегации в UML с использованием семантики значений (заполненный ромб), а правая часть — пример моделирования агрегации в UML с использованием ссылочной семантики (пустой ромб).
Рис. 5.27. Агрегация типа Безраздельно обладает
Объект Chapter (Глава) является частью, по меньшей мере, одного объекта CopyrightedBook (Книга, защищенная авторским правом). Будучи включенным
(по значению) в составной объект, он не может быть повторно соединен с другим объектом CopyrightedBook. Соединение заморожено (за счет ограничения frozen).
Колода карт для игры в бридж (BridgeCardPack) содержит в точности пятьдесят две карты. Для моделирования принадлежности в UML используется ссылочная семантика. Каждая карта для бриджа (объект BridgeCard) принадлежит в точности одной колоде карт (BridgeCardPack) и не может быть повторно соединена с другой колодой карт.
4.1.2. Агрегация типа “Обладает”
Аналогично агрегации типа Безраздельно обладает агрегацию типа Обладает можно выразить в UML с помощью семантики значений композиции (заполненный ромб) или ссылочной семантики агрегации (пустой ромб). В каждый момент времени компонентный объект принадлежит по меньшей мере одному составному объекту, однако он может быть заново соединен с другим составным объектом. При удалении составного объекта его компонентные объекты также удаляются.
На рис. 5.28 показано два примера агрегации типа Обладает. Вода (объект Water) может быть перелита из одного кувшина (объект Jug) в другой. Аналогично, шина (объект Tire) может быть переставлена с одного велосипеда (Bicycle) на другой. Благодаря зависимости по существованию, разрушение объекта Jug или Bicycle распространяется вниз на их компонентные объекты.
Рис. 5.28. Агрегация типа Обладает
4.1.3. Агрегация типа “Включает”
Для моделирования агрегации типа Включает в UML обычно используется ссылочная семантика агрегации (пустой ромб). Агрегация типа Включает не содержит зависимости по существованию — удаление составного объекта не распространяется автоматически вниз на компонентные объекты. Агрегацию типа Включает отличают такие свойства, как транзитивность и асимметричность.
Пример агрегации типа Включает показан на рис. 5.29. Если тележка (объект Trolley) включает несколько ящиков с пивом (BeerCrate), а каждый ящик с пивом включает несколько бутылок с пивом (BeerBottle), то тележка также включает бутылки с пивом (транзитивность). Если тележка включает ящики с пивом, то ящики с пивом не могут включать тележку (асимметричность).
Рис. 5.29. Агрегация типа Включает
4.1.4. Агрегация типа “Участник”
Агрегация типа Участник допускает отношения с кратностью “многие ко многим". В отношении свойств зависимости по существованию, транзитивности, асимметрии и ограничения frozen не делается никаких специальных предположений. При необходимости любое из этих четырех свойств можно выразить в UML с помощью ограничения. Благодаря кратности “многие ко многим”, агрегацию типа Участник можно моделировать в UML только с помощью ссылочной семантики агрегации (пустой ромб).
На рис. 5.30 показано четыре отношения агрегации типа Участник. JAD-совещание (объект JADSession) (см. разд. 3.2.2.2) состоит из одного модератора и одного или нескольких секретарей (Scribe), пользователей (User) и разработчиков (Developer). Каждый компонентный “объект" может принимать участие, более чем в одном JAD-совещан ии.
Рис. 530. Агрегация типа Участник
Агрегация как альтернатива обобщению
Обобщение — это отношение суперкласс-подкласс. Агрегация больше напоминает отношение супермножество-подмножество. Вопреки этому различию обобщение можно представить как агрегацию.
Рассмотрим рис. 5.31. Заказы клиентов, которые не выполнены, могут ожидать некоторых дальнейших действий. Заказ в состоянии ожидания может быть отложенным заказом, который должен быть выполнен после пополнения запаса. Заказ в состоянии
ожидания может быть заказом наперед, если он должен быть выполнен позднее, в сроки, определенные клиентом.
Модель в левой части рисунка представляет собой обобщение заказов клиентов. Класс Gorder (Заказ) может быть классом GPendingOrder (Ожидающий заказ). Класс GPendingOrder может быть классом GBackOrder (Невыполненный заказ) или классом GFutureOrder (Заказ наперед). Наследование гарантирует разделение атрибутов и операций вниз по дереву обобщения.
Аналогичную семантику можно смоделировать с помощью агрегации, показанной в правой части рисунка 5.31. Классы ABackOrder и AFutureOrder включают атрибуты и операции класса APendingOrder, которые, в свою очередь, включает класс AOrder.
Хотя две модели, показанные на рис. 5.31, отражают аналогичную семантику, между ними существуют определенные различия. Одно из них вытекает из замечания, что модель обобщения основана на понятии класса, в то время как модель агрегации фактически сконцентрирована на понятии объекта.
Конкретный объект GBackOrder является также объектом класса и GPendingOrder и Gorder. Для объекта GBackOrder существует один идентификатор объекта (OID). С другой стороны, конкретный объект ABackOrder состоит из трех отдельных объектов, каждый из которых обладает собственным идентификатором объекта,— собственно объект ABackOrder, содержащийся в нем объект APendingOrder и содержащийся в‘нем объект AOrder.
Обобщение использует наследование для реализации его семантики. Агрегация использует делегирование для повторного использования реализации компонентных объектов. Использование делегирования рассматривается в следующем разделе.
Рис. 5.31. Альтернатива: обобщение или агрегация
Делегирование и системы-прототипы
Вычислительная модель наследования основана на понятии класса. Однако можно положить в основу вычислительной модели понятие объекта. Объектноориентированная вычислительная модель структурирует объекты в виде агрегативных иерархий. Всякий раз, когда составной объект (.внешний объект') не в состоянии выполнить задание самостоятельно, он может вызвать методы одного из его компонентных объектов (внутренних объектах) — это называется делегированием (delegation).
При подходе, основанном на делегировании, функциональные возможности системы реализуются с помощью включения (клонирования) функций существующих объек-
тов во вновь требуемые функции. Существующие объекты трактуются как прототипы для создания новых объектов. Идея состоит в том, чтобы сначала отыскать требуемые функции в существующих объектах (внутренних объектах), а затем реализовать необходимые функции во внешних объектах. Системы, построенные подобным способом из существующих объектов-прототипов, называются системами-прототипами.
Объект может быть связан отношением делегирования с любым другим идентифицируемым и видимым объектом в системе [49]. Когда внешний объект получает сообщение и не в состоянии выполнить обслуживание самостоятельно, он делегирует выполнение обслуживания внутреннему объекту. При необходимости внутренний объект может переслать сообщение любого из своих собственных внутренних объектов.
Интерфейсы внутреннего объекта могут быть видимы или невидимы для объектов, отличных от внещнего объекта. Для контроля уровня видимости внутренних объектов можно использовать четыре типа агрегации, определенные в разд.5.4Л. Например, внешний объект может раскрыть интерфейс внутреннего объекта как свой собственный в более слабой форме агрегации (например, в такой как агрегация типа Включает или Участник). При более сильной форме агрегации внешний объект может скрыть интерфейс своего внутреннего объекта от внешнего мира (вводя, таким образом, уровень инкапсуляций).
Делегирование или наследование
Покажем, что с помощью делегирования можно моделировать наследование и наоборот. Это значит, что одни и те же функциональные возможности можно реализовать как с помощью наследования, так и делегирования. Согласие в этом вопросе впервые было достигнуто на конференции в США в городе Орландо, штат Флорида, в 1987 году и теперь известно как Орландское соглашение [81].
Мы уже касались изъянов наследования реализации. В связи с этим возникает настоятельный вопрос: позволяет ли делегирование избежать недостатков, присущих наследованию реализации. Ответ на этот вопрос не очевиден [88].
С точки зрения повторного использования делегирование сильно приближено к наследованию. Внешний объект повторно использует реализацию внутреннего объекта. Разница состоит в том, что — в случае наследования — после завершения обслуживания управление всегда возвращается объекту, который получает исходное сообщение (запрос на обслуживание).
В случае делегирования после того, как управление передано от внешнего объекта внутреннему объекту, оно остается у последнего. Любая авторекурсия должна быть явно запланирована и спроектирована в рамках делегирования. При использовании наследования реализации авторекурсия всегда случайна — она не запланирована и наложена как программная “заплата” [88]. Одним из нежелательных последствий неза- планированного/“заплатанного" повторного использования является проблема изменчивости базового класса.
Еще одним потенциальным преимуществом делегирования является то, что разделение и повторное использование можно определить динамически во время выполнения приложения. В системах, ориентированных на использование наследования, разделение и повторное использование обычно определяется статически при создании объекта. При этом достигается компромисс между безопасностью и скоростью выполнения предусмотренного разделения наследования и гибкостью непредусмотренного разделения делегирования.
В пользу делегирования можно привести тот аргумент, что непредусмотренное разделение более естественно и ближе к человеческому способу мышления [49]. Объекты объединяются естественным способом для формирования масштабных решений и могут эволюционировать непредвиденным образом. В следующем разделе приводится другая точка зрения на эти же вопросы.
Агрегация и голоны — интеллектуальное орудие
В работах [54] и [55] с целью обуздания сложности объектных моделей был предложен новый подход для описания архитектуры ПО, основанный на интерпретации естественных систем Артура Кёстлера (Arthur Koestler) [44], [45]. Центральной концепцией является идея так называемых “голонов" (“ho Ions"), которые интерпретируются как объекты, являющиеся одновременно и частью и целым. Более точно они рассматриваются как саморегулируемые сущности, которые проявляют одновременно взаимозависимые свойства части и независимые свойства целого.
Живые системы обладают иерархической организацией. Структурно они представляют собой агрегации полуавтономных элементов, которые являют как независимые свойства целого, так и взаимозависимые свойства части. По Артуру Кёстлеру они представляют собой агрегации голонов от греческого слова holos, обозначающего целое (англ, whole) с суффиксом, измененным на-он (он), означающим частицу или часть (как в словах протон или нейтрон) [44].
Части и целое в абсолютном смысле не существуют в живых организмах и даже в социальных системах. Голоны образуют иерархические уровни соответствующей сложности, например, в биологических организмах можно различать иерархию атомов, молекул, органоидов, клеток, тканей, органов и систем органов. Подобные иерархии голонов называются голократиями.
Каждый уровень голократии скрывает свою сложность от вышележащего уровня. Если смотреть сверху-вниз, голон представляет собой нечто законченное и уникальное, целое. Если смотреть снизу-вверх, голон представляет собор элементарную компоненту, часть. Каждый уровень голократии содержит множество голонов, например, атомов (водород, углерод, кислород и т.д.), клетки (нервные волокна, клетки крови и т.д.).
Если смотреть изнутри, голон предоставляет услуги другому голону. Если смотреть снаружи, голон запрашивает услуги у других голонов. Голократии отличаются незавершенностью. Не существует абсолютных голонов-“листьев” или голонов-“вершин” за исключением тех, которые мы специально обозначаем таким образом для удобства интерпретации. Благодаря этим характеристикам, сложные системы могут эволюционировать из простых систем.
Отдельные голоны, таким образом, представляются четырьмя характеристиками.
Его внутренние правила (взаимодействия между ними могут формировать уникальные шаблоны).
Самоутверждающаяся агрегация подчиненных голонов.
Тенденция к интеграции по отношению к высшим голонам.
Отношения с соседними голонами.
Удачные системы упорядочены в виде голократий, которые скрывают сложность в последовательных нижних уровнях и в то же время обеспечивают больший уровень
абстракции в рамках более высоких уровней ее структур. Эта концепция соответствует семантике агрегации.
Агрегация предусматривает разделение — позволяет каждому классу оставаться инкапсулированным и концентрироваться на специфическом поведении (кооперация и услуги) класса способом, который не связан с реализаций его родительских классов (как это имеет место для обобщения). В то же время агрегация позволяет свободное перемещение между стратифицированными уровнями во время выполнения.
Баланс между интеграцией и самоутверждением объектов (голонов) достигается за счет требования, согласно которому объекты должны “признавать интерфейсы друг друга” [28]. Инкапсуляция не нарушается, поскольку объекты взаимодействуют только посредством своих интерфейсов. Эволюция системы облегчается, поскольку взаимодействие объектов не запрограммировано жестко в реализации с помощью механизмов, аналогичных наследованию.
Со структурной точки зрения агрегация дает возможность моделировать большие сообщества объектов с помощью группирования их в виде различных множеств и установления между ними отношения часть-целое. С функциональной точки зрения агрегация позволяет просматривать иерархию объектов (голонов) сверху-вниз и снизу-вверх.
Однако агрегация не позволяет моделировать необходимые возможности взаимодействия между голонами одного уровня так, чтобы они могли просматривать структуру изнутри и извне. Этот структурный и функциональный разрыв можно преодолеть с помощью отношений обобщения и ассоциации.
В рамках рекомендуемого подхода агрегация обеспечивает “вертикальное” решение и обобщение “горизонтального” решения для разработки объектных приложений. Агрегация становится преобладающей концепцией моделирования, которая определяет общую структуру системы. Эта структура может быть формализована за счет использования множества проектных шаблонов [28], в особенности поддержки подхода на основе голонов и применения четырех видов агрегации. Мы надеемся, что рассмотренный выше подход послужит читателям интеллектуальным орудием в их собственных изысканиях.
Резюме
В этой главе было завершено рассмотрение анализа требований. Была тщательно исследована поддержка объектной технологии для разработки крупномасштабных систем. Глава представляется технически сложной, но обеспечивает проникновение в сущность объектной технологии, которое не так просто найти в книгах по анализу и проектированию систем. Это глубокое проникновение во многом помогает раскрыть слабые стороны и недостатки объектной технологии.
Основным методом расширения языка UML является использование стереотипов. Они позволяют моделировать свойства, выходящие за пределы предопределенных в UML. За счет изобретательности в этой главе удалось широко использовать стереотипы. Стереотипы не следует путать с ограничениями, примечаниями и дескрипторами UML.
Открытая и закрытая видимость, рассмотренная в предыдущей главе, обеспечивает только базовую поддержку важного понятия инкапсуляции. Защищенная видимость позволяет управлять инкапсуляцией в рамках структур наследования. Видимость уровня класса (в противоположность видимости отдельных атрибутов и операций) представляет собой еще одну важную концепцию, касающуюся наследования. Понятие друже-
ственности позволяет “прорваться” сквозь инкапсуляцию для обработки специфических ситуаций.
Язык UML включает некоторые дополнительные концепции моделирования, способные повысить выразительность моделей классов. К ним относятся производные атрибуты, производные ассоциации и квалифицированные ассоциации. Одним из наиболее интригующих моментов в моделировании классов является выбор между ассоциативным классом и материализованным классом.
Современные программные системы отличаются большой сложностью. Поэтому важно, что решения по моделированию упрощают разработку систем и позволяют уменьшить присущую им сложность там, где это возможно. Пожалуй, наиболее важным механизмом, позволяющим обуздать сложность ПО, является представление архитектуры системы в виде многоуровневой иерархии. Надлежащее структурирование классов в виде пакетов, организованных в соответствии с подходом ВСЕ, является важной архитектурной задачей.
Концепция обобщения и наследования представляет собой в моделировании “палку о двух концах". С одной стороны, она способствует повторному использованию ПО и повышает выразительность, понятность и уровень абстракции моделей системы. С другой стороны, при неверном использовании всех перечисленных преимуществ она потенциально склонна к саморазрушению.
Концепция агрегации и делегирования представляет собой важную альтернативу обобщению и наследованию в моделировании. Делегирование и системы-прототипы обладают дополнительными преимуществами поддержки иерархических архитектурных структур. Абстрактное понятие галона дает интересный взгляд на способ построения сложных систем.
Вопросы
Что называется в UML “профилем"? Приведите пример.
Иногда класс позволяет порождать только неизменяемые объекты, т.е. объекты, которые не могут изменяться после реализации. Каким обрвзом подобное требование можно представить в UML-модели?
Объясните различие между ограничением и примечанием.
Обозначают ли термины “инкапсуляция” и “видимость” одно и то же понятие? Объясните вашу точку зрения.
Видимость унаследованных свойств в производном классе зависит от уровня видимости, который предоставлен базовому классу в определении этого производного класса. Какова будет видимость, если базовый- класс объявлен как закрытый? Каковы последствия этого факта для остальной модели? Приведите пример.
Вб. Понятие “дружественности" применимо к классу или операции. Объясните, в чем различие этих случаев. Приведите пример (отличный от изложенного в этой книге), когдв требуется использование свойства дружественности.
В чем заключаются преимущества использования производной информации для моделирования?
Когда материализованный класс должен заменять ассоциативный класс? Приведите пример (отличный от приведенного в этой книге).
Какова сложность сети из девяти классов (измеряемая как количество возможных соединений между этими классами)? Изобразите иерархию для этих девяти классов, состоящую из четырех уровней. Какого понижения сложности можно достичь за счет этой четырехуровневой иерархии?
Предположим, что модель классов для банковского приложения содержит класс interestcalculation (Подсчет процентов). Какому пакету ВСЕ должен принадлежать этот класс? Объясните свою точку зрения.
В чем состоит принцип подставимости? Дайте пояснения.
Объясните различия между наследованием интерфейса и наследованим реализации.
В чем состоит проблема изменчивости базового класса? Каковы основные причины изменчивости базовых классов?
Объясните различия между агрегациями типа Безраздельно владеет и Владеет. Какие преимущества при моделировании дает разделение агрегации на два этих вида?
Сравните наследование и делегирование. В чем их схожесть? В чем различие между ними?
@| Упражнения
У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.
Архитектура программного обеспечения
Проект представляет собой низкоуровневую модель архитектуры системы и ее внутренних функций. Проектирование осуществляется в терминах программно-аппаратной платформы, на которой предстоит реализовать систему. При итеративной и наращиваемой разработке модели анализа непрерывно "обрастают” техническими подробностями. Как только Технические подробности включают соображения, касающиеся программного и аппаратного обеспечения, модель анализа становится проектной моделью.
Между анализом и проектированием нельзя провести резкой границы. Можно углубляться в технические вопросы, не касаясь специфических программно-аппаратных решений. В этом смысле большую часть вопросов, обсуждавшихся в главе 5, можно отнести скорее к анализу, чем к проектированию.
Описание системы в терминах ее модулей называется архитектурным проектированием (architectural design). Архитектурный проект включает выбор стратегии решений в отношении клиентской и серверной компонент системы.
Описание внутренних функций каждого модуля (прецедента) называется детализированным проектированием (detailed design). Детализированный проект направлен на разработку завершенных алгоритмов и структур данных для каждого модуля. Эти алгоритмы и структуры данных приспосабливаются ко всем (усиливающим и навязываемым) ограничениям базовой платформы реализации.
Распределенная архитектура
Архитектурное проектирование связано с выбором стратегии решений и модуляризацией системы. Стратегия решения призвана разрешить проблемы, связанные с построением клиентской и серверной частей системы, а ПО промежуточного слоя (middleware) необходимо для “склеивания” клиента и сервера. Решение по основным строительным блокам (модулям) только отчасти зависит от выбранной стратегии решения.
Клиент и сервер — логические понятия [6]. Клиент (client) — это вычислительный процесс, который осуществляет запросы к процессу сервера. Сервер (server) — это вычислительный процесс, который обслуживает запросы сервера. Обычно процессы клиента и сервера выполняются на разных компьютерах, но вполне возможно реализовать систему клиент/сервер на одной машине.
В типичном сценарии клиентский процесс отвечает за управление отображением информации на экране пользователя и за обработку событий, инициированных пользователями. Процесс сервера— это любой компьютерный узел с базой данных, из которой данные могут быть запрошены клиентским процессом.
Архитектуру клиент/сервер можно расширить для представления произвольной распределенной системы. Любой компьютерный узел с базой данных может играть роль клиента в одних деловых операциях, а сервер — в других операциях. Соединение подобных узлов с помощью сети связи дает начало архитектуре системы распределенной обработки, как показано на рис. 6.1.
В системе распределенной обработки клиент может осуществлять доступ к любому количеству серверов. Однако клиенту может быть разрешен доступ одновременно только к одному серверу. Это значит, что он может быть не в состоянии объединить данные от двух или более серверов баз данных в одном запросе. Если это возможно, то архитектура поддерживает систему распределенных баз данных.
Трехзвенная архитектура
В разд. 5.2.4 был рассмотрен подход ВСЕ (boundary-control-entity— граница- управление-сущность). Также утверждалось, что подход ВСЕ хорошо увязан с трехзвенной архитектурой, в которой между клиентом (граница) и сервером (сущность) вводится отдельный промежуточный слой логики приложения (управление).
Аналогично клиентскому и серверному процессу прикладной процесс представляет собой логическое понятие, которое может поддерживаться или не поддерживаться специально выделенным для этой цели аппаратным обеспечением. Логика приложения может с равным успехом выполняться на клиентском или серверном узле, т.е. может быть встроена в клиентский или серверный процесс и реализована в виде библиотеки DLL (Dynamic Link Library — динамически компонуемая библиотека), API-интерфейса (Application Programming Interface — интерфейс прикладного программирования), RPC- вызовов (Remote Procedure Calls — удаленный вызов процедуры) и т.д. [57].
Если логика приложения скомпилирована с клиентом, говорят об архитектуре толстого клиента (thick client architecture') ("клиент на стероидах’’). Если она скомпилирована с сервером, говорят об архитектуре тонкого клиента (thin client architecture) (“клиент “кожа да кости”). Возможны также промежуточные архитектуры, в которых логика приложения частично скомпилирована с клиентом, а частично — с сервером.
Логику приложения можно также развернуть на отдельных вычислительных узлах, как показано на рис. 6.2.
1вная1вная1ИЛ '1ИЛ 'Novell NetWare SPX/IPXNovell NetWare SPX/IPXУровень активной базы данныхУровень активной базы данныхПользовательский уровеньПользовательский уровеньРис. 6.2. Трехзвенная архитектураРис. 6.2. Трехзвенная архитектура
1вная
1вная
1ИЛ '
1ИЛ '
Novell NetWare SPX/IPX
Novell NetWare SPX/IPX
Уровень активной базы данных
Уровень активной базы данных
Пользовательский уровень
Пользовательский уровень
Рис. 6.2. Трехзвенная архитектура
Рис. 6.2. Трехзвенная архитектура
Это трехзвенная архитектура в самом чистом виде. К ее лучшим сторонам относятся высокая гибкость, расширяемость, независимость пользователя, готовность и низкая стоимость обновления. Однако подобная архитектура может отличаться высокой начальной стоимостью, а кроме того может испытывать некоторые проблемы с производительностью [90].
Программирование баз данных
Независимо от того, где расположена логика приложения, программа (клиент) взаимодействует с базой данных (сервером), чтобы получить информацию для ее отображения и предоставления в распоряжение пользователя для дальнейших манипуляций. Однако современные базы данных также можно программировать. Говорят, что эти современные базы данных активны.
Программы баз данных называются хранимыми процедурами {stored procedure). Хранимые процедуры хранятся в самой базе данных (они являются постоянными или персистентными^. Их можно вызвать из клиентской программы (или из другой хранимой процедуры) с помощью обычного оператора вызова процедуры/функции.
Существуют хранимые процедуры специального вида — триггеры, которые нельзя вызвать явно. Триггер срабатывает автоматически при попытке изменить содержимое базы данных. Триггеры используются для реализации бизнес-правил масштаба предприятия, которые должны быть проведены в жизнь способом, независимым от клиентских программ (или хранимых процедур). Триггеры усиливают целостность и непротиворечивость баз данных. Они не позволяют отдельным приложениям нарушать бизнес-правила, заложенные в базу данных.
Взаимодействие “приложение-база данных”
Нам необходимо решить, какая часть системы будет запрограммирована в клиенте, а какая — в базе данных. При этом рассматриваются следующие программируемые части системы.
Пользовательский интерфейс.
Презентационная логика.
Прикладные функции.
Интегральная логика.
Функции доступа к данным.
Часть программы, которая называется пользовательским интерфейсом, отвечает за отображение информации на конкретный GUI-интерфейс, такой как GUI-интерфейс Microsoft Windows, GUI-интерфейс Unix Motif, GUI-интерфейс Macintosh. Презентационная логика (или логика представления) отвечает за обработку объектов GUI-интерфейса (форм, меню, кнопок действий и т.д.), как того требуют функции приложения.
Функции приложения содержат основную логику программы. Они фиксируют действия приложения и представляют собой связующее звено, соединяющее вместе клиента и базу данных. С точки зрения подхода ВСЕ (разд. 5.2.4) функции приложения реализуются классами управляющего пакета.
Интегральная логика отвечает за бизнес-правила масштаба предприятия. Это правила, которые применяются ко всем прикладным программам, т.е. все программы
должны функционировать в соответствии с ними. Функции доступа к данным владеют вопросами доступа к постоянным объектам данных на диске.
На рис. 6.3 показан типичный сценарий. Пользовательский интерфейс и презентационная логика принадлежат клиенту. Функции доступа к данным и интегральная логика (триггеры) находятся в ведении базы данных. Прикладные функции зачастую программируются (в виде SQL-запросов) как часть клиента в начале этапа разработки, а затем переносятся в базу данных (в виде хранимых процедур) для окончательного развертывания программного продукта.
Интерфейс пользователяПрезентационная логикаФункция приложения (разработка)Интерфейс пользователяПрезентационная логикаФункция приложения (разработка)КлиентКлиентПО промежуточного слоя — протокол обмена (например, собственный интерфейс или ODBC)ПО промежуточного слоя — протокол обмена (например, собственный интерфейс или ODBC)Функция приложенияИнтегральная логикаДоступк даннымФункция приложенияИнтегральная логикаДоступк даннымБаза данныхБаза данныхИнтерфейс пользователяПрезентационная логикаФункция приложения (разработка)Интерфейс пользователяПрезентационная логикаФункция приложения (разработка)
Интерфейс пользователя
Презентационная логика
Функция приложения (разработка)
Интерфейс пользователя
Презентационная логика
Функция приложения (разработка)
Клиент
Клиент
ПО промежуточного слоя — протокол обмена (например, собственный интерфейс или ODBC)
ПО промежуточного слоя — протокол обмена (например, собственный интерфейс или ODBC)
Функция приложения
Интегральная логика
Доступ
к данным
Функция приложения
Интегральная логика
Доступ
к данным
База данных
База данных
Интерфейс пользователя
Презентационная логика
Функция приложения (разработка)
Интерфейс пользователя
Презентационная логика
Функция приложения (разработка)
Рис. 6.3. Взаимодействие “приложение-база данных”
Подход BCED
Подход BCED (Boundary-Control-Entity-Database— граница-управление-сущностъ-база данных) является расширением подхода ВСЕ (разд. 5.2.4). Он позволяет эффективно отделить EntityPackage (Пакет сущностей) от классов, ответственных за извлечение данных из базы данных. Эти классы помещаются в пакете DatabasePackage (Пакет базы данных) (рис. 6.4). (Пакет DatabasePackage в действительности является пакетом интерфейса с базой данных — Dat abase Inter face Package, однако, мы предпочитаем короткие обозначения. Назвать пакет подобным образом — в любом случае не очень хорошая идея из-за многозначности понятия интерфейса.)
Пакет EntityPackage по-прежнему обеспечивает "исполняемую модель бизнес- процессов” [26]. Он хранит и помещает в буфер данные, полученные из базы данных и других источников; эффективно запрашивает две службы пакета DatabasePackage, а именно, службу загрузки объекта из базы данных loadMe (anObject) и службу сохранения объекта в базе данных saveMe (anObject) [26]. Реализация этих служб возможна в рамках классов пакета DatabasePackage, а именно, в виде классов DatabaseReader (Чтение базы данных) и DatabaseUpdater (Обновление базы данных) или классов с похожими именами.
Пакет DatabasePackage обеспечивает уровень взаимного обмена между' приложением и базой данных. Логика приложения (ControlPackage) теперь отделена от изменений источника данных. Любые изменения структур баз данных и протоколов получения данных из базы данных влияют на классы пакета DatabasePackage. Хра-
некие и буферизация данных (пакет Entitypackage) для функций приложения остаются неизменными, поскольку об этом заботится пакет Controlpackage.
Рис. 6.4. Уровни BCED
В действительности, классы пакета Databasepackage выполняют набор и других услуг. Эти дополнительные услуги могут состоять в открытии и закрытии соединения с базой данных, выдаче базе данных указания о подтверждении или откате транзакции, определении параметров времени выполнения для конфигурации базы данных, работе с авторизацией пользователей, извлечении и хранении метаданных об объектах базы данных (таких, как таблицы, столбцы, представления, хранимые процедуры, индексы и т.д.).
Разделение обязанностей, вводимое подходом BCED, можно “донести” до системных проектировщиков и программистов с помощью простого метода задания префиксов имен. Поскольку каждый класс может принадлежать только к одному пакету, его можно поименовать с помощью однобуквенного префикса (В, С, Е или D). Например, класс, помеченный как B_TreeBrowseView, принадлежит пакету Boundarypackage, а класс D_DatabaseUpdater — пакету DatabasePackage.
Системное ПО
Стратегия решения для объектно-ориентированного клиента обычно развивается вокруг программной среды со “строительными инструментами” в виде GUI-интерфейса. При этом решение, возможно, также учитывает используемый способ подключения к базе данных, при котором могут использоваться два основных подхода.
Собственный интерфейс базы данных, предоставляемый многими графическими языками четвертого поколения — 4GL (например, PowerBuilder, Developer 2000, Delphi).
Драйверы ODBC или JDBC для базы данных (например, в составе сред Visual C++, PowerJ++).
Стратегия решения для сервера определяет технологию баз данных. Поскольку “данные остаются навсегда, а приложения появляются и исчезают" (слова Боба Эпштейна (Bob Epstein) из Sybase, цитируются по памяти), стратегия решения для сервера, вероятно, оказывает значительное влияние на клиентскую стратегию. Часто выбирается та среда разработки клиента, которая предоставляется поставщиком СУБД.
К стратегическим решениям по серверу относятся следующие варианты СУБД.
Реляционные базы данных (например, Sybase, Oracle, Informix).
Объектнореляционные базы данных (например, Oracle8, Informix/Illustra, UniSQL).
Объектные базы данных (например, ObjectStore, Versant, Objectivity/DB).
В настоящее время перечисленные три технологии баз данных не конкурируют, они превосходят друг друга по разным вопросам и обращены к различным прикладным областям. В результате, решения по модели базы данных должны основываться на текущих и ожидаемых требованиях приложения.
Стратегия повторного использования
" UML определяет повторное использование (reuse) как "использование ранее существовавших артефактов” [76]. Мы мимоходом уже обсуждали объектноориентированные методы для повторного использования ПО, такие как наследование и делегирование. В данном разделе обратимся к стратегиям повторного использования ПО. Оказывается, что стратегия также влияет на степень детализации, с которой осуществляется повторное использование. Могут применяться следующие степени детализации повторного использования.
Класс.
Компонента.
Идея решения.
В связи со степенью детализации существуют три соответствующие стратегии повторного использования [13], [28], в основе которых лежат следующие программные сущности.
Инструментальные средства (библиотеки классов).
Каркасы.
Шаблоны анализа и проектирования.
Повторное использование инструментальных средств
" Стратегия повторного использования инструментальных средств придает особое значение многократному использованию программного кода на уровне классов. При этой стратегии повторного использования программист “заполняет бреши” в программе за счет осуществления вызовов конкретных классов из некоторых библиотек классов. Основное тело (ядро) программы не подлежит повторному использованию — его пишет программист.
Существует два типа (уровня) инструментальных средств [60].
Базовые инструментальные средства.
Архитектурные инструментальные средства.
Базовые классы (foundation classes) широко представлены объектными программными средами. Они включают классы для реализации элементарных типов данных (такие как String), структурных типов данных (таких как Date) и коллекций (таких как Set, List или Index).
Архитектурные классы (architecture classes) обычно представлены как части системного ПО, такого как операционные системы, СУБД или ПО GUI-интерфейсов. Напри-
мер, когда мы приобретаем объектную СУБД, то фактически получаем архитектурные инструментальные средства, реализующие ожидаемые функциональные возможности системы, такие как поддержка хранения постоянных объектов, выполнение транзакций и обеспечение параллельности.
Повторное использование каркасов
Стратегия повторного использования каркасов (framework) придает особое значение многократному использованию на уровне компонент (компоненты рассматриваются в разд. 6.1.5). В противоположность повторному использованию инструментальных средств каркас предоставляет в распоряжение разработчиков скелет программы. Затем программист “наращивает” этот скелет (настраивает его) за счет написания программного кода, вызовы которого встроены в каркас. Помимо конкретных классов (для самого каркаса) каркас предоставляет в распоряжение программиста массу абстрактных классов, которые он должен реализовать (настроить).
Каркас — это настраиваемое прикладное ПО. Лучшими примерами каркасов служат ERP-системы (Enterprise Resource Planning Systems — системы планирования ресурсов предприятий), такие как SAP, PeopleSoft, Ваап или J.D. Edwards. Однако повторное использование этих систем не основано на чистых объектноориентированных методах.
Объектно-ориентированные каркасы для разработки ИС предлагаются в рамках распределенных компонентных технологий, таких как CORBA, DCOM и EJB (см. разд. 1.1.1). Они известны как “бизнес-обкекты” ("business objects”) — “поставляемые” программные продукты, призванные удовлетворить специфические деловые или прикладные потребности. Например, бизнес-объект может быть каркасом системы бухгалтерского учета с настраиваемыми классами, такими как Invoice (Счет-фактура) или Customer (Клиент).
Хотя каркасы и привлекательны с точки зрения повторного использования, они обладают рядом недостатков. Пожалуй, самым значительным из них является то, что исходное решение на основе “наименьшего общего знаменателя", которое они предлагают, является условно оптимальным, а то и вовсе устарелым. В результате каркасы не дают конкурентного преимущества своим приверженцам и могут оказаться весьма обременительными в стремлении внедрить более современные решения.
Повторное использование шаблонов
Стратегия повторного использования шаблонов (pattern) придает особое значение многократному использованию подходов, при котором в распоряжение разработчиков предоставляются идеи и примеры кооперативного взаимодействия объектов, которые хорошо зарекомендовали себя в практике разработки и которые ведут к понятным и масштабируемым решениям (кооперативное взаимодействие рассматривается в разд. 6.2). Шаблоны могут применяться на этапе анализа или проектирования ЖЦ разработки ПО (отсюда — шаблоны анализа (analysispatterns) и шаблоны проектирования (designpatterns)).
Шаблон — это документально оформленное решение, которое доказало свою работоспособность в ряде ситуаций. Данные ситуации четко обозначены и могут использоваться в качестве “статьи индекса” для поиска приемлемого решения в ходе разработки. Чтобы дать возможность разработчику принять обоснованное решение, необходимо привести перечень всех известных недостатков и побочных эффектов шаблона.
Повторное применение шаблонов во многом носит концептуальный характер, хотя многие проектные шаблоны содержат примеры программного кода для повторного ис-
пользования программистами. Рамки проектного шоблогна (см., например, [28]) определяются кооперацией (разд. 6.2) — обычно они охватывают область более широкую, чем класс, но более узкую, чем компонента. Рамки шаблона анализа (см., например, [26]) зависят от уровня абстракции моделирования, к которой применяется шаблон.
6.1.5. Компоненты
Компонента (component) — это физическая часть системы, фрагмент реализации, программа [8], [48], [76], [88]. Компоненты зачатую воспринимаются как двоичные исполняемые (ЕХЕ-файлы) части системы. Но компонента может быть также частью системы, которая не является непосредственно исполняемым модулем (например, файлом исходного текста программы, файлом данных, динамически компонуемой библиотекой (Dynamic Link Library — DLL) или хранимой процедурой базы данных).
В настоящее время UML определяет пять стандартных стереотипов для компонент [8].
Исполняемая (т.е. непосредственно исполняемый модуль).
Библиотека (т.е. модуль статической или динамической объектной библиотеки).
Таблица (т.е. таблица базы данных).
Файл (т.е. файл исходного текста или данных).
Документ (т.е. документ, предназначенный для восприятия человеком).
Ниже приводится перечень характеристик компонент [76], [88].
Компонента представляет собой независимо развертываемый программный блок (компонента никогда не развертывается частично).
Компонента может служить строительным блоком для стороннего разработчика (т.е. компонента в достаточной мере документирована и самодостаточна, чтобы сторонний разработчик мог “встроить” ее в другие компоненты).
Компонента не обладает тупиковым состоянием (т.е. компоненту невозможно отличить от ее собственных копий; в рамках любого данного приложения присутствует самое большее одна копия конкретной компоненты).
Компонента— заменяемая часть системы, т.е. ее можно заменить другой компонентой, которая согласуется с тем же интерфейсом.
Компонента выполняет четкую функцию и с логической и физической точки зрения образует единое целое. '
• Компонента может быть вложена в другие компоненты.
Обозначение компонент
Графически компонента представляется как прямоугольник с двумя небольшими •прямоугольниками-вставками с левой стороны. Уникальное имя компоненты помещается внутри большого прямоугольника. Между двумя любыми компонентами может быть задано отношение зависимости.
■ На рис. 6.5 показана компонента InvoicingEXE, которая относится к стереотипу Исполняемых компонент.
j «executable»
1' InvoicingEXE
Рис. 6.5. Обозначение компоненты
Диаграмма компонент
Диаграмма компонент показывает компоненты и их взаимосвязь друг с другом. Компоненты могут быть связаны отношениями зависимости. Зависимая компонента запрашивает обслуживание у компоненты, на которую указывает отношение зависимости. Компоненты также могут быть связаны отношениями композиции, т.е. одна компонента может содержать другую.
На рис. 6.6 показаны три компоненты. Компонента InvoicingEXE зависит от двух других. Характер этих зависимостей не определен, поскольку интерфейсы компонент не показаны.
Язык UML допускает моделирование интерфейсов компонент с помощью символа “леденца на палочке” (разд. 5.3.3). Если зависимость между компонентами устанавливается в порядке договоренности через интерфейсы, то другая компонента, которая реализует тот же набор интерфейсов, может заменить одну из компонент, участвующих в отношении.
«stored procedure» MaintainlnvoiceUSP«stored procedure» MaintainlnvoiceUSP«executable»InvoicingEXE«executable»InvoicingEXE«executable» InvoiceDLL«executable» InvoiceDLL
«stored procedure» MaintainlnvoiceUSP
«stored procedure» MaintainlnvoiceUSP
«executable»
InvoicingEXE
«executable»
InvoicingEXE
«executable» InvoiceDLL
«executable» InvoiceDLL
Puc. 6.6. Диаграмма компонент
Компоненты в сравнении с пакетами
Пакет (package) — логическая часть системы (разд. 5.2.3). На логическом уровне каждый класс принадлежит одному пакету. На физическом уровне каждый класс реализуется, по меньшей мере, одной компонентой, а компонента, возможно, реализует только один класс. Абстрактные классы, определяющие интерфейсы, зачастую реализуются более, чем одной компонентой.
Пакеты обычно представляют собой более крупные архитектурные элементы, чем компоненты. Они имеют тенденцию группирования классов по горизонтали— за счет статической близости классов, принадлежащих одной проблемной области. Компоненты— это вертикальные группы классов с близким поведением. Они могут принадлежать разным проблемным областям, однако, вносят вклад в один фрагмент деловой деятельности, возможно, представленный прецедентом.
Описанное выше свойство ортогональности пакетов и компонент затрудняет установление зависимостей между ними. Зачастую ситуация складывается так, что логический пакет зависит от нескольких физических компонент.
Обратитесь к описанию пакетов, представленных в примере 5.10 (разд. 5.2.3.2). Рас- i смотрите пакет Timetable. Предположим, что пакет реализуется как программа на ’ языке C++, которая включает логику распределения университетских аудиторий по I группам. Программа получает доступ к базе данных по аудиториям и группам. Для пре- ! доставления программе этой услуги реализуются две хранимых процедуры.
Изобразите диаграмму компонент, которая показывает зависимости между пакетами и , необходимыми компонентами.
На рис. 6.7 показана модель компонент. Она включает три компоненты: RoomAllocEXE, RoomUSP и ClassUSP. Пакет Timetable зависит от этих компонент.
Рис. 6.7. Пакеты в сравнении с компонентами
Компоненты в сравнении с классами и интерфейсами
Подобно классам компоненты реализуют интерфейсы. Разница между ними двоякая. Во-первых, компонента — физическая абстракция, развертываемая на некотором компьютерном узле. Класс представляет логическую сущность, которая для того, чтобы действовать в качестве физической абстракции, должна быть реализована с помощью компоненты.
■ Во-вторых, компонента показывает только некоторые интерфейсы содержащихся в ней классов. Многие другие интерфейсы инкапсулированы компонентой — они используются только внутри кооперирующимися классами и не видимы другим компонентам.
Интерфейс, который конкретизируется компонентой, может быть реализован в отдельном классе. Подобный класс называется доминантным классом (dominant class) [76]. Поскольку доминантный класс представляет интерфейс компоненты, любой объект внутри компоненты достижим из доминантного класса через связи композиции. “Доминантный класс конкретизирует интерфейс компоненты” [76].
Обратитесь к трем компонентам, представленным в примере 6.1 (разд. 6.1.1.3.3).
Предположим, что компонента RoomAllocEXE инициирует процесс распределения аудиторий по курсам за счет обеспечения для компоненты ciassUSP идентификации i классов. С этой целью реализует интерфейс под названием Allocate.
Компонента ciassUSP выполняет остальную работу, запрашивая подробную информа- : цию об аудитории у компоненты Roomusp. Для предоставления этой услуги Roomusp ; реализует интерфейс под названием Reserve.
На рис. 6.8 показана диаграмма компонент, соответствующая сформулированнымНа рис. 6.8 показана диаграмма компонент, соответствующая сформулированнымРис. 6.8. Отображение интерфейсов на диаграмме компонентРис. 6.8. Отображение интерфейсов на диаграмме компонент
На рис. 6.8 показана диаграмма компонент, соответствующая сформулированным
На рис. 6.8 показана диаграмма компонент, соответствующая сформулированным
Рис. 6.8. Отображение интерфейсов на диаграмме компонент
Рис. 6.8. Отображение интерфейсов на диаграмме компонент
6.1.6. Развертывание
В языке UML трехзвенная архитектура (наподобие той, что показана на рис. 6.2) или любая другая архитектура для системы выражается в виде диаграммы развертывания (deployment diagram). Фактически диаграмма, представленная на рис. 6.2, является допустимой диаграммой развертывания UML, на которой вычислительные ресурсы представлены в виде специальных пиктограмм.
Вычислительные ресурсы (физические объекты времени выполнения) называются узлами (node). Узел обладает, как минимум, памятью и некоторыми вычислительными возможностями (например, клиентский Х-терминал на рис. 6.2). Узел может также быть сервером баз данных наподобие активного (программируемого) сервера.
Обозначение узлов
В UML узел графически представляется в виде куба. Куб может быть обозначен как стереотип. Подобный куб-стереотип может выглядеть как пиктограмма. Каждому узлу присваивается уникальное имя (текстовая строка).
На рис. 6.9 показан узел CorporateDatabaseServer. Стереотип «Sybase» говорит о том, что узел размещен на платформе СУБД Sybase.
«Sybase»Корпоративныйсервербаз данных
Рис. 6.9. Обозначение узла
Диаграмма развертывания
Диаграмма развертывания показывает узлы и взаимосвязи между ними. Узлы могут быть связаны отношениями соединения (connection relationships). Отношение соединения можно поименовать, чтобы указать используемый сетевой протокол (если это подходит) или описания характера соединения каким-либо другим способом. В общем случае отношение соединения представляет собой ассоциацию, и его можно моделировать с использованием типичных свойств ассоциации, таких как порядок, кратность, роли и т.д. (разд. 2.1.3).
На рис. 6.10 показаны два узла на диаграмме развертывания. Отношение соединения download_nightly говорит о том, что узел сервера хранилища данных DataWarehouseServer (функционирующий под управлением ПО IQ от Sybase) каждую ночь загружает данные с узла транзакционной базы данных CorporateDatabaseServer.
Рис. 6.10. Диаграмма развертыванияРис. 6.10. Диаграмма развертывания
Рис. 6.10. Диаграмма развертывания
Рис. 6.10. Диаграмма развертывания
Узлы в сравнении с компонентами
'' Узлы представляют местоположение выполнения компонент. Компоненты функционируют на узлах. Компоненты развертываются на узлах. Узлы вместе с их компо- йентами иногда называются элементами размещения (distribution unit) [8].
На рис. 6.11 показан узел корпоративной базы данных CorporateDatabaseServer. НаузЛе выполняются две хранимые процедуры, которые представлены как компоненты CustomerUSP иInvoiceUSP.
На рис. 6.12 показан альтернативный способ моделирования “включения” компонент в узел. Эту нотацию можно расширить таким образом, чтобы вся диаграмма компонент помещалась на диаграмме развертывания [25].
Корпоративный сервер баз данныхКорпоративный сервер баз данныхCustomerUSPCustomerUSPInvoiceUSPInvoiceUSPРис. 6.11. Узел и его компонентыРис. 6.11. Узел и его компоненты
Корпоративный сервер баз данных
Корпоративный сервер баз данных
CustomerUSP
CustomerUSP
InvoiceUSP
InvoiceUSP
Рис. 6.11. Узел и его компоненты
Рис. 6.11. Узел и его компоненты
6.2. Кооперация
Архитектурное проектирование оказывает влияние на детализированное проектирование в том смысле, что оно определяет целевую программно-аппаратную платформу, с которой должен быть согласован детализированный проект. Помимо этого, детализированное проектирование есть прямое продолжение анализа. Задача заключается в том, чтобы превратить модели анализа в документы детализированного проекта, на основе которых программисты могут реализовать систему.
В ходе анализа мы идем на упрощение моделей, абстрагируясь от деталей, которые служат помехой в представлении определенной точки зрения на систему. При проектировании мы стремимся действовать с точностью до наоборот. Берем одновременно одну из сторон представления архитектуры и добавляем в модель технические детали или создаем качественно новую проектную модель на более низком уровне абстракции.
Мы мимоходом довольно свободно использовали термин коопдЬяуия (collaboration), говоря о множествах объектов, которые кооперируются для выполнения задания (разд. 2.1.1.2 и 2.1.2.2.1). Язык UML использует термин кооперация в тех же целях и связывает с ним специфические методы моделирования. В частности, понятие кооперации используется в UML для задания реализации прецедентов или операций [8], [76].
Обозначение кооперации
Неудивительно, что нотация для кооперации похожа на нотацию для прецедентов. Кооперация обозначается в виде эллипса со штриховыми границами.
На рис. 6.13 показаны две кооперации Browse Student List (Показать список студентов) и Add Student to Course Of fering (Занести студента в список [слушателей] курса). Две кооперации реализуют (через отшпионие реализации (realization relationships)) прецедент Enter Program of Study (Ввод программы обучения).
Заметим, что CASE-средства могут заменить явное моделирование отношения реализации на рис. 6.13 гиперссылками между прецедентом и моделью кооперации [8]. Другими словами, одна или более диаграмм UML, внутренне связанных с помощью CASE-средств, с их прецедентами могут представлять модель кооперации. Проектировщик может перемещаться между прецедентом и моделями кооперации, не прибегая к отношениям реализации.
Add Student to Course Offering
Рис. 6.13. Обозначение кооперации
Диаграмма кооперации
Диаграмма кооперации представляет собой один из видов модели взаимодействия UML (разд. 2.2.5). Второй вид — диаграммы последовательностей (разд. 2.2.5.3). Мы отдаем предпочтение диаграммам последовательностей при анализе и диаграммам кооперации при проектировании (по поводу сравнения этих двух типов диаграмм взаимодействия см. разд. 6.2.3).
Диаграмма кооперации на рис. 6.14 соответствует диаграмме последовательностей на рис. 2.33 (разд. 2.2.5.1). Номера последовательностей фиксируют временные последовательности сообщений. Номера последовательностей необязательны. Для сложных алгоритмов бывает трудно приписать сообщениям и осмысленную временную последовательность, поэтому для выражения временных последовательностей могут потребоваться дополнительные модели (такие как диаграммы видов деятельности или псевдокод).
Заметим, что имена объектов на диаграмме кооперации в действительности представляют роли, которые играют объекты в кооперации. Соответствующая нотация UML выглядит так.
rolename:classname
aConfltem:ConfigurationitemaConfltem:ConfigurationitemaCust: -CustomeraCust: -Customerdisplaycomputer (item_recset)displaycomputer (item_recset)
aConfltem:
Configurationitem
aConfltem:
Configurationitem
aCust: -
Customer
aCust: -
Customer
displaycomputer (item_recset)
displaycomputer (item_recset)
Puc. 6.14. Диаграмма кооперации “DispUy Current Configuration” (Internet-магазин)
Если быть более точными, то роль— это не объект. В языке UML роль— это “классификатор”, представляющий любой объект, который может появиться в различных экземплярах кооперации. Кроме того, один и тот же объект может играть разные роли последовательных кооперациях. В общем случае ролевое имя можно опустить, но перед именем класса необходимо поместить двоеточие, чтобы отличить его от обычного класса [76].
Обозначение сообщений
Структура сообщения соответствует сигнатуре целевого метода (разд. 2.1.2.2). Для успешной отправки сообщений объект-отправитель должен предоставить следующую информацию [60].
Значение уникального идентификатора OID (дескриптор) для целевого объекта. Обычно оно хранится в одном из атрибутов отправителя (с точки зрения программирования — в переменных).
Имя операции (метода) в целевом объекте.
Дополнительно, фактические входные и выходные (возвращаемый результат) аргументы для подстановки вместо соответствующих формальных аргументов метода.
На рис. 6.15 показана альтернативная нотация UML для определения сообщения. Верхняя нотация, приведенная на рисунке, непосредственно отображается в сигнатуру метода (для краткости ключевые слова можно опустить). Средняя нотация использует возвращаемое значение и оператор присваивания вместо выходного аргумента. Нижняя нотация заменяет входные и выходные аргументы направленными маркерами данных.
loanPlease (in amount_req, out amount_g ranted)
loanPlease
' Puc. 6.15. Альтернативное обозначение сообщений
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-дескриптор объекта.
Типы сообщений
Сообщение можно отправить объекту-классу (разд. 2.1.6) или объекту-экземпляру. Обычно сообщения, отправляемые объекту-классу, представляют собой конструкторы (constructors') (предназначенные для создания новых объектов-экземпляров) и деструкторы (destructors) (предназначенные для уничтожения существующих объектов-экземпляров). Остальные типы сообщений (направляемые как объектам-классам, так и объектам-
экземплярам) можно разделить на следующие три группы (альтернативные имена в скобках заимствованы из [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Л. Сравнение замещения и перегрузки
При проектировании моделей взаимодействия следует учитывать, что имя метода может быть замещено или перегружено. Эти два термина обозначают не одно и то же.
Замещение метода (overriding) было рассмотрено в разд. 5.3.4.4.2. Замещение составляет базис полиморфизма. Оно означает, что существует несколько методов с одним и тем же именем в различных классах. Различные реализации одного метода должны выполняться в зависимости от того, какому классу принадлежит целевой объект.
Перегрузка метода (overloading) также означает, что существует несколько методов с одним и тем же именем, но в одном классе. Например, помимо ранее определенного метода loanPlease можно ввести еще один метод loanPlease в класс Bank. Этот метод должен включать дополнительный аргумент, задающий минимальный размер займа, который может получить клиент, как показано ниже
aBankl.loanPlease(in amount_req, minimum_amount, _out amount_granted)
Теперь метод loanPlease перегружен. Выполнение того или иного перегруженного метода зависит от сигнатуры сообщения. Отсюда следует, что установление сигнатуры сообщений — весьма важное мероприятие на этапе проектирования.
Итеративные сообщения и шаблоны
Итеративное сообщение (iteration message) — это сообщение, отправка которого повторяется для нескольких объектов класса. Для обозначения итерации в языке UML используется маркер итерации— звездочка перед меткой сообщения (разд. 2.2.5.1).
Множество объектов, на которые распространяется итеративное сообщение, называется коллекцией (collection). Коллекция может быть набором, списком (неупорядоченным набором) или массивом объектов. На диаграмме кооперации коллекция изображается как комплект (“штабель") объектов (рис. 6.14 в разд. 6.2.2).
В смысле объектно-ориентированного подхода коллекция (набор, список и т.д.) сама является классом. Естественно, многие среды объектно-ориентированного программирования по умолчанию включают соответствующие классы с именами Set, List, FixedArray, VarryingArray, Btreelndex и т.д. Эти классы-коллекции можно затем использовать для включения в них объектов, определяемых пользователем классов. Типичным примером использования коллекции классов может служить реализация связей отношений ассоциации или агрегации с кратностью "многие" (разд. 2.1.3.2).
Рассмотрим рис. 6.14 и итеративное сообщение *getConf (out item_rec) от объекта класса аСотр к объекту 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. Отношение агрегации с указанием ролейРис. 6.16. Отношение агрегации с указанием ролей
Рис. 6.16. Отношение агрегации с указанием ролей
Рис. 6.16. Отношение агрегации с указанием ролей
Configurationitem item_type: String item_descr: String is part of comp: ComputerConfigurationitem item_type: String item_descr: String is part of comp: Computer• Computer, computer_name: String standard_price: Currency
Configurationitem item_type: String item_descr: String is part of comp: Computer
Configurationitem item_type: String item_descr: String is part of comp: Computer
has cont item: Ust<Configurationltem>
Puc. 6.17. Отношение агрегации, уже реализованное с использованием атрибутов
Определение шаблона играет важную роль в понимании области действия итеративного сообщения. Сообщение *getConf(out item_rec) распространяется на объекты класса Configurationitem, входящие в список List. Список образует текущее значение атрибута has_conf_item. Если быть более точным, список содержит OID-значения (дескрипторы) всех объектов Configurationitem, включенных в конкретный объект-компьютер Computer.
G. Автосообщения
Объект может отправить сообщение самому себе. Автосообщение (self message) означает локальный вызов — один метод вызывает другой метод одного и того же объекта. Название автосообщение заимствовано из языка Smalltalk. В языках C++ и Java автосообщению соответствует термин this применительно к объекту. Соответствующий объект представляет собой константу (не переменную), которая хранит идентификатор (OID) объекта [60].
Автосообщение может встретиться в последовательности кооперативных сообщений (разд. 6.2.2.3), которые воздействуют на тот же класс до передачи управления другому классу. Оно может также встретиться, если управление возвращается отправителю и следующее сообщение вызывает метод отправителя (отправитель и получатель — один и тот же объект).
На рис. 6.18 приведен пример двух автосообщений (currentLeave и longServiceLeave), которые активизируются в результате запроса на вычисление значения суммы, подлежащей выплате работнику за отпускной период — leaveEntitlement.
Автообъект может быть передан в некоторых редких случаях, как аргумент в сообщении, т.е.
messagename(self)
При передаче синхронных сообщений (synchronous message) (во время которой отправитель должен дождаться возврата управления от целевого объекта прежде, чем завершить выполнение) пересылка OID-отправителя, как правило, не требуется. Возврат управления выполнением происходит автоматически, по крайней мере в большинстве объектно-ориентированных сред программирования.
longServiceLeave!)
currentLeave!)
leaveEntitlement!) ]|
* anEmployee:
Employee
Рис. 6.18. Автосообщения•
Асинхронные сообщения
При передаче асинхронных сообщений (asynchronous message) объект-отправитель не должен дожидаться, пока целевой объект закончит свою работу, а продолжать выполнение другого потока управления. Передача асинхронных сообщений предполагает существование множественных потоков управления (параллелизм (concurrency)) в программе.
Для обозначения асинхронных сообщений в UML используются “односторонние" стрелки. Объект те (я) на рис. 6.19 порождает два потока управления, отправляя два асинхронных сообщения объектам myCoffeeMaker (моя кофеварка) и myRadio (мое радио).
Передача асинхронных сообщений характерна для инженерных приложений и приложений реального времени. Типичные бизнес-приложения, выполняющие деловые операции, по большей части базируются на синхронных сообщениях.
Рис. 6.19. Передача асинхронных сообщений
Обратные вызовы
Обратные вызовы упоминались ранее в этой книге в контексте наследования (разд. 5.3.4.4.2). Обратный вызов (callback) — это обращение "снизу-вверх” (если смотреть по связи отношения) к отправителю сообщения. Типичным примером использования обратного вызова служит передача асинхронного сообщения, при котором отправитель (абонент (subscriber)) заявляет целевому объекту (получателю (listener)), что ему необходимо получить информацию о завершении действия, выполняемого получателем. Целевой объект (тот, на который указ геает связь отношения) должен отправить асинхронное "сообщение назад отправителю.
На рис. 6.20 приведена расширенная диаграмма кооперации, показанная на рис. 6.19, включающая обратный вызов от объекта myCoffeeMaker к объекту me. Как- никак я (те) жду кофе, и мне совсем не хочется прерываться, чтобы посмотреть, готов ли он — об этом мне просигналит сама кофеварка (myCof feeMaker).
Обратные вызовы — удобный механизм, однако, их очень трудно программировать. Чтобы обратный вызов работал надлежащим образом, получатель должен иметь возможность каким-либо образом наблюдать за состоянием и изменением состояния абонента прежде, чем отправить обратный вызов. Отправлять мне сообщение о том, что кофе готов (cof feeReady), когда я уже в пути, не очень умная затея!
makeCoffee
Рис. 6.20. Обратный вызов при передаче асинхронных сообщений
Диаграммы последовательностей и диаграммы кооперации
Диаграммы кооперации и диаграммы последовательностей эквивалентны в том смысле, что их можно автоматически преобразовать одну в другую. В то же время эти два типа диаграмм выделяют различные аспекты взаимодействия объектов (и иногда эти различные аспекты в процессе преобразования могут быть утеряны).
Диаграммы последовательностей придают особое значение временной последовательности сообщений между объектами. Они неудобны и не дают необходимой точности при представлении альтернативных путей сообщений — то, в чем отлично зарекомендовали себя диаграммы видов деятельности. Кроме того, они громоздки при представлении кооперативных действий многих объектов (хотя тщательное упорядочение жизненных линий объектов зачастую может улучшить удобство восприятия диаграммы в целом).
Диаграмма кооперации может явно отображать статические отношения между объектами, по которым может протекать поток сообщений. В результате, диаграммы кооперации обеспечивают большую точность при визуализации таких вещей, как полиморфное сообщение. Схема диаграмм кооперации позволяет отображать большее количество объектов на той же графической площади. Сообщения могут быть полностью определены и аннотированы.
Мы предпочитаем использовать диаграммы последовательностей для моделей анализа и диаграммы кооперации для проектных моделей. Оба типа диаграмм можно дополнить диаграммами видов деятельности. При изображении диаграмм видов деятельности можно использовать уровень абстракции, соответствующий уровню абстракции связанных с ними диаграмм последовательностей или кооперации.
Реализация прецедентов
Кооперация значит для проекта то же самое, что прецеденты для анализа. Если прецеденты направляют анализ, то кооперация объектов направляет проектную деятельность. Прецеденты реализуются с помощью кооперативных действий. Из-за различия в уровне абстракции каждый прецедент реализуется несколькими схемами кооперации.
Кооперативные взаимодействия имеют две стороны: структурную и поведенческую. Структурная сторона представляет статический аспект кооперации. Он представляется подмножеством диаграмм классов, соответствующих рамкам кооперации. Диаграмма классов детализируется (в сравнении со своей версией, полученной в результате анализа) за счет подробностей реализации. В частности, осуществляется идентификация сигнатур операций классов.
Поведенческая сторона представляет динамику, которая показывает, каким образом осуществляется кооперативное взаимодействие статических элементов. Поведенческий аспект моделируется именно в виде взаимодействий (разд. 2.2.5). Помимо диаграмм последовательностей (разд. 2.2.5.3), диаграммы кооперации часто используются для спецификации поведения объектов в ходе кооперативных действий. На практике структурный и поведенческий аспекты кооперации по возможности следует разрабатывать параллельно.
Структурный аспект кооперации
Для решения задачи необходимо рассмотреть все дополнительные классы и дополнительные атрибуты и операции, необходимые для поддержки кооперации. Нам требуется детализировать диаграмму классов, выработанную в ходе анализа. При этом следует руководствоваться диаграммой последовательностей для прецедента, разработанной в ходе анализа (рис. 4.14, разд. 4.3.3.3).
Как видно из рис. 6.21, к диаграмме классов добавлено всего несколько классов. Пограничный класс ProgramEntryWindow получен на основе диаграммы последовательностей, показанной на рис. 4.14. Класс PrereqCourse требуется для установления отношения “многие ко многим” проверки обязательных условий. Класс Grade (Оценка) добавлен для полноты, однако, в рассматриваемом прецеденте больше использоваться не будет. Прошлые оценки студентов хранятся в классе AcademicRecord. Класс Grade содержит отметки и оценки, которые студент получает при прохождении текущего курса.
Рис. 6.21. Структурный аспект кооперации (Запись на университетские курсы)
Атрибуты ранее определенных классов не изменились. Новые классы содержат атрибуты, которые должны быть самоочевидными. Основное добавление в детализн рованную диаграмму классов состоит в определении операций. Операции цепосрсд ственно выводятся из диаграммы кооперации, представляющей поведенческий ас пект кооперации (см. след. разд.).
Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Мы рассматри- ; ваем прецедент "Enter Program of Study” (“Ввод программы обучения"). Прецедент * управляет записью студентов на предлагаемые учебные курсы.:
Для целей этого примера мы предполагаем, что прецедент проверяет (прежде, чем студент будет записан), внес ли студент плату и удовлетворяет ли студент предваритель- ' ным условиям набора на курсы.;
Наша задача состоит в том, чтобы расширить диаграмму классов на рис. 4.16 (пример 1 4.9) таким образом, чтобы смоделировать структурный аспект кооперации, необходимый для описанного сценария.i
Поведенческий аспект кооперации
На рис. 6.22 представлено решение для примера. По сравнению с диаграммой последовательностей (рис. 4.14) в диаграмму кооперации введено два объекта anAcademicRecord и aPrereqCourse. Эти объекты необходимы для осуществления проверки оплаты студентом курса и выполнения обязательных условий прежде, чем студент может быть зарегистрирован на предлагаемом курсе (объект Courseoffering).
: Data'Entry[c_check='no’]destroyPerson[s_check='no’]destroyfeesPaid(out paid): Data'Entry[c_check='no’]destroyPerson[s_check='no’]destroyfeesPaid(out paid)
: Data'Entry[c_check='no’]destroy
Person[s_check='no’]destroyfeesPaid(out paid)
: Data'Entry[c_check='no’]destroy
Person[s_check='no’]destroyfeesPaid(out paid)
Puc. 6.22. Поведенческий аспект кооперации (Запись на университетские курсы)
| Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Наша задача со- [ стоит в создании диаграммы кооперации, представляющей поведенческий аспект коо- • перативного взаимодействия, как определено в примере 4.9. Диаграмма кооперации| Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Наша задача со- [ стоит в создании диаграммы кооперации, представляющей поведенческий аспект коо- • перативного взаимодействия, как определено в примере 4.9. Диаграмма кооперации
| Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Наша задача со- [ стоит в создании диаграммы кооперации, представляющей поведенческий аспект коо- • перативного взаимодействия, как определено в примере 4.9. Диаграмма кооперации
| Обратитесь к примеру 4.9 (разд. 4.2.3.3) и примеру 4.17 (разд. 4.3.3.3). Наша задача со- [ стоит в создании диаграммы кооперации, представляющей поведенческий аспект коо- • перативного взаимодействия, как определено в примере 4.9. Диаграмма кооперации
’ должна быть детализацией диаграммы последовательностей на рис. 4.14 (пример 4.17).
Реализация операций
Кооперацию можно также использовать для моделирования реализации более сложных операций [8]. С этой целью можно использовать как структурные, так и поведенческие аспекты.
Модели кооперации стоит применять только для сложных операций, требующих кооперативного взаимодействия нескольких объектов. Более простые операции— ограниченные одним-двумя классами — лучше моделировать с помощью диаграмм видов деятельности, в особенности, если эти операции сильны алгоритмически. Этот же принцип применим в отношении более простых операций, представляющих собой компоненты более сложных операций, которые моделируются с использованием кооперации.
Q |Пример М^Запмсь на университетские курсы
; Обратитесь к примерам 4.18 (разд. 4.3.4.3), 6.3 (разд. 6.2.4.1) и 6.4 (разд. 6.2.4.2). Рас
: смотрите сообщение addstudent (stdOID) на рис 6.22 (пример 6.4).
I Наша задача состоит в разработке диаграммы видов деятельности для реализации опе- : рации Courseoffering.addStudent. Операция должна добавлять студента в список > студентов, проходящих данный курс обучения (атрибут courseoffering, std). Атрибут вводится как шаблон list<Student> (рис. 4.15, пример4.18).
' Прежде, чем студент добавляется к списку слушателей курса, система осуществляет > проверку, чтобы определить, по-прежнему ли открыт прием на курс. Это необходимо, даже если аналогичная проверка была выполнена непосредственно перед инициирова-
! нием события addstudent (stdOID) (рис. 6.22). В системах баз данных с высоким ; уровнем распараллеливания операций статус предлагаемого курса (прием открыт или , закрыт) мог за это время измениться.
i После добавления студента в список слушателей курса -. Courseoffering наш алгоритм \ должен зафиксировать противоположную связь в объекте : student. Чтобы установить ■ обратный указатель из объекта : Student на объект : Courseoffering, первый должен ! быть обновлен.
Решение для примера показано на рис. 6.23. Рамки диаграммы видов деятельности ограничены классом Courseoffering за исключением необходимости взаимодействия с классом Student для поддержания ссылочной целостности между связями.
Наконец, наиболее очевидные операции можно моделировать с использованием псевдокода или непосредственно реализовать программно. Программа, которая реализует подобную операцию, по-прежнему может быть включена в UML-модель в качестве примечания или присоединенного документа.
Событие (сообщение) addStudent активизирует деятельность (метод) addStudent. Внутреннее сообщение areYouOpen активизирует метод areYouOpen. Вид деятельности areYouOpen сравнивает квоту с количеством уже записавшихся студентов, чтобы прийти к утешению. Проверка осуществляется с помощью внутреннего илимнительного действия.
Если утешение отрицательно, объект Courseoffering переходит в состояние С Leased ([Прием] закрыт). В противном случае он будет находиться в состоянии Open. Выполнение диаграммы деятельности должно завершиться при достижении состояния Closed.
При нахождении диаграммы (и объекта 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), используя их применительно к одной проблемной области. Мы обратимся как к архитектурным вопросам (пакеты, компоненты, узлы), так и к вопросам детализированного проектирования (кооперация). Во-вторых, детализиру-
ем модели анализа, разработанные в разд. 2.2. А именно, добавим проектные подробности и расширим существующие модели, чтобы эффективно превратить их в проектные документы, хотя и по-прежнему на относительно высоком уровне абстракции.
Рамки наставления ограничены понятиями, введенными до сих пор в книге. Детализированное проектирование пользовательского интерфейса (глава 7), баз данных (глава 8) и программной логики (глава 9) не рассматриваются.
Проектирование пакетов
В разд. 5.2.3 мы отметили, что пакеты могут объединять в группы классы или другие элементы моделирования, чаще всего — прецеденты. При использовании в ходе анализа пакеты обычно применяются для обозначения основных групп прецедентов. При проектировании пакеты используются наиболее характерным способом — для группирования классов. Следовательно, можно выделить две основные категории пакетов.
Пакеты прецедентов.
Пакеты классов.
Использование моделей пакетов оправдано только при структуризации больших систем. Небольшие системы можно понять и управлять ими, не прибегая к помощи пакетов. Для подобных систем обычно достаточно уровня модульности, который обеспечивают прецеденты. Иногда пакеты играют роль своеобразных “архитектурных объемов", призванных дать возможность приспособиться к ожидаемому росту масштабов системы или зафиксировать тот факт, что первоначальное множество прецедентов и классов по мере продолжения разработки и продвижения детализированного проектирования будет расти.
Пакеты классов, в частности, эволюционируют в ходе проектирования по мере того, как к модели классов добавляются новые пограничные и управляющие классы, а также классы баз данных (напомним читателю, что диаграмма классов, построенная в результате анализа, идентифицирует и связывает между собой классы-сущности— к другим типам классов при проектировании фактически не обращаются). Соответственно, модель пакета класса играет ведущую роль при проектировании. Модель пакета прецедентов практически не используется за пределами этапов проектирования, поскольку модель пакета классов довольно эффективно заменяет ее.
Пакеты прецедентов
Обратитесь к наставлению по анализу для приложения Internet-магазин (разд. 2.2). Рас; смотрите диаграмму прецедентов на рис. 2.24 (разд. 2.2.2.3). Более пристальный [взгляд на спецификацию для приложения Internet-магазин приводит нас к заключению, что модель прецедентов неполна.
| В процессе изучения и документирования уже выявленных прецедентов мы определен- 1 но должны обнаружить дополнительные прецеденты. Новые прецеденты могут быть । расширением существующих прецедентов или входить в их состав (разд. 4.3.1.2), либо * они могут означать прецеденты, которые были упущены из виду при первоначальном = анализе требований.
- В любом случае мы предполагаем, что новые прецеденты значительно усложнят систе- j му, и поэтому нам кажется целесообразным структурировать существующие прецеден- j ты в виде пакетов. Пакеты станут играть роль “функциональных объемов" для размеще- । ния в них существующих и новых прецедентов.
i В данном примере мы конструируем диаграмму пакетов прецедентов, которые должны { вобрать в себя существующие прецеденты и обеспечить адаптацию к их росту в будущем.
Наше решение для примера представлено на рис. 6.24. Из рисунка видно, что мы выделили пять пакетов и назначили им прецеденты (рис. 2.24). На рисунке также показаны отношения зависимости.
Наверное не удивительно, что пакеты на рис. 6.24 выстроились в соответствии с последовательностью выполнения бизнес-процессов для приложения Internet-магазгт. Они отражают порядок, в котором клиенты, приобретающие компьютер, используют Web-страницы и формы, отображаемые броузером.
Рис. 6.24. Пакеты прецедентов (Internet-магазин)Рис. 6.24. Пакеты прецедентов (Internet-магазин)
Рис. 6.24. Пакеты прецедентов (Internet-магазин)
Рис. 6.24. Пакеты прецедентов (Internet-магазин)
Пакеты классов
Лучший способ “расправиться” с примером — “сымитировать систему” и представить, что необходимо сделать, чтобы принять заказ клиента на сконфигурированный компьютер. Первый очевидный вывод состоит в том, что система справляется с двумя отдельными функциями: конфигурирование компьютера и ввод заказа. Эти две функции требуют отдельных GUI-окон. В наставлении по анализу мы идентифицировали только два пограничных класса, однако, можно не сомневаться, что каждая функция может потребовать сво-
его набора GUI-объектов. Следовательно, можно создать два пакета: ConfigurationGUI (GUI-интерфейс для конфигурирования) и OrderGUI (GUI-интерфейс для заказа).
>™»« ", . " ;< XMAS'S .,*--му . Kt„-- .i.lt-wMS •#•/ . Kk:V4.. • iwi ■."nr '- X
|ф91^|^ие&1?^^
i Обратитесь к наставлению no анализу для приложения Internet-магазин (разд. 2.2). J Вполне естественно, что большинство классов, определенных нами в разд. 2.2, пред> ставляют постоянные объекты базы данных (“бизнес-объекты”). Более полная модель 1 для системы может потребовать идентификации классов прикладной программы. Это ? можно выполнить во время проектирования кооперативных взаимодействий позже в этом наставлении.
| Даже если мы еще не определили классы прикладной программы, можно сделать пред- t положения относительно пакетов, которые должны группировать классы в связанные ; модули в соответствии с подходом BCED (разд. 6.1.3.2). Наша задача в этом примере ( заключается в том, чтобы продумать возможный состав и структуру пакетов для прило- ; жения “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.25 представлены описанные выше пакеты. На нем также показаны основные зависимости. Зависимости носят первоначальный и небесспорный характер. В отсутствие знания всех классов и связей взаимодействия между ними между пакетами можно установить только гипотетические зависимости. Основной принцип состоит в том, что пограничные пакеты зависят от управляющих пакетов, а те, в свою очередь, — от пакетов сущностей. Наконец, пакеты сущностей зависят от пакетов баз данных.
Рис. 6.25. Пакеты классов (Internet-магазин)
Заметим, что зависимости между пакетами нетранзитивны [25]. Например, на рис. 6.25 изменения в рамках пакета Customers могут влечь за собой изменения в ConfigureProcess и OrderPlacement, но не в ConfigurationGUI и OrderGUI. Нетранзитивность, конечно, необходима для достижения меньшей сложности в иерархических или квазииерархических структурах (разд. 5.2.2).
Еще одним фактором сложности являются уиклы в структурах зависимости. В принципе, циклов следует избегать [48]. На практике иногда циклов очень трудно избежать, в особенности между пакетами на одном и том же уровне иерархии [25].
Проектирование компонент
Компоненты— это физические части системы. Следовательно, проектирование компонент нельзя отделить от платформы реализации. Приложение Internet-магазин — это Web-приложение с сервером баз данных. Другие аспекты платформы реализации нами на определялись.
Проектирование компонент требует знания платформы реализации. Поскольку мы не намерены в этой книге выступать в защиту каких-либо конкретных решений или поставщиков ПО, все предположения относительно платформы реализации будут строиться на достаточно общем уровне.
. Реализация 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 могут удаляться или не удаляться с клиентской машины.
Чтобы придать страницам, отображаемым на клиентской машине, динамичность, используются сценарии или апплеты. Сценарий (или скрипт (script)) (например, написанный на языке JavaScript) представляет собой программу, выполняемую броузером в режиме интерпретации. Апплет (applet} — это скомпилированная компонента, которая выполняется в контексте броузера, однако, имеет лишь ограниченный доступ к другим ресурсам клиентской машины (из соображений безопасности).
Web-страница может также включать сценарии, выполняемые сервером. Подобная страница называется серверной страницей (server page). Серверная страница имеет доступ ко всем ресурсам сервера баз данных. Серверные страницы управляют клиентскими сеансами, размещают cookies в среде броузера и строят клиентские страницы (т.е. строят страничные документы из серверных бизнес-объектов и отправляют их назад клиенту).
Чтобы обеспечить доступ сценариев, содержащихся в серверных страницах, к базам данных, используются стандартные библиотеки доступа к данным. К типичным технологиям, позволяющим реализовать эту возможность, относятся ODBC (Open Database 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 Language), 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-системой без установления соединения. Более сложный механизм соединения клиента с сервером превращает Internet в распределенную объектную систему. В распределенной объектной системе объекты идентифицируются с помощью уникальных OID (разд. 2.1.1.3) и взаимодействуют за счет получения OID друг друга. Главными механизмами при этом выступают техно-
логии CORBA, DCOM и EJB (разд. 1.1.1). При использовании данных технологий объекты могут взаимодействовать без использования протокола HTTP или Web-сервера в качестве посредника [15].
Диаграмма компонент
Обратитесь к приведенному выше разделу 6.3.2.1 и предложите диаграмму компонент для приложения Internet-магазин (разд. 2.2). Исходите из предположения, что компонента — I это цельный функциональный модуль с четким интерфейсом, так что она вполне может выступать в качестве заменяемой части системы. Поскольку платформа реализации для при- . ложения Internet-магазин не определена, идентификация более мелких компонент (таких как библиотеки, хранимые процедуры и т.д.) на этом этапе невозможна.Обратитесь к приведенному выше разделу 6.3.2.1 и предложите диаграмму компонент для приложения Internet-магазин (разд. 2.2). Исходите из предположения, что компонента — I это цельный функциональный модуль с четким интерфейсом, так что она вполне может выступать в качестве заменяемой части системы. Поскольку платформа реализации для при- . ложения Internet-магазин не определена, идентификация более мелких компонент (таких как библиотеки, хранимые процедуры и т.д.) на этом этапе невозможна.
Обратитесь к приведенному выше разделу 6.3.2.1 и предложите диаграмму компонент для приложения Internet-магазин (разд. 2.2). Исходите из предположения, что компонента — I это цельный функциональный модуль с четким интерфейсом, так что она вполне может выступать в качестве заменяемой части системы. Поскольку платформа реализации для при- . ложения Internet-магазин не определена, идентификация более мелких компонент (таких как библиотеки, хранимые процедуры и т.д.) на этом этапе невозможна.
Обратитесь к приведенному выше разделу 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 (Покупка).
Последняя компонента, которую мы выделяем в нашем наставлении, должна обрабатывать выполнение и отслеживание заказа. С точки зрения клиента она должна
обеспечивать возможность просмотра состояния заказа с помощью Web-страницы (после ввода номера клиента и номера заказа). Эту компоненту можно назвать OrderTracking (Отслеживание заказа).
Рассмотренные выше пять компонент показаны на рис. 6.26. Интересно отметить сходство этой диаграммы с пакетами прецедентов на рис. 6.24, что неудивительно, поскольку пакеты прецедентов и компоненты представляют собой функциональные модули с четкими границами. Пакеты прецедентов —логические функциональные блоки — не оказывают влияния на способ окончательного построения системы, а если система проста, то нет даже нужды в их конструировании. Компоненты — это реальные независимо развертываемые физически блоки — требуют тщательного проектирования и реализации даже для небольших систем.
ProductListProductListProductDisplayProductDisplayттPurchasePurchaseТТOrderTrackingOrderTrackingРис. 6.26. Диаграмма компонент (Internet-магазин)Рис. 6.26. Диаграмма компонент (Internet-магазин)ConfigurationConfiguration
ProductList
ProductList
ProductDisplay
ProductDisplay
т
т
Purchase
Purchase
Т
Т
OrderTracking
OrderTracking
Рис. 6.26. Диаграмма компонент (Internet-магазин)
Рис. 6.26. Диаграмма компонент (Internet-магазин)
Configuration
Configuration
Проект развертывания
Характер Internet-систем без установления прямого соединения (разд. 6.3.2.1) делает развертывание (deployment) Web-приложений значительно более сложной задачей, чем развертывание приложений баз данных в архитектуре клиент/сервер. Чтобы приступить к развертыванию, требуется установить Web-сервер в качестве пункта маршрутизации между всеми7броузерами клиентов и базой данных.
Если проблема управления сеансами не может быть удовлетворительно решена с помощью технологии cookie, необходимо привлекать на помощь технологию распределенных объектов. Развертывание распределенных объектов может потребовать размещения отдельных архитектурных элементов— сервера приложений— между Web- сервером и сервером баз данных.
Проект развертывания должен обращаться к вопросам безопасности. Безопасная передача данных и протоколы шифрования — еще один аспект требований со стороны проекта развертывания. Кроме того, необходимо тщательное планирование с учетом сетевой загрузки, Internet-соединений, резервных копий и т.д.
Развертывание Web-приложений
Архитектура развертывания, способная поддерживать более сложные Web- приложения, включает четыре звена вычислительных узлов.
Клиентский Web-броузер.
Web-сервер.
Сервер приложений.
Сервер баз данных.
Броузер клиентского ^зла можно использовать для отображения статических или динамических Web-страниц. Страницы, включающие сценарии и апплеты, можно загружать и выполнять в рамках броузера. Клиентский броузер можно оснастить дополнительными функциональными возможностями, такими как элементы управления ActiveX или JavaBeans. Выполнение программы приложения на клиентской машине, но вне броузера, может удовлетворить другие требования к GUI-интерфейсу.
Web-cepeep обрабатывает запросы на страницы, поступающие от броузера, и динамически генерирует страницы и программный код для выполнения и отображения на клиенте. Web-сервер также обеспечивает настройку и параметризацию сеансов работы пользователя.
Сервер приложений необходим в том случае, когда в реализации используются распределенные объекты. Он управляет бизнес-логикой. Бизнес-компоненты публикуют свои интерфейсы для других узлов через интерфейсы компонент, такие как CORBA, DCOM или EJB.
Бизнес-компоненты инкапсулируют постоянные объекты, хранимые в базе данных, чаще всего в реляционной базе. Они взаимодействуют с сервером баз данных через протоколы связи с базами данных, например, такими как JDBC или ODBC. Узел базы данных обеспечивает масштабируемое хранилище данных и многопользовательский доступ к нему.
Развертывание диаграмм
Обратитесь к приведенному выше разделу 6.3.3.1 и предложите диаграмму разверты- ; вания для приложения Internet-магазин. В частности, рассмотрите вопрос о том, необ- ; ходимо ли использование для приложения Internet-магазин сервера приложений. :
Как показано на рис. 6.27, приложение Internet-магазин можно развернуть без отдельного сервера приложений. Программы, содержащиеся в Web-страницах, могут выполняться Web-сервером. Потенциальным преимуществом сервера приложений является то, что хранимые на нем компоненты приложения могут повторно использоваться другими Web-приложениями для вызова той же бизнес-логики. Однако Internet-магазин— автономная система и вряд ли можно указать другие Web- приложения, которые могли бы извлечь пользу из ее бизнес-логики.
Рис. 6.27. Диаграмма развертывания (1п1егпекмагазин)
Проектирование кооперативных взаимодействий
В начале этой главы объяснялось, что системное проектирование разделяется на архитектурное проектирование и детализированное проектирование. Проектирование пакетов, компонент и узлов относится к архитектурному проектированию. Детализированное проектирование сосредоточивается на кооперации (разд. 6.2).
Кооперативные взаимодействия определяют реализацию прецедентов и реализацию более сложных операций (простые операции не следует моделировать как кооперативные). Проектирование кооперативных взаимодействий неизменно приводит к уточнению (модификации и расширению) существующих диаграмм классов и выработке новых диаграмм кооперации (либо к детализации существующих диаграмм последовательностей). Другие типы диаграмм, в частности диаграммы состояний, также могут потребовать разработки или уточнения.
Детализация прецедентов
Важным побочным результатом (или даже предпосылкой) проектирования кооперации является уточнение прецедентов. Прецеденты, зафиксированные в виде документа при проведении анализа требований, как правило, не достаточно детализированы для проектирования кооперации. Спецификации прецедентов необходимо уточнить в проектной документации. Прецеденты, представленные более подробными спецификациями, должны включать требования системного уровня, оставаясь, в то же время, на точке зрения субъектов.
Если на этапе анализа на управлении требованиями (разд. 3.4) концентрировались не слишком большие усилия, то теперь наступает последняя возможность достичь большей формализации и строгости в их определении. Требования следует подвергнуть тщательной классификации и пронумеровать их. Чтобы обеспечить надлежащее управление изменениями и прослеживаемостью требований, их следует поместить в репозиторий CASE-системы. (Значение управления требованиями выходит далеко за рамки анализа требований на ранних фазах проектирования. Эти вопросы рассматриваются в главе 10.)
Нумерация и структурирование требований
Требования следует пронумеровать (разд. 3.4.1), структурировать (разд. 3.4.2). Названные виды деятельности лучше всего осуществлять с помощью CASE-средств. Попытки отслеживать изменения требований вручную обречены на провал. В то же время CASE-средства значительно облегчают процесс перенумерации и реструктуризации требований.
На рис. 6.28 показана часть документа-спецификации прецедентов с пронумерованными требованиями. Требования пронумерованы с использованием десятичной системы Девея (Dewey), при этом каждое требование обозначено префиксом UC (Use Case— прецедент). Префикс полезен в том случае, когда документ описания прецедентов содержит более одного типа требований. Заметим, что требования заключены в квадратные скобки, подчеркнуты и отображаются в зеленом цвете (в вопросе цвета вы уж нам поверьте).
Tlmee New RomanTlmee New RomanThe document “use Case Specification: Update Order Status” describes how order can beThe document “use Case Specification: Update Order Status” describes how order can beUse Case Specification: Order Configured Computer
Tlmee New Roman
Tlmee New Roman
The document “use Case Specification: Update Order Status” describes how order can be
The document “use Case Specification: Update Order Status” describes how order can be
.1 Brief Description
A customer fills in and submits a purchase order form The system verifies the details and confirms or rejects the order.
. Flow of Events
2.1 Beak Flow2.1 Beak FlowП.ТС1 S1 2 E№laaal,C<ry mfc-rmation к .limls-.t-d Ь»кя the title
2.1 Beak Flow
2.1 Beak Flow
order.__Ysu c*n._aiiMl.ixiir crdsr.jritizmt^^^bears Jr cct the orda'
issicn You cancel submitted ord#* by using W^b. ^rnau. fax-x гЛоп-?.''!
Puc. 6.28. Фрагмент документа описания прецедентов, поддерживаемого с помощью CASE-системы
МН—№
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 ^sic-EJo
False False False False5 False False:
False False
False1 False; False: False' False ■ False I False; False?
Puc. 6.29. Управление требованиями с помощью CASE-системы
Проектная документация по прецедентам
I Обратитесь к документу по анализу прецедентов для приложения Internet-магазин, при- 1 веденному в табл. 2.2 разд. 2.2.2.4. Этот документ описывает прецедент "Order Config-
( ured Computer" ("Заказ сконфигурированного компьютера”). Данный документ недоста- Е точно подробный для разработки проекта кооперации объектов.
; Наша цель на этом шаге наставления заключается в уточнении документа описания
прецедентов таким образом, чтобы он представлял собой спецификацию прецедентов проектного уровня. Детализированный документ должен быть организован аналогично тому, как показано на рис. 6.28. Фактически, рис. 6.28 и 6.29 представляют собой часть решения для данного шага наставления.
Соответствующий текст документа описания прецедента приведен ниже. Заметим, что этот документ можно отпечатать в формате, отличном от приведенного здесь. Например, можно подавить отображение и печать номеров прецедентов.
(Поскольку приводимый ниже документ-спецификация носит иллюстративный характер и связь описанных в ней действий клиента и функций системы с табл. 2.2 разд. 2.2.2.4 легко пролеживается, для удобства читателей она полностью переведена на русский язык. Прим, ред.)
Спецификация прецедента: “Заказ сконфигурированного компьютера”
[UC15 Заказ сконфигурированного компьютера]
Краткое описание
Клиент заполняет и отправляет форму заказа на покупку. Система проверяет детальную информацию и подтверждает или отвергает заказ.
Поток событий
Основной поток
ШЫМ Система отображает Форму мола адкам додне.Вводзаказа бооузвпа клиента. Форма состоит из следующих цуммол]
HJQlgt 1Л Фсомд имеет заголовок Заказывайте кс№!ртео.1
IUC15.1.2 Поя заголовком отображается поясняющая инАосмация-1
Прикопим текст поясняющей инФсимации:
"Заполните. пожалуйста. поля Форму. Приглашения для ввела
отправки Формы нажмите капку ->тедавитщ если же вы решили не продолжать заполнение, Бы можете отказаться ст своего заказа без всякого штрафа, в течение 24-х .масса с момента отправки заказа. Вы можете отказаться от отдавленного заказа, прибегнув к помаши Web, электронной почты, факса или телефона, ”1 Описание того, каким образом клиент может отказаться от заказа, содержится в документе “Спецификация педивцентт Обновление статуса заказа”,
[UC15.1.3 Реквизиты псстаЕкм!,
ШС15.1.3.1 К требуемым реквизитам доставки относится; имя, страна, город. удина- купье^кие направления,!
[UC15.1.3.2 К дополнительным реквизитам доставки относятся: ВИГОРОА. шхат. г^^вуйкод.!
ГЦС15.1.4 Контактная информация, утличная от той, -чцедач предоставляется как реквизиты доставки, 1
Г.ЦС15.1,4,1 Предпочтительные средства для контактов;
электронная почта, телефон. Факс, почта, курьерская почта. 1
ШС15.1.4.2 В качестве сбяаательндй^днтакшоПинФормашм следует указать один из следующих реквизитов; электронная почта, телефон, Факс.!
UC15,1.4.3 В качестве дш рлнитщ ьнпй контактной
информации можно указать дна из трех контактных реквизита. нипичиаценные как обязательные. и центовый адрес /ысли им отличается от указанного в реквизитах доставки).!
[UC15.15 Алене доставки счет-Фактуры, вели он отличается ст реквизитов поставки. 1
ШС15.1.6 Способ оплаты.!
£ЦС16а! А! Клиент может выбрать в качестве метода тушы чук или кредитную карточку.!
CUC15.1.6.2 Пси додате G помощью чикз система поьцсстаелчьт подробную информацию, кому должен быть оплачен чек и покаксму алпесу его следует доставить, Она также инфосо'к'суь! клиента* что на клиринг чека посла получения может ШЕа^йбатьсадрдк^днейД
IUC 15,1,5.3 При оплати р помощью кредитной, карточки система отображает реквизиты, которые должен заполнить клиент. к этим Ойкнизитам ОТНОСИТСЯ: ПЕЮНЧВНЬ ^ГУСТИМЫХ ШЬЯЦТНиХ кзотдчж. номер кинлитнрй карточки- едок действия конлитной карточки.)
IUC15-1.7 ИмЯ-ТОрговогр представителя, если она известно клиенту по прошлым сделкам-!
ШС15.1.6Две командные кнопки; отдоздить и утмена.1
£U£154L— Система„иредда; ае:.клиенту алеети подробности, . касающиеся заказа, поместив указатель мыши на первое редактируемое поле (реквизит имени).] ГОСТ 5.3 Система позволяет вводить информацию в произвольном иорядке-!
15 минут, выполняется адьтед нативный поток "Клиент не активен").)
(UC15.5 Если клиент нажимает кнопку Отправить, м вея необходимая информация предоставлена., форма заказа отправляется на Web- серзер,. Wfib-сыивер связывается с сервером баз данных дня лого, чтобы поместить заказ в базу данных.! [UC15.6 Сервер баз данных присваивает заказу на покупку уникальный номер заказа и учетный номер клиента.!
IUC15-7 Если сеокро баз данных не ь состоянии создать и запомните заказ* выполняется альтернстийный 1;отрк’“Исключительная ситуация для БД".))
(UC15-8 Если клиент отправляет заказ с ньпштний информацией, ныийлнчстся альтернативный поток ^Узшдлт'аяит^аьмация" J
ГЦС15.9 Если клиент в качестве предпочтительногосредства коммуникации предоставляет адрес, электронно^ почты,, система отправляет клиенту заказ и номера клиента вместе со всеми
деталями, касающимися заказа, и подтверждением принятия заказа. Прецедент завершается.! ЩС15.10 В противном случае, детали, касающиеся заказа, отправляются клиенту по почте и прецедент тйюкб завершается-!
lUClfiJJЕсли клиент нажимает кнопку рт^еу а ^выполняется ' альтернативный паток“Отмена”Д
Альтернативные потоки
Клиент неактивен
fUC 15.4.1 Если клиент не проявляет активности в течение более чем 15 минут, система закрывает соединение с броузером* Прецедент завершается !
Исключительная ситуация для БД
IUQ15JJ Если база данных возбуждает исключительную сихуаиию^сь^т^ма ИНJtiUUPUTKpyoi ее и информирует гдиунта о хара^гоиа ошибки. Если клиент разорвал соединение, система отправляет сообщений об ошибке пр аректроннрй почте клиенту и пррлднцу. Прецедент здеерщаетсн.]
Если с клиентом нет возможности связаться посредством Internet или электронной почты, продавец должен связаться с клиентом с помощью других средств.
Неполная информация
1UC15.E.1 Если клиент не заполнил все необходимые реквизиты. система предлагает клиенту пред пота пить пропущенную информацию- Слисок пропущенных реквизитов отображается, Прецедент продолжается.!
Отмена
rUC15.11.1 Если клиент нажал кнопку СНмыр, .заполненный поди фор?^ы
очищаются. ПриЦедент продолжаете^.]
Предусловия
Клиент указывает броузеру Internet на Web-страницу системы. Страница отображает детальную информацию о конфигурации компьютера вместе с ее ценой. Клиент нажимает кнопку Покупка./
Клиент нажимает кнопку Покупка в пределах 15 минут с (момента запроса на построение и отображение на странице броузера последней конфигурации компьютера.
Постусловия
Если отправка заказа клиента прошла успешно, заказ на покупку записывается в базу данных. В противном случае состояние системы не изменяется.
Структура кооперативного взаимодействия
Диаграмма классов, разработанная в ходе анализа, определяет постоянные классы базы данных. Классы прикладной программы фактически нельзя определить до начала проектирования. Следовательно, диаграмму классов, определяющую структуру некоторой кооперации, необходимо разрабатывать практически “с нуля”. Классы, участвующие в кооперации, разрабатываются для того, чтобы осуществить привязку к выбранной для приложения технологии, обеспечивающей его функционирование (разд. 6.3.2.1).
Web-страншш может содержать сценарии, выполняемые на сервере или интерпретируемые на клиентской машине броузером, или же сценарии обоих типов. Проектирование кооперативного взаимодействия для Web-страницы — непростая проблема. Технология, обеспечивающая функционирование, может не поддерживать надлежащим образом объектно-ориентированного взгляда на мир. В некоторых случаях работа всего приложения может определяться одной Web-страницей, наполненной объектами и апплетами.
Что касается более сложных Web-приложений, для них должна существовать возможность разделения страниц на клиентские, серверные. С точки зрения подхода BCED (разделы 6.1.3.2 и 6.3.1.2), клиентские страницы, представленные в формате HTML, соответствуют пограничным классам. Серверные страницы могут, с одной стороны, обладать ассоциативными связями с клиентскими страницами, а, с другой стороны, с остальными ресурсами Web-сервера. Серверные страницы соответствуют управляющим классам в иерархии SCJ5D [15].
~ Наставление по проектированию: шаг Я (lhtemet-магазин)
; Обратитесь к проектному документу по прецеденту "Order Configured Computer, пред- , ■ ставленному в разделе 6.3.4.1.2. Основываясь на потоке событий, представленном в ’ этом документе, нам требуется создать проект кооперации, отражающий ее структур- 1 | ный аспект, который реализует прецедент “Заказ сконфигурированного компьютера”.
' Даже для такого простого прецедента детализированное проектирование кооперации ’ » выходит за рамки наставления. Поэтому мы сделаем некоторые упрощения. Нет необходимости обрабатывать все детали, касающиеся формы и схемы формы заказа (см. '
j главу 7). Аналогично, с противоположной стороны, нет необходимости принимать ре' шение в отношении интерфейса между приложением и базой данных (т.е. мы не каса- •' I емся вопросов получения и запоминания информации в базе данных) (см. главу 8).
: В данном случае мы применяем подход BCED (разд. 6.3.1.2). Всем предложенным классам | должны быть присвоены префиксы Ь, с, е, или d для обозначения их принадлежности соот- j ветствующему уровню пакета BCED. Классы также должны быть отнесены к одному из еле- ' ] дующих стереотипов: «client раде» (клиентская страница), «form» (форма), «server : I раде» (серверная страница), «entity» (сущность), «db interface» (интерфейс с БД). < ■ Следует определить все отношения ассоциации и агрегации между классами. Также сле- I дует показать отношения материализации, чтобы обозначить поток сообщений материа- . \ лизованным объектам (отношение материализации изображается в языке UML с помощью ’ f пунктирных линий со стрелками, направленными от отправителя сообщения к классу, ко; торый запрашивает материализацию нового объекта). Если объект материализован в ре: зультате инициированного пользователем события (например, пользователь нажимает i командную кнопку), событие можно изобразить на линии материализации.
Рис. 6.30. Структурная сторона кооперации для прецедента “Order Configured
Computer” (Internet-магазин)
На рис. 6.30 приведена диаграмма классов, представляющая структурную сторону кооперации для прецедента "Order Configured Computer”. Поскольку этот прецедент составляет только часть приложения, а также с целью моделирования предусловий и постусловий прецедента на рисунке показаны два класса вместе с их связями, принадлежащие другому прецеденту “Build Computer Configuration” (“Составление конфигурации компьютера”). Это классы b_ConfigurationClientPa^e (Клиентская страница конфигурации) и e_Conf iguration (Конфигурация).
Заметим, что событие покупки [on Purchase], инициируемое пользователем при работе со страницей b_ConfigurationClientPage, устанавливает окружение прецедента. Класс b_OrderClientPage отвечает за обработку содержимого клиентской формы заказа b_OrderClientForm. Форма представляет собой набор полей для ввода информации с экрана, которая принимает входные данные от пользователя. После того, как форма заполнена, она отправляется для обработки серверной странице (c_OrderServerPage).
Четыре объекта, относящиеся к стереотипу «entity» (e_Order, e_Conf iguration, e_Payment и e_Customer) хранят текущую информацию,относящуюся к заказу, независимо от Web-страниц. Следует, однако, напомнить, что это всего лишь объекты памяти— долговременное хранение заказа в базе данных выходит за рамки данного наставления.
С кооперацией связан объект d_Transaction (Транзакция), материализуемый классом c_OrderServerPage после отправки заказа. Хотя класс d_Transaction и не показан явно на диаграмме, он может взаимодействовать с базой данных с целью удостовериться в том, что передача заказа в базу данных осуществлена надлежащим образом. Этот класс также представляет механизм приложения для управления состоянием клиента — он вызывает размещение и удаление cookies с клиентской машины.
Поведенческая сторона кооперации
На рис. 6.31 приведена диаграмма классов, представляющая поведенческую сторону кооперации для прецедента “Order Configured Computer”. Диаграмма выражает функциональные требования к прецеденту. Кооперативные действия начинаются в тот момент, когда удовлетворяется первое предусловие прецедента и клиент нажимает кнопку подтверждения покупки — Purchase. На диаграмме это событие моделируется как сообщение [ on Purchase] newOrderClientPage.
emailCustomeremailCustomerРис. 6.31. Поведенческая сторона кооперации для прецедента “Order ConfiguredРис. 6.31. Поведенческая сторона кооперации для прецедента “Order ConfiguredComputer” (Internet-магазин)Computer” (Internet-магазин)
emailCustomer
emailCustomer
Рис. 6.31. Поведенческая сторона кооперации для прецедента “Order Configured
Рис. 6.31. Поведенческая сторона кооперации для прецедента “Order Configured
Computer” (Internet-магазин)
Computer” (Internet-магазин)
Обратитесь к проектному документу по прецеденту "Order Configured Computer”, пред- , ставленному в разделе 6.3.4.1.2, и предыдущему шагу наставления (разд. 6.3.4.2). Ос- J новываясь на потоке событий, представленном в этом проектном документе по прецеденту, и готовности классов,показанных на рис. 6.30, нам требуется создать проект кооперации, отражающий ее поведенческий аспект, который реализует прецедент “Order Configured Computer".
Объект класса b_OrderClientPage обслуживает сообщение [on Purchase] newOrderClientPage. Эта представленная в формате HTML страница содержит три «£огт»-объекта класса 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 и сервером баз данных на диаграмме отсутствует.
Резюме
Этой главой было открыто рассмотрение проблем системного проектирования — в ней представлены основания системного проектирования. Обсуждаемые здесь вопросы были прямым продолжением предыдущей главы, посвященной углубленному
анализу требований. Были прояснены два основных (и различных) аспекта проектирования — архитектурное проектирование и детализированное проектирование.
Типичные приложения ИС строятся на принципах архитектуры клиент/сервер. Специфические решения на базе этой архитектуры включают распределенные системы обработки и распределенные системы баз данных. Трехзвенные системы расширяют базовую клиент/серверную архитектуру за счет выделения логики приложения в отдельный логический и/или физический уровень.
Архитектурные решения оказывают влияние на проектирование интерфейсов между приложением и базой данных. Иерархия пакетов, построенная на основе подхода ВСЕ (введенного в главе 5), была расширена за счет пакетов интерфейса с базами данных и образования иерархии пакетов BCED.
Повторное использование представляет собой один из важнейших проектных факторов, который влияет как на архитектурные решения, так и на вопросы детализированного проектирования. Решение проблемы повторного использования сводится к выбору между повторным использованием инструментальных средств, каркасов и шаблонов. Эти варианты выбора не являются взаимно исключающими — напротив, рекомендуется применять комплексную стратегию. Повторное использование за счет использования внешних источников следует увязывать с внутренним проектированием пакетов, компонент, классов и интерфейсов. В конечном итоге вычислительные ресурсы представляются в виде диаграммы развертывания.
Детализированное проектирование концентрируется на кооперауии. Кооперация определяет реализацию прецедентов или операций. Кооперация дает модель передачи сообщений между объектами. При этом необходимо учитывать такие факторы, как замещение, перегрузка, итерация, шаблоны, автосообщения, асинхронные сообщения и обратные вызовы. Структурные аспекты кооперации моделируются в виде диаграмм классов, а поведенческие аспекты —■ в виде диаграмм кооперации.
Глава завершается наставлением с решениями для упражнений по проектному моделированию— продолжением наставления по анализу, представленному в главе 2 (при этом используется приложение Internet-магазин). Наставление служит иллюстрацией использования методов проектирования языка UML — проектирования пакетов, компонент, развертывания и кооперации.
■ Вопросы
Объясните, в чем состоит различие между распределенной системой обработки и распределенной системой баз данных.
Что такое трехзвенная архитектура? В чем ее преимущества и недостатки?
Что мы понимаем под активной базой данных?
Каково назнвчение пакета баз данных в подходе BCED?
Что общего и каковы различия между повторным использованием инструментальных средств и каркасов?
Вв. Каким образом компоненты и пакеты соотносятся между собой?
Что такое доминантный класс?
Что такое отношение соединения?
Что такое отношение реализации, используемое в кооперации? Приведите пример (отличный, от приведенного в книге).
Какими альтернативными способами можно представить аргументы сообщения на диаграммах кооперации?
Какие типы сообщений можно отнести к основным (помимо конструкторов и деструкторов)?
В чем заключается различие между замещением и перегрузкой?
Каким образом итеративные сообщения связаны с коллекциями?
Отправитель сообщения может послать или не посылать свой OID целевому объекту. Справедливо ли данное утверждение применительно к асинхронным сообщениям? Поясните свой ответ.
Какие диаграммы языка UML используются для проектирования структурного аспекта кооперации? Объясните, насколько они подходят для выполнения этой задачи.
В1в. Какие диаграммы языка UML используются для проектирования поведенческого аспекта кооперации? Сравните, насколько они подходят для выполнения этой задачи.
В17. Сравните, насколько пакеты прецедентов и пакеты классов применимы на этапах анализа и проектирования жизненного цикла разработки систем.
И| Упражнения
I Рассмотрите следующие дополнительные требования для приложения Магазин видеопроката (эти требования изложены в конце главы 4 и для удобства повторены здесь).
За кассеты и диски, возвращенные позже срока, взимается дополнительная плата за период, превышающий срок проката. Каждый видеоноситель обладает уникаль- , ным идентификационным номером.
Фильмы заказываются у поставщика, который в общем случае может поставить кассеты и диски в течение одной недели. Обычно один заказ делается на несколько фильмов.
Забронировать можно те фильмы, которые заказаны у поставщика и/или все копии которых находятся в прокате. Можно также забронировать те фильмы, которых нет в запасе и которые не заказаны у поставщика; при этом с клиента требуется задаток за один период проката./
Клиент может также сделать несколько предварительных заказов, однако, для каждого забронированного фильма готовится отдельный запрос на бронирование. Бро- . нирование может быть отменено из-за отсутствия реакции со стороны клиента, более точно, в течение одной недели с момента, когда клиенту было сообщено о воз- : можности взять фильм напрокат. Если за фильм был уплачен задаток, он ' записывается на счет клиента.
База данных хранит обычную информацию о поставщиках и клиентах, т.е. адреса, телефонные номера и т.д. В каждом заказе поставщику указываются заказываемые ■ фильмы, их количество, форматы кассеты/диска, а также дата ожидаемой доставки, ' отпускная цена, возможные скидки и т.д.
в. Когда кассета возвращается клиентом или поступает от поставщика, вначале удов- i летворяются предварительные заказы. Работники магазина устанавливают контакт с ’ клиентами, сделавшими предварительный заказ. Для правильной обработки бронирования фильмов информация, связанная с бронированием, обновляется дважды: * после установления контакта с клиентом, когда ему сообщается, что “забронированный фильм пришел", и после сдачи фильма клиенту напрокат. Эти шаги гарантируют правильное проведение операции бронирования._
Клиент может взять несколько кассет или дисков, однако, каждому взятому видео- ' носителю ставится в соответствие отдельная запись. Для каждого выдаваемого на- • прокат фильма фиксируются дата и время выдачи, установленный и фактический
срок возврата. Позже запись о прокате обновляется, чтобы отразить факт возврата видеофильма и факт окончательного платежа (или возврата денег). Кроме того, запись хранит информацию о продавце, отвечающем за прокат фильма. Детальная информация о клиенте и по прокату хранится в течение года, чтобы можно было легко определить уровень доверия к клиенту. Старая информация по прокату сохраня- . ется в течение года в целях проведения аудита.
Все операции выполняются с использованием наличности, электронного перевода денег или кредитных карточек. От клиентов требуется внести плату за прокат при выдаче кассет/дисков.
Если кассета/диск возвращены позже установленного срока (или не могут быть возвращены по каким-либо причинам), плата снимается либо со счета клиента, либо принимается непосредственно от клиента.
Если кассета/диск задержаны более, чем на два дня, клиенту отправляется уведомление о задержке. После отправки двух уведомлений о задержке одной и той же кас- сеты/диска клиент предупреждается о том, что он является “нарушителем", и при следующем его обращении в магазин руководство рассматривает вопрос о снятии с ; него статуса “нарушителя”.:
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”).
б. Магазин видеопроката — обратитесь к приведенным выше дополнительным требованиям и к примеру 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-интерфейса, а также особенностями и ограничениями выбранной программной среды. Эти вопросы являются предметом рассмотрения данной главы.
Проектирование интерфейса как междисциплинарная деятельность
Проектирование графического интерфейса пользователя (GUI — Graphical User Interface) представляет собой междисциплинарную деятельность. Оно требует усилий многофункциональной бригады — один человек, как правило, не обладает знаниями, необходимыми для реализации многоаспектного подхода к проектированию GUI- интерфейса. Надлежащее проектирование GUI-интерфейса требует объединения навыков художника-графика, специалиста по анализу требований, системного проектировщика, программиста, эксперта по технологии, специалиста в области социальной психологии, а также, возможно, некоторых других специалистов, в зависимости от характера системы.
Типичный процесс проектирования GUI-интерфейса для приложений ИС начинается с прецедентов. Аналитик, занимающийся описанием потока событий для прецедента, обладает некоторым зрительным образом GUI-интерфейса для поддержки человеко-машинного взаимодействия. Сложные человеко-машинные взаимодействия нельзя верно передать, пользуясь лишь “языком прозы". Иногда процесс сбора и согласования требований заказчика делает необходимым выработку эскизов GUI-интерфейса.
Проектировщик, участвующий в определении кооперативных взаимодействий для реализации прецедентов, должен иметь ясное зрительное представление о том, как выглядят экранные отображения, выраженные с помощью GUI-интерфейса. Если до него этого уже не сделал аналитик, проектировщик становится первым человеком, который вырабатывает графические представления пользовательского интерфейса. Эти графические представления, предлагаемые проектировщиком, должны соответствовать технологии, на которой базируется GUI-интерфейс — средствам организации окон и элементам управления окнами, Internet-броузерам и т.д. Чтобы успешно воспользоваться технологическими возможностями, может потребоваться прибегнуть к консультации эксперта в области технологии. .
Прежде, чем проект кооперативных действий классов попадет к программистам для реализации, необходимо сконструировать прототип GUI-экранов, “дружественный” пользователю. Для решения этой, задачи привлекаются художники-графики и специалисты по социальной психологии. Совместно они могут предложить привлекательный и удобный GUI-интерфейс.
Задача программиста заключается не в том, чтобы слепо реализовать экраны, но также предложить изменения, обусловленные средой программирования. В некоторых случаях изменения могут привести к улучшению GUI-интерфейса, в других случаях изменения отрицательно сказываются на проекте из-за ограничений, связанных с программированием или продуктивностью.
Из приведенного выше краткого обсуждения ясно, что проектирование GUI- интерфейса — очень обширная задача. На тему разработки GUI-интерфейса написано много книг, уделяющих основное внимание различным аспектам этой деятельности [16], [27], [26], [59], [73], [92]. В данной главе мы сконцентрируемся на том, что должен знать системный проектировщик, чтобы в сотрудничестве с другими специалистами разработать у дачный интерфейс.
Интерфейс: от прототипа к реализации
Основной момент в проектировании GUI-интерфейса заключается в том, что контроль находится на стороне пользователя (при условии, что система, а не пользователь, контролирует системную целостность, защиту и безопасность). Современные объектно-ориентированные программы управляются событиями. Объекты реагируют на события (сообщения). Внутренние взаимодействия между объектами запускаются внешними событиями, инициируемыми пользователем.
“Впечатление и ощущение” от GUI-интерфейса служит “двигателем торговли” при продаже программного продукта заказчику. Прототипы GUI-интерфейса могут служить двоякой цели оценки “ощущения” от GUI-экранов и передачи его функций. Истинное “впечатление” становится доступным на этапе реализации.
Прототип GUI-интерфейса для класса Organization представлен на рис. 7.1, его основной целью является визуализация данных и контроль объектов, расположенных
в окне. Обратная связь с пользователями, получаемая в виде их откликов, а также идеи бригады разработчиков GUI-интерфейса изменяют “впечатление” от окна, а, возможно, и “ощущение" от него.
ЕЕОбратитесь к постановке задачи для приложения Управление контактами с клиентами (разд. 2.3.3), а также к решенным примерам в главе 4. В частности, рассмотрите проект класса Organization в примере 4.8 (разд. 4.2.2.3).Обратитесь к постановке задачи для приложения Управление контактами с клиентами (разд. 2.3.3), а также к решенным примерам в главе 4. В частности, рассмотрите проект класса Organization в примере 4.8 (разд. 4.2.2.3).
Е
Е
Обратитесь к постановке задачи для приложения Управление контактами с клиентами (разд. 2.3.3), а также к решенным примерам в главе 4. В частности, рассмотрите проект класса Organization в примере 4.8 (разд. 4.2.2.3).
Обратитесь к постановке задачи для приложения Управление контактами с клиентами (разд. 2.3.3), а также к решенным примерам в главе 4. В частности, рассмотрите проект класса Organization в примере 4.8 (разд. 4.2.2.3).
Цель этого примера — продемонстрировать то, каким изменениям может подвергнуться GUI-экран для класса Organi zation от первоначального прототипа до конечной реализации. Мы предполагаем, что в качестве бвзсесй технологии создания GUI- интерфейса выступает технология Microsoft Windows.
На рис. 7.2 показана возможная реализация окна Organization как диалогового.
Как можно видеть из рисунка, программист предпочел реализовать окно в виде вкладок; кроме того, в окно был внесен ряд других изменений, касающихся “впечатления и ощущения" от него, таким образом, чтобы привести их в соответствие с принципами проектирования GUI-интерфейса для MicrosoftWindows.
Рис. 7.1. Прототип окна для класса Organization (Управление контактами с клиентами)Рис. 7.1. Прототип окна для класса Organization (Управление контактами с клиентами)
Рис. 7.1. Прототип окна для класса Organization (Управление контактами с клиентами)
Рис. 7.1. Прототип окна для класса Organization (Управление контактами с клиентами)
Рис. 7.2. Реализованное окно для класса Organization (Управление контактами с клиентами)
Руководящие принципы проектирования интерфейса, ориентированного на
пользователя
Центральным звеном при проектировании GUI-интерфейса выступает пользователь. Это замечание послужило основанием для ряда приводимых ниже рекомендаций разработчикам ПО. Руководящие принципы опубликованы производителями GUI- интерфейсов [92]. Они также служат предметом обсуждения многих книг [27], [73].
Руководящие принципы служат разработчикам основанием для построения GUI- интерфейса. При принятии любых проектных решений в отношении GUI-интерфейса они должны использоваться разработчиками на подсознательном уровне. Некоторые из этих руководящих принципов выглядят как хорошо известные старые истины, другие основаны на современной GUI-технологии.
Контроль — на стороне пользователя
“Контроль - на стороне пользователя” — вот главнейший принцип построения GUI- интерфейса. Лучше было бы назвать этот принцип пользовательским восприятием контроля. Некоторые называют его принципом отсутствия какой-либо “материнской опеки — программа не должна действовать как ваша заботливая мать, делая многие вещи
за вас [89]. Основной смысл этого принципа заключается в том, что пользователь инициирует действия, и если в результате этого контроль переходит к программе, то пользователь получает необходимую обратную связь (в виде курсора в форме песочных часов, индикатора ожидания или аналогичным способом).
Рис. 7.3 демонстрирует типичный поток управления в человеко-машинном взаимодействии. Событие, инициированное пользователем (выбор пункта меню, щелчок мышью, перемещение указателя мыши по экрану и т.д.), может привести к открытию окна GUI-интерфейса или вызову программы— как правило, программы на языках типа 4GL или SQL в рамках приложения ИС. Программа временно перехватывает контроль у пользователя.
Процесс выполнения программы имеет возможность вернуть управление назад тому же или другому окну. В другом случае он может вызвать другой модуль на языках типа 4GL или SQL или вызвать внешнюю процедуру. В некоторых случаях программа может кое-что делать для пользователя. Это возможно, к примеру, если программе требуется выполнить вычисления, которые обычно связаны с явным пользовательским событием, или если программа перемещает указатель на другое поле экрана, а для события перемещения с исходного поля предусмотрен обработчик события выхода, связанный с ним.
Согласованность •
Согласованность несомненно является вторым основным принципом разработки качественного интерфейса. Фактически согласованность означает соблюдение стандартов и следование некоторым общепринятым правилам работы с GUI-интерфейсом. Согласованность может рассматриваться, по меньшей мере, в двух аспектах.
Соответствие стандартам поставщика GUI-интерфейса.
Соответствие стандартам в области именования, программирования и другим, разработанным внутри организации стандартам, которые связаны с GUI- интерфейсом.
Оба аспекта одинаково важны, и второй (на который оказывают влияние разработчики) не должен противоречить первому. Если приложение разрабатывается для Windows, то следует обеспечить “впечатление и ощущение”, свойственные работе в системе Windows. Для системы Macintosh замена знаменитого “яблочного” меню вложенным меню (типа “кенгуру”), как это раз попытался сделать автор, вообще никудышная идея!
Разработчик GUI-интерфейса не должен слишком увлекаться творчеством и предлагать необычные новшества. Это может плохо сказаться на уверенности и умении пользователей. Пользователям следует представлять знакомую среду, поведение которой предсказуемо. Как\заметил Трайсман (Treisman) [89], можно представить, какова была бы реакция автомобилистов, если бы производитель автомобилей выпустил на рынок новую машину, у которой поменяли местами педали скорости и тормоза!
Не следует также недооценивать соответствие внутренним стандартам в области именования, программирования, аббревиатур и т.п. Сюда относятся именование и программирование меню, командных кнопок, полей экранов, также стандарты по расположению объектов на экране и последовательному использованию элементов GUI-интерфейса в рамках всех приложений, разрабатываемых собственными силами.
GUI-интерфейсGUI-интерфейсСобытие (пользователь)Событие (пользователь)Событие (пользователь)Событие (пользователь)GUI-интерфейсGUI-интерфейсРис. 7.3. Поток управления GUI-программыРис. 7.3. Поток управления GUI-программыПроцедура 4GL-SQLПроцедура 4GL-SQLВызовВызовпроцедурыпроцедуры4GL-SQL4GL-SQLОбращение кокнуОбращение кокнуСобытие (пользователь)Событие (пользователь)Событие (пользователь)Событие (пользователь)Процедура 4GL-SQLПроцедура 4GL-SQLGUI-Г/ \“/ XGUI-Г/ \“/ XОбращениеОбращениевнешнейвнешнейпрограммепрограммеВнешняя программаВнешняя программаВыполнениеВыполнениеGUI-событияGUI-событияОбработка правила или выходаОбработка правила или выхода
GUI-интерфейс
GUI-интерфейс
Событие (пользователь)
Событие (пользователь)
Событие (пользователь)
Событие (пользователь)
GUI-интерфейс
GUI-интерфейс
Рис. 7.3. Поток управления GUI-программы
Рис. 7.3. Поток управления GUI-программы
Процедура 4GL-SQL
Процедура 4GL-SQL
Вызов
Вызов
процедуры
процедуры
4GL-SQL
4GL-SQL
Обращение кокну
Обращение кокну
Событие (пользователь)
Событие (пользователь)
Событие (пользователь)
Событие (пользователь)
Процедура 4GL-SQL
Процедура 4GL-SQL
GUI-
Г/ \“/ X
GUI-
Г/ \“/ X
Обращение
Обращение
внешней
внешней
программе
программе
Внешняя программа
Внешняя программа
Выполнение
Выполнение
GUI-события
GUI-события
Обработка правила или выхода
Обработка правила или выхода
Индивидуализация и настройка
Индивидуализация и настройка— два взаимосвязанных принципа разработки GUI- интерфейса. Индивидуализация GUI-интерфейса — это просто его настройка под персональные нужды, в то время как настройка — так, как мы понимаем ее здесь — административная задача приспособления ПО к требованиям различных групп пользователей.
Примером индивидуализации является изменение пользователем порядка и размеров колонки в программе просмотра строк (так называемые сетки — grid?) с последующим сохранением этих изменений как его личных предпочтений. При обращении к этой же программе в будущем данные предпочтения учитываются.
Примером настройки является различие в функционировании программы по отношению к опытным пользователям и пользователям-новичкам. Например, пользователю-новичку программа может предложить явную помощь и дополнительные предупреждающие сообщения, указывающие на потенциальную опасность некоторых событий, инициируемых пользователем.
Во многих случаях различия между индивидуализацией и настройкой весьма размыты и малозаметны. Изменение пунктов меню, создание новых меню и т.п. попадают в обе категории. Если они предназначены для индивидуального использования — это индивидуализация. Если они осуществляются системным администратором в интересах всего коллектива пользователей — это настройка.
Терпимость к ошибкам
Хорошо спроектированный интерфейс должен позволять пользователям экспериментировать и совершать ошибки, проявляя терпимость к ошибкам. Подобная терпимость стимулирует исследовательскую активность пользователя, поскольку позволяет ему выполнять ошибочные последовательности действий с возможностью в любой момент совершить при необходимости “откат” в начало. Терпимость к ошибкам подразумевает многоуровневую систему отмены операций.
Об этом принципе легко говорить, однако, он трудно поддается реализации. Реализация терпимости к ошибкам в интерфейсе отличается особой сложностью для многопользовательских приложений баз данных. Пользователь, который снял (и потратил) деньги с банковского счета, не имеет возможности отменить эту операцию! Единственное, что он в состоянии сделать— исправить ошибку (если, конечно, это было ошибкой!), положив деньги назад на счет, осуществив другую операцию. Должен или не должен терпимый к ошибкам интерфейс предупреждать пользователя о последствиях снятия денег со счета — вопрос спорный (и относится он к принципу индивидуализации интерфейса).
Обратная связь
Принцип обратной связи дополняет первый принцип — контроль должен находиться на стороне пользователя. Контролировать ситуацию — значит знать, что происходит, когда контроль временно передается программе. Разработчик должен встроить в систему визуальные или/аудиоподсказки для каждого события, инициируемого пользователем.
В большинстве случаев указатель в форме песочных часов или индикатор ожидания представляет достаточный уровень обратной связи, чтобы понять, что программа что-то делает. Для тех компонент приложения, которые иногда могут стать источником проблем с производительностью, может потребоваться более ясная обратная связь (например, в виде отображения поясняющего сообщения). В любом случае, разработчик никогда не должен предполагать, что приложение выполняется настолько быстро, что обратная связь не потребуется. Любые отклонения в рабочей нагрузке приложения докажут, что разработчик, к сожалению, ошибался.
Эстетичность и удобство
Эстетичность интерфейса влияет на зрительное восприятие системы. Удобство касается легкости, простоты, эффективности, надежности и продуктивности в использовании: интерфейса. Безусловно, оба принципа касаются удовлетворенности пользователя. Именно в этом вопросе разработчик GUI-интерфейса нуждается в помощи художника-графика и эксперта по социальной психологии.
Существует много разнообразных “золотых правил", касающихся создания эстетичного и удобного интерфейса [27], [16]. При этом следует учитывать такие вопросы, как фиксация и движение человеческого глаза, использование цветов, чувство уравновешенности и симметрии, выравнивание и отступ между элементами, чувство пропорции, группирование связанных элементов и т.д.
Принцип эстетичности и удобства превращает разработчика GUI-интерфейса в художника. В этом смысле неплохо помнить о том, что “простота — эталон красоты". В
действительности простоту часто рассматривают как еще один принцип создания GUI-интерфейса, прочно связанного с принципами эстетичности и удобства. В сложных приложениях простота лучше всего достигается с помощью подхода “разделяй и властвуй" за счет последовательного раскрытия информации таким образом, что она отображается только тогда, когда в ней возникает необходимость, возможно, в различных окнах.
Оконный интерфейс
Проектирование GUI-интерфейса характеризуется двумя основными аспектами — проектированием окон и проектированием элементов ввода и редактирования информации в окна. Оба аспекта зависят от базовой среды GUI. Последующее рассмотрение концентрируется на среде Microsoft Windows [92].
Типичное Windows-приложение состоит из единственного главного окна приложения (primary window)-. Главное окно поддерживается набором всплывающих окон (рор-ир window), вторичных окон (secondary window). Вторичные окна поддерживают действия пользователя с главным окном. Многие действия, поддерживаемые вторичными окнами, представляют собой набор основных операций над базой данных — так называемый набором CRUD-операций. (GRUD— популярная аббревиатура, которая обозначает четыре основных операции над данными: Create, Read, Update, Delete (“Создать”, “Читать”, “Обновить” “Удалить”).
Главное окно
Главное окно имеет границу (рамку). Рамка содержит строку заголовка для окна, строку меню, панели инструментов, строку состояния, а также отображаемое и модифицируемое содержимое окна. Горизонтальные и вертикальные полосы прокрутки используются для прокрутки, при необходимости, содержимого окна.
Отображаемое и модифицируемое содержимое может быть организовано в виде подокон (панелей). Панели позволяют осуществлять просмотр и манипулирование различными, но связанными между собой информационными элементами содержания. На рис. 7.4 показано главное окно, которое отображается после успешного входа в систем}' и открытия приложения. Панель в левой части окна содержит схему приложения в стиле программы the Windows Explorer (кнопка закрытия в правом верхнем углу панели говорит пользователю о том, что при желании панель можно убрать из окна). Комментарии соответствуют хорошо известной терминологии Windows.
Типичными обличительными чертами главного окна являются наличие строки меню и панели инструментов. Панель инструментов содержит командные кнопки для наиболее часто используемых пунктов меню. Пиктограммы панели инструментов дублируют эти пункты меню. Они предназначены для быстрого доступа к наиболее часто используемым командам.
Пиктограмма строки заголовкаПиктограмма строки заголовкаТекст заголовкаТекст заголовкаСтрока менюПанель. инструментовСтрока менюПанель. инструментовПанельПанельго Quality Control ф Si Dictionary Т ' -В AdI I to Ad Link-В Ad Link Merge...I |to Advertiser।0Й Advertiser Grom| to Agency■to Agency Groupsго Quality Control ф Si Dictionary Т ' -В AdI I to Ad Link-В Ad Link Merge...I |to Advertiser।0Й Advertiser Grom| to Agency■to Agency GroupsВертикальная полоса прокруткиВертикальная полоса прокруткиГоризонтальная полоса прокруткиГоризонтальная полоса прокрутки|- to Brand. Lto Category|- to Category Produr1 -to Contacti Link Restriction0Й Organisationj - to Outlet1 -B Product t$ Ci Rew Ad В Cj Reports ее Ci SystemXReference|- to Brand. Lto Category|- to Category Produr1 -to Contacti Link Restriction0Й Organisationj - to Outlet1 -B Product t$ Ci Rew Ad В Cj Reports ее Ci SystemXReferenceСтрока состоянияСтрока состояния
Пиктограмма строки заголовка
Пиктограмма строки заголовка
Текст заголовка
Текст заголовка
Строка меню
Панель. инструментов
Строка меню
Панель. инструментов
Панель
Панель
го Quality Control ф Si Dictionary Т ' -В Ad
I I to Ad Link
-В Ad Link Merge...
I |to Advertiser
।0Й Advertiser Grom
| to Agency
■to Agency Groups
го Quality Control ф Si Dictionary Т ' -В Ad
I I to Ad Link
-В Ad Link Merge...
I |to Advertiser
।0Й Advertiser Grom
| to Agency
■to Agency Groups
Вертикальная полоса прокрутки
Вертикальная полоса прокрутки
Горизонтальная полоса прокрутки
Горизонтальная полоса прокрутки
|- to Brand. Lto Category
|- to Category Produr
1 -to Contact
i Link Restriction0Й Organisation
j - to Outlet
1 -B Product t$ Ci Rew Ad В Cj Reports ее Ci System
XReference
|- to Brand. Lto Category
|- to Category Produr
1 -to Contact
i Link Restriction0Й Organisation
j - to Outlet
1 -B Product t$ Ci Rew Ad В Cj Reports ее Ci System
XReference
Строка состояния
Строка состояния
Кнопки минимизации, максимизации и закрытия окна
Puc. 7.4. Главное окно приложения
Обратитесь к постановке задачи для приложения Управление контактами с клиентами ; (разд. 2.3.3), а также к решенным примерам в главе 4. Одно из требований пользователя заключается в том, чтобы приложение Управление контактами с клиентами было по- ; строено на функциональной модели диалогового окна Calendar программы Microsoft Outlook (рис. 7.5).
Главное окно должно отображать виды деятельности, запланированные на день для ра- • ботника, использующего систему. Элемент управления Calender может отображать дея- f тельность, относящуюся как к прошлому, так и к будущему. Мероприятия, запланиро- ; ванные на определенное время дня (спланированные по времени^, должны отображать- Sb левой панели окна Microsoft Outlook. Однако, пользователи выдвигают также ;
ебование об отображении и обработке не спланированных по времени, просроченных J ("ожидаемых" в прошлом) и завершенныхмероприятий.
Наша задача в этом примере заключается в проектировании главного окна для прило- ‘ жения Управление контактами с клиентами, удовлетворяющем приведенным выше требованиям.
Рис. 7.5. Окно Calendar программы Microsoft Outlook
На рис. 7.6 показано главное окно приложения Управление контактами с клиентами. В целях экономии места элемент управления Calendar спроектирован как “съемное" плавающее окно. При желании его можно закрыть. Для каждого мероприятия в левой панели отображается краткое описание мероприятия и либо название организации, либо имя контактного лица. Кроме того, для некоторых мероприятий может отображаться дополнительная информация, например, телефонный номер организации или контактного лица, номер факса или адрес. Используемая в этой книге чернобелая печать не дает возможности в полной мере оценить использование цветов в левой панели главного окна. В частности, цвета используются для обозначения приоритетов, назначенных мероприятиям (высокий — красный, обычный — черный и низкий — синий).
Правая панель служит трем целям. Она отображает три типа мероприятий. Завышенные мероприятия перецосятся из левой панели и размещаются в верхней части правой панели. Текст описания этих мероприятий отображается в синем цвете и зачеркивается. Основная причина, по которой завершенные мероприятия вообще не удаляются с экрана, состоит в том, что иногда требуется придать завершенным мероприятиям статус “незавершенных” (положим, что мы преждевременно решили, что работа выполнена, однако позже выяснили, что она еще не вполне закончена).
Просроченные мероприятия перечислены в правой панели. Они отображаются красным шрифтом. Наконец, мероприятия, которые не спланированы по времени, отображаются черным цветом и перечисляются в нижней части правой панели. Левая колонка панели спроектирована в расчете на людей, которые не различают цветов. Соответствующие пиктограммы обозначают три типа мероприятий, которые могут присутствовать в правой панели.
Рис. 7.6. Главное окно приложения “Управление контактами с клиентами”
Окно просмотра строк
Часто главное окно приложения ИС используется в качестве окна, просмотра строк, для отображения записей базы данных, содержащих, к примеру, данные о сотрудниках. Подобное окно иногда называют броузером строк (row browser') по аналогии с Web- броузером. Пользователь имеет возможность “прокручивать” строки вверх и вниз с помощью вертикальной полосы прокрутки или клавиш клавиатуры (<Page Up>, <Page Down>, <Home>, <End>, а также стрелок "вверх” и “вниз”).
На рис. 7.7 показан пример окна просмотра строк. Документ, помеченный как Ad Link, внутри главного окна является дочерним окном (child window) (это понятие объясняется позже). Дочернее окно обладает собственным набором кнопок управления окном (window button) (для минимизации, восстановления, закрытия), расположенных в правом углу строки меню. Ширину колонок сетки броузера можно изменять, также как и порядок их расположения. Округлые вмятинки рядом с именами колонок указывают на то, что колонки можно сортировать — щелчок мышью на колонке вызывает сортировку записей в порядке возрастания или убывания значений в этой колонке.
В любой данный момент времени в окне просмотра строк активна только одна строка (запись). Двойной щелчок мышью на этой строке обычно приводит к отображению “ окна редактирований (edit window), которое содержит детали, относящиеся к этой записи. Окно редактирования позволяет модифицировать содержимое записи.
Панели могут использоваться для разделения окна по вертикали или по горизонтали, либо в обоих направлениях. Рис. 7.8 иллюстрирует разделение окна по горизонтали. Как ясно из заголовка окна, три панели используются для отображения товаров по рекламодателям и рекламным агентствам. Средняя панель содержит перечень рекламодателей, связанных с текущим выбранным (выделенным) рекламным агентством, показанным в верхней панели. Нижняя панель, в свою очередь, отображает товары, рекламируемые выбранным рекламодателем.
Рис. 7.7. Окно просмотра строкРис. 7.7. Окно просмотра строкWade-Ferrell Larkins (NSW)Walker Wimble Media (NSW) accredidation confirmed June 96 DougWebster Marketing Svcs (NSW) (02) 62281800. Gill 15/12/98.Whybin TBWA & Partners (NS... Previously known as Box Emery 8. Partners media buying lor this agency is thru BO,Wade-Ferrell Larkins (NSW)Walker Wimble Media (NSW) accredidation confirmed June 96 DougWebster Marketing Svcs (NSW) (02) 62281800. Gill 15/12/98.Whybin TBWA & Partners (NS... Previously known as Box Emery 8. Partners media buying lor this agency is thru BO,service - hubby looking 'Press use Virgin Adv WA "Tv and radio use raws tor Virginservice - hubby looking 'Press use Virgin Adv WA "Tv and radio use raws tor VirginDimmeys & Forges Of Footscray Hardings Hardware Stores Hire A HubbyDimmeys & Forges Of Footscray Hardings Hardware Stores Hire A Hubbyuse Raws for Russell Curtis, direct and Virgin Advertising. "Virgin Advertising buCuse Raws for Russell Curtis, direct and Virgin Advertising. "Virgin Advertising buC
Рис. 7.7. Окно просмотра строк
Рис. 7.7. Окно просмотра строк
Wade-Ferrell Larkins (NSW)
Walker Wimble Media (NSW) accredidation confirmed June 96 Doug
Webster Marketing Svcs (NSW) (02) 62281800. Gill 15/12/98.
Whybin TBWA & Partners (NS... Previously known as Box Emery 8. Partners media buying lor this agency is thru BO,
Wade-Ferrell Larkins (NSW)
Walker Wimble Media (NSW) accredidation confirmed June 96 Doug
Webster Marketing Svcs (NSW) (02) 62281800. Gill 15/12/98.
Whybin TBWA & Partners (NS... Previously known as Box Emery 8. Partners media buying lor this agency is thru BO,
service - hubby looking 'Press use Virgin Adv WA "Tv and radio use raws tor Virgin
service - hubby looking 'Press use Virgin Adv WA "Tv and radio use raws tor Virgin
Dimmeys & Forges Of Footscray Hardings Hardware Stores Hire A Hubby
Dimmeys & Forges Of Footscray Hardings Hardware Stores Hire A Hubby
use Raws for Russell Curtis, direct and Virgin Advertising. "Virgin Advertising buC
use Raws for Russell Curtis, direct and Virgin Advertising. "Virgin Advertising buC
44301
Capri Body* Fashion Lingerie St
Capri Body Fashions
Direct Advertiser
ATMC
44302
Capri Body Fashion Lingerie St
Capri Body Fashions
Direct Advertiser
ATMC
44303
Capri Bocf/ Fashion Lingerie St
Capri Body Fashions
Direct Advertiser
ATMC
703135
Classic Sounds Hi Fi Str
Classic Sounds Hi Fi
Direct Advertiser
ATMC
791837
Cassie Sounds Hi Fi Str
Classic Sounds Hi Fi
Direct Advertiser
ATMC
767987
Cassie Sounds Hi Fi Str
Classic Sounds Hi Fi
Direct Advertiser
ATMC
936551
Cassie Sounds Hi Fi Str
Classic Sounds Hi Fi
Direct Advertiser
ATMC
1008555
Cassie Sounds Hi Fi Str
Cassie Sounds Hi Fi
Direct Advertiser
ATMC
612797
Centrepoint Toyota Dealers
Centrepoint Toyota Dealers
Direct Advertiser
ATMC
612814
Centre point Toyota Dealers
CentrepointToyota Dealers
Direct Advertiser
ATMC
1076412
NWS9 Promotions/Competiti...
NWS9(SA)
Young & Rubicam Adelaide (...
ATMC
1461650
NWS9 Promotions/CompefrtL.
NWS9(SA)
Media Edge\Yng & Rubicam .
ATMC
960401
GatewayTasmanie Tourism
Gateway Tasm onia Ltd
Andrews Thomas&Mallirison (...
ATMC
955070
Gateway Tasmanie Tourism
Gateway Tasmania Ltd
Andrews Thomas&Mallinson (...
ATMC
1177271
Meander HorseDrewn Coach...
Meander Coaches
Direct Advertiser
ATME
964005
Gateway Tasmanie Tourism
Gateway Tasmanie Ud
Andrews Thomas&Mallinson (...
АТМЁ
1403901
Atomfest Student Rim Festival
AustTeachers Of Media
Direct Advertiser
AIMI.
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, . ¥й-' ••>?/• .
Puc. 7.8. Многопанелъное окно просмотра строк
557 AIS Media (Viq557 AIS Media (Viq612 677816724628 588499 568665612 677816724628 588499 568665C&N Advertising Py Ltd (VIQ Francis Agency The (VIQ Leeds Media & Comm Svcs (... Magnum Opus Advertising (VI... Nicholson Guthrie Advtg (VIQ Sanford Vick & Assoc (VIC) SSB Advertising (VIC) Us Advertising (VIQ Wilson Everard Advtg (VIQC&N Advertising Py Ltd (VIQ Francis Agency The (VIQ Leeds Media & Comm Svcs (... Magnum Opus Advertising (VI... Nicholson Guthrie Advtg (VIQ Sanford Vick & Assoc (VIC) SSB Advertising (VIC) Us Advertising (VIQ Wilson Everard Advtg (VIQAl S Med iу fVICl Cub C r.jujjAl S Med iу fVICl Cub C r.jujj<*^ AdCx2O(IO Dota Collerhun and Quality Control - [Agency Groups]<*^ AdCx2O(IO Dota Collerhun and Quality Control - [Agency Groups]Puc. 7.9. Окно с панелями просмотра дерева и строкPuc. 7.9. Окно с панелями просмотра дерева и строк
557 AIS Media (Viq
557 AIS Media (Viq
612 677
816
724
628 588
499 568
665
612 677
816
724
628 588
499 568
665
C&N Advertising Py Ltd (VIQ Francis Agency The (VIQ Leeds Media & Comm Svcs (... Magnum Opus Advertising (VI... Nicholson Guthrie Advtg (VIQ Sanford Vick & Assoc (VIC) SSB Advertising (VIC) Us Advertising (VIQ Wilson Everard Advtg (VIQ
C&N Advertising Py Ltd (VIQ Francis Agency The (VIQ Leeds Media & Comm Svcs (... Magnum Opus Advertising (VI... Nicholson Guthrie Advtg (VIQ Sanford Vick & Assoc (VIC) SSB Advertising (VIC) Us Advertising (VIQ Wilson Everard Advtg (VIQ
Al S Med iу fVICl Cub C r.jujj
Al S Med iу fVICl Cub C r.jujj
<*^ AdCx2O(IO Dota Collerhun and Quality Control - [Agency Groups]
<*^ AdCx2O(IO Dota Collerhun and Quality Control - [Agency Groups]
Puc. 7.9. Окно с панелями просмотра дерева и строк
Puc. 7.9. Окно с панелями просмотра дерева и строк
< Agency Groups
В-Si Carat Consortium
; Й-€Э Carat Australia Media Group
’ €3 Carat Australia Sub-Group (NSW) 9-43 Equmedia Consortium
I H £3 AIS Group
' i ф-Cj AS Media (NSW) Sub-Group
' i Й О AS Media (OLD) Sub-Group
' i ф-Q AJS Media (SA) Sub-Grou<
! I
■ j фО AS Media (WA) Sub-Group
" Ф (_) Total Media (Viq Sub-Group
I ф Q Bowtell Clarke Yole Group (WA)
I ф Q] Charterhouse Adv Sub-Group
i ф О DMB&B Group
I ф О Euro RSCG Partnership Group
i ф-О MediaCompete Group
i ; 1- 0 MediaCompete (NSW) Sub-Group
• О ediaCompete (VIQ Sub-Group
Окно просмотра деревьев
Еще один популярный способ использования главного окна — окно просмотра деревьев, которое иногда называют броузером деревьев (tree browser). Программа просмотра деревьев отображает связанные записи в виде схемы с отступами. Схема содержит элементы управления, которые позволяют сворачивать и разворачивать дерево. Хорошо известный пример броузера деревьев — отображение каталогов файлов компьютера с помощью программы Windows Explorer.
В отличие от броузера строк броузер деревьев должен допускать модификацию на месте, т.е. должен допускать модификацию содержимого окна без активизации окна редактирования. Модификации в окне просмотра деревьев осуществляются с помощью операции “перетащить и поместить” (“drag and drop”).
На рис. 7.9 показано окно просмотра деревьев, распложенное в левой панели главного окна. Правая панель представляет собой окно просмотра строк. Выбор записи для группы агентств приводит к отображению агентств, входящих в эту группу в окне просмотра строк.
Web-страница
WebcmpaHuuy также можно трактовать как особый вид главного окна, если она используется в качестве точки входа в Web-приложение. В отличие от традиционных приложений ИС строка меню и панель инструментов Web-страницы не используются для задач приложения. Они используются для навигации по Web — это общий вид деятельности для всех Web-броузеров. Для Web-приложений события, инициируемые пользователями, обычно программируются с помощью командных кнопок и активных гиперссылок.
Рис. 7.10. Окно WebcmpauuuM
На рис. 7.10 показана Web-страница, представляющая собой точку входа для Web- узла Макуарского университета. Строка меню и панель инструментов не применимы к этой Web-странице. Гиперссылки используются для поиска в библиотечной базе данных, а также для того, чтобы “брать" книги или другие библиотечные материалы.
Вторичное окно
За исключением некоторых простейших приложений ИС вторичное окно дополняет свое главное окно. Оно расширяет функциональные возможности главного окна, в частности, в отношении операций, которые модифицируют базу данных (т.е. за счет операций вставки, удаления или обновления).
Вторичное окно обычно является модалъкым по отношению к его главному окну. Прежде, чем приступить к работе с любым другим окном приложения, пользователь должен ответить и закрыть вторичное окно. Немодальные вторичные окна допустимы, однако, их использование не рекомендуется.
Окно входа в систему — простой пример вторичного окна. Пример экрана входа в систему, показанный на рис. 7.11, иллюстрирует основные видимые отличия между главным и вторичным окном. У вторичного окна отсутствуют какие-либо “строки": строка меню, панель инструментов, полосы прокрутки или строка состояния. События инициируются пользователем посредством командных кнопок (кнопок запуска действий), таких как кнопки OK, Cancel (Отмена), Help (Помощь).
Вторичные окна выступают в иде различных экранных форм и масок. Ниже перечислены основные типы вторичных окон.
Диалоговое окно.
Папка с вкладками.
Выпадающий список
I ngon to SybaseI ngon to SybaseКомандные кнопкиКомандные кнопкиРис. 7.11. Простое вторичное окно — окно входа в системуРис. 7.11. Простое вторичное окно — окно входа в систему
I ngon to Sybase
I ngon to Sybase
Командные кнопки
Командные кнопки
Рис. 7.11. Простое вторичное окно — окно входа в систему
Рис. 7.11. Простое вторичное окно — окно входа в систему
Окно сообщений.
Диалоговое окно
Диалоговое окно (dialog box) является почти синонимом понятия вторичного окна, заключает в себе наиболее часто требуемые свойства вторичных окон. Оно поддерживает диалог между пользователем и приложением. Диалог предполагает ввод пользователем некоторой информации, которая обрабатывается приложением.
" '?" '?На рис. 7.12 приведен пример диалогового окна. Это окно обновления. Оно отображает рекламную продукцию, соответствующую текущему товару, выбранному в подокне просмотра строк главного окна. Пользователь может модифицировать любые значения редактируемых полей, ограниченных рамками с белым заполнением внутри.
" '?
" '?
Обратитесь к постановке задачи для приложения Управление контактами с клиентами (разд. 2.3.3), а также к решенным примерам в главе 4. Обратитесь также к примерам 7.1 и 7.2 в этой главе.
Главное окно приложения (рис. 7.4) не позволяет выполнять определенные манипуляции с мероприятиями. Например, ввод нового мероприятия или обновление существующего мероприятия должны осуществляться через вторичное, в данном случае диалоговое, окно.
ГГПосле двойного щелчка мышью на строке мероприятия должно появиться диалоговое окно, отображающее полный список деталей, относящихся к этому мероприятию. Диалоговое окно отображает не только информацию по мероприятию, но также данные о его сопутствующих задачах, равно как и информацию об организации и контактном лице, к которому относится мероприятие.
Г
Г
Затем относящиеся к мероприятию детали могут быть отображены и, возможно, модифицированы, включая тип мероприятия (поле Action (Действие) диалогового окна Details (Подробности), более длинное описание (поле Notes этого же окна), дату и время создания мероприятия, работника, создавшего мероприятие, а также работника, которому запланировано выполнение мероприятие и срок его выполнения (группа полей Due), и работника и время фактического завершения мероприятия (группа полей Completed).
Наша задача заключается в том, чтобы спроектировать диалоговое окно для манипулирования мероприятиями, удовлетворяющее приведенным выше требованиям.
Не редактируемое значение поля
Рис. 7.12. Диалоговое окно
На рис. 7.13 представлен вариант решения нашего примера. Обратите внимание, что поля Organization (Организация), Contact (Контактное лицо) не являются редактируемыми, поскольку “адресат” мероприятия не подлежит изменению. Аналогично значения группы полей, следующих за приглашением Created (Создано), также нельзя редактировать.
Значения полей, примыкающих к приглашению Completed (Завершено), не редактируемы в том смысле, что пользователь не может ввести их. Однако, нажатие кнопки Complete (Завершить) автоматически вставляет в эти поля значения даты, времени и имени пользователя. После завершения мероприятия пользователь по-прежнему имеет возможность вернуться к нему как к “несостоявшемуся”, поскольку в таком случае кнопка Complete превращается в кнопку Uncomplete (Не завершать).
Пользователь имеет возможность сохранить изменения в базе данных и вернуться в главное окно, щелкнув на кнопке ОК. Вместо этого пользователь может отменить (кнопка Cancel) внесение изменений и остаться в диалоговом окне. Наконец, пользователь может нажать кнопку New Event (Новое мероприятие), что приведет к сохранению изменений (после подтверждения их пользователем), очистке всех полей и даст пользователю возможность создать качественно новое мероприятие (не возвращаясь в главное окно).
Папка со вкладками
В тех случаях, когда объем информации, которую необходимо отобразить во вторичном окне, превышает “полезную площадь", а предмет рассмотрения можно логически разделить на несколько информационных групп, бывает полезным использование пайки со вкладками (tab folder). В каждый данный момент времени видим только один из листов вкладок, расположенный на вершине этой “стопки” листов. (В системе Microsoft Windows папка со вкладками, называется листом свойств, снабженным вкладками (tabbed property sheet), а каждая из вкладок называется страницей свойств (property page)).
Рис. 7.13. Диалоговое окно (Управление контактами с клиентами)
| Обратитесь к постановке задачи для приложения Управление контактами с клиентами { I (разд. 2.3.3), а также к решенным примерам в главе 4. Обратитесь также к примерам ' ; 7.1,7.2 и 7.3 в этой главе.
I Рассмотрите папку со вкладками для окна Maintain Organizations, приведенную на < рис. 7.2 (пример 7.1). Одна из вкладок называется Contacts (Контактные лица). Она ’ предназначена для осуществления доступа и модификации данных поля Contact (класс : Contact) с помощью этой папки со вкладками. При ее отсутствии пользователь вынуж- * ; ден был бы всегда возвращаться в главное окно и активизировать отдельное вторичное , ; окно для ведения учетной информации по контактам.:
5 Цель этого примера заключается в проектировании содержимого вкладки Contacts.
На рис. 7.14 показана папка со вкладками для ввода информации о новых организациях, занимающихся рекламой. Четыре вкладки разделяют большой объем информации, вводимой пользователем, на четыре группы. Командные кнопки в нижней части экрана применимы ко всему окну, а не только к текущей видимой странице вкладки.
Рис. 7.14. Папка со вкладками
Как показано на рис. 7.15, вкладка Contacts отображает только имена контактных лиц в организации. Однако, вкладка обладает собственным набором командных кнопок (Add, Edit и Delete) для добавления, редактирования и удаления выделенных в текущий момент Элементов из базы данных по учету информации о контактах. Действия по добавлению (Add) или редактированию (Edit) контактной информации приводят к открытию вторичного окна Maintain Contacts поверх окна Maintain Organizations. Окно Maintain Contacts является модальным по отношению к окну Maintain Organizations.
Выпадающий список
В некоторых случаях удобной заменой странице вкладки может служить выпадаю- ги,ий список (drop-down list) или набор выпадающих списков. Выпадающий список обеспечивает список выбора элементов, из которого пользователь может выделить один подходящий элемент. Для выполнения операции вставки нового элемента в список пользователь может ввести новое значение, которое добавляется в список и отображается при открытии списка в следующий раз.
Как видно из рис. 7.16, выпадающий список не обязательно должен быть простым списком, он может представлять собой окно просмотра деревьев.
Рис. 7.15. Папка с вкладками (Управление контактами с клиентами)
Рис. 7.16. Выпадающий список
AIM2000 Data Dictionary Mnintenance t
Рис. 7.17. Окно сообщения
На рис. 7.17 показано сообщение, которое требует подтверждения (кнопка ОК) от пользователя.
Зависимость между окнами
С точки зрения пользователя приложение выглядит как набор взаимодействующих окон. Задача разработчика GUI-интерфейса состоит в том, чтобы организовать зависимости между окнами в виде последовательной легко понятной структуры. Пользователь никогда не должен чувствовать себя заблудившимся среди открытых окон.
В идеале между главным окном и верхним текущим открытым вторичным окном должна устанавливаться простая, даже не иерархическая связь. Это достигается за счет придания вторичному окну статуса модального по отношению к предыдущему окну. Многодокументный интерфейс (multiple document interface — MDI), рассматриваемый в разд. 7.5.3, должен позволять обрабатывать любую сложную ситуацию, не прибегая к необходимости использования немодальных окон.
В то время, как проектирование GUI-интерфейса должно способствовать исследованию интерфейса пользователем, хороший проект строки меню остается принципиальным методом объяснения возможностей приложения. Команды меню, доступные пользователю при использовании выпадающих или выдвигающихся меню, служат в качестве косвенного объяснения зависимостей между окнами.
Документ и его представление
Проектирование 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.
Обычно на экране отображается только фрагмент данных, хранимых в объекте CDocument. Этот фрагмент называется представлением (view). Объект представления является производным объектом класса CView. Для одного документа может существовать множество представлений. С технической точки зрения объект CView и окно (фрейм), в котором он отображается, — это не одно и то же.
На рис. 7.18 показано, в чем состоит видимое различие между документом и представлением. В данном случае документ представляет собой документ, созданный с помощью текстового процессора, но в общем случае он может быть любым файлом, содержащим информацию, которая извлечена из базы данных.
Рис. 7.18. Документ и его представление
Однодокументный интерфейс
В случае некоторых простых приложений проект GUI-интерфейса может состоять из единственного главного окна, в котором одновременно отображается только один открытый документ. Библиотека MFC поддерживает эту возможность, которая получила распространение под названием SDI-интерфейса (single document mterjace— однодокументный интерфейс).
В проекте GUI-интерфейса для приложения “Управление контактами с клиентами” используется SDI-приложение. В любой момент времени пользователю представлены события, относящиеся к одному дню (рис. 7.19).
Многодокументный интерфейс
Для более сложных приложений безусловно может потребоваться открывать одновременно несколько документов. Документы могут быть однотипными, однако, зачастую они принадлежат разным типам. Библиотека MFC поддерживает возможность, которая получила распространение под названием MDI-интерфейса (multiple document interface— многодокументный интерфейс).
Рис. 7.19. Приложение с однодокументным интерфейсом (SDI) (с любезного разрешения компании ACNielsen AdEx, Сидней, Австралия)
MDI-приложение все так же использует только одно главное окно. Это окно называется родительским окном {parent window). Однако, MDI-приложение позволяет открывать несколько документов внутри фрейма родительского окна. Каждый документ называется дочерним окном {child window). Логически каждое дочернее окно ведет себя так, как если бы оно было главным окном, которое может появиться только внутри родительского окна (но не на рабочем столе компьютера).
Тот факт, что архитектура MDI обладает только одним главным окном, по существу, выражается в том, что все дочерние окна совместно используют одну строку меню. Аналогично дочерние окна, как правило, совместно используют панель инструментов и строку состояния. Однако, существует возможность внести модификации в доступные пользователю действия, содержащиеся в меню и панели инструментов, чтобы отразить функциональные возможности текущего активного дочернего окна.
На рис. 7.20 показано MDI-приложение. Внутри фрейма главного окна открыто четыре документа (броузера строк). Пятый документ, расположенный в левой части главного окна, представляет собой броузер деревьев.
Навигация по окнам
Графическая картина GUI-окон, построенная с использованием прототипов или других средств визуализации, ничего не говорит о том, каким образом пользователь может фактически перемещаться по окнам. Нам еще требуется спроектировать систему навигации по окнам. Диаграмма навигации по окнам призвана визуализировать окна приложения и управляющие объекты, которые позволяют пользователю перемещаться от одного окна к другому.
К сожалению, UML не обладает методами графического моделирования для моделирования навигации по окнам. Необходимо разработать собственную модель или воспользоваться преимуществами стереотипов UML и настроить одну из диаграмм UML для представления навигации по окнам.
❖ Quality ControlЙ-Qi DictionaryBl AdВ Ad LinkB Ad Link Merge...В AdvertiserB Advertiser Grau;В AgencyB Agency Groups- В Brand...В CategoryВ Category ProdiKB Con actB Link RestrictionВ OrganisationВ Owlet❖ Quality ControlЙ-Qi DictionaryBl AdВ Ad LinkB Ad Link Merge...В AdvertiserB Advertiser Grau;В AgencyB Agency Groups- В Brand...В CategoryВ Category ProdiKB Con actB Link RestrictionВ OrganisationВ Owlet2V2020202020202020 20'202V2020202020202020 20'200Q ■■■■■■■■■■■■■■00 120Bar12th Night Theatre°" 13 Car Dealers Keilor Rd Essnd0Q ■■■■■■■■■■■■■■00 120Bar12th Night Theatre°" 13 Car Dealers Keilor Rd EssndH-£ Raw Ad ; В Raw Ad-All | -BRawAdTV j I -B Raw Ad Radi'H-£ Raw Ad ; В Raw Ad-All | -BRawAdTV j I -B Raw Ad Radi'00 00 oo001 oo oo00 00 oo001 oo oo13 Dentist Ph Directory Svc13 Find Phone No Svc13 PAID'131-SHOP Business Sves14 Plus Fashions Wmns Clthg St156 Outdoor Home Fitness Ctr1626 Ladies Clothing Rng13 Dentist Ph Directory Svc13 Find Phone No Svc13 PAID'131-SHOP Business Sves14 Plus Fashions Wmns Clthg St156 Outdoor Home Fitness Ctr1626 Ladies Clothing RngHotels/Pubs/Tavernj TheatresMotor Dealers A-E 1 Dial It ServicesDirectories Electronic/Phone Bail DirectoriesFashion RetaiFWomlFitness Centres I RangeHotels/Pubs/Tavernj TheatresMotor Dealers A-E 1 Dial It ServicesDirectories Electronic/Phone Bail DirectoriesFashion RetaiFWomlFitness Centres I Range
❖ Quality Control
Й-Qi Dictionary
Bl Ad
В Ad Link
B Ad Link Merge...
В Advertiser
B Advertiser Grau;
В Agency
B Agency Groups
- В Brand...
В Category
В Category ProdiK
B Con act
B Link Restriction
В Organisation
В Owlet
❖ Quality Control
Й-Qi Dictionary
Bl Ad
В Ad Link
B Ad Link Merge...
В Advertiser
B Advertiser Grau;
В Agency
B Agency Groups
- В Brand...
В Category
В Category ProdiK
B Con act
B Link Restriction
В Organisation
В Owlet
2V
20
20
20
20
20
20
20
20 20'
20
2V
20
20
20
20
20
20
20
20 20'
20
0Q ■■■■■■■■■■■■■■
00 120Bar
12th Night Theatre
°" 13 Car Dealers Keilor Rd Essnd
0Q ■■■■■■■■■■■■■■
00 120Bar
12th Night Theatre
°" 13 Car Dealers Keilor Rd Essnd
H-£ Raw Ad ; В Raw Ad-All | -BRawAdTV j I -B Raw Ad Radi'
H-£ Raw Ad ; В Raw Ad-All | -BRawAdTV j I -B Raw Ad Radi'
00 00 oo
001 oo oo
00 00 oo
001 oo oo
13 Dentist Ph Directory Svc
13 Find Phone No Svc
13 PAID'
131-SHOP Business Sves
14 Plus Fashions Wmns Clthg St
156 Outdoor Home Fitness Ctr
1626 Ladies Clothing Rng
13 Dentist Ph Directory Svc
13 Find Phone No Svc
13 PAID'
131-SHOP Business Sves
14 Plus Fashions Wmns Clthg St
156 Outdoor Home Fitness Ctr
1626 Ladies Clothing Rng
Hotels/Pubs/Tavernj Theatres
Motor Dealers A-E 1 Dial It Services
Directories Electronic/Phone Bail Directories
Fashion RetaiFWoml
Fitness Centres I Range
Hotels/Pubs/Tavernj Theatres
Motor Dealers A-E 1 Dial It Services
Directories Electronic/Phone Bail Directories
Fashion RetaiFWoml
Fitness Centres I Range
Puc. 7.20. Приложение с многодокументным интерфейсом (MDI)
Введение навигационных стереотипов в диаграмму видов деятельности
Оказывается, диаграмма видов деятельности является неплохим потенциальным стереотипом для оконной навигации. Диаграмма видов деятельности показывает переходы между видами деятельности (разд. 2.2.3.2). Однако, диаграмма видов деятельности, будучи разновидностью конечного автомата, может также обрисовать состояния объектов. Эту двойственность диаграмм видов деятельности можно использовать в изобразительных целях— для интерпретации аналогичной двойственности, присущей GUI- объектам. GUI-окна похожи на состояния в ожидании событий (видов деятельности).
Состояния и виды деятельности диаграммы видов деятельности можно превратить в стереотипы. Стереотипы состояния могут обозначать различные типы окон и другие GUI-объекты, которые “продолжают существовать” между событиями, т.е. которые обладают длительностью. На рис. 7.21 показано состояние, играющее роль стереотипа главного окна. Состояние представляет окно просмотра (сетку) для товаров, отображаемое в главном окне приложения. Это также и начальное состояние модели.
«Primary Window»Product Browser
Рис. 7.21. Состояние, обозначенное как стереотип GUI-объекта •
Рис. 7.22. Вид деятельности, обозначенный как стереотип управляющего GUI-объекта
Стереотипы видов деятельности могут обозначать различные типы управляющих элементов GUI-интерфейса, которые можно использовать для запуска событий на состояниях (теперь обозначенных как объекты GUI-окон). В противоположность состоянию деятельность обладает очень короткой длительностью — можно сказать, что на нашей относительной временной шкале они обладают нулевой длительностью.
Виды деятельности (овалы) можно представить внутри состояния (прямоугольник со скругленными краями), к которому они применяются. На рис. 7.22 показано три вида деятельности в состоянии Product Browser. Окно Product Browser можно использовать для инициирования события вставки, удаления или обновления товара. Все три события можно запустить с помощью командной кнопки панели инструментов или пункта меню. Двойной щелчок мышью на строке товара в окне просмотра также поддерживает событие обновления.
Полный список стереотипов состояний и Видов деятельности для поддержки проектирования системы навигации по окнам, как правило, зависит от выбранного GUI- интерфейса. Разработчики могут также подумать над использованием стереотипов в виде пиктограмм. Ниже приведен неполный перечень стереотипов для GUI- интерфейса Microsoft Windows.
Состояния (окна)
Главное окно
Панель в главном окне
Окно просмотра строк
Окно просмотра деревьев
Web-страница
Вторичное окно
Диалоговое окно
Окно сообщений
Папка со вкладками
Типы данных окон
Текстовое поле
Комбинированное окно
Спиновое окно
Колонка
Строка
Группа полей
Виды деятельности (элемент управления окном)
Пункт выпадающего меню
Пункт всплывающего меню
Кнопка панели инструментов
Командная кнопка
Двойной щелчок мышью
Выбор из списка
Клавиша клавиатуры
Функциональная клавиша клавиатуры
Комбинация клавиш клавиатуры
Бегунок полосы прокрутки
Кнопка закрытия окна
Диаграмма навигации по окнам
После определения стереотипов состояний и видов деятельности можно использовать линии перехода для соединения видов деятельности и состояний. В результате получится диаграмма навигации по окнам, в которой виды деятельности запускают переходы на состояниях.
Рис. 7.23 расширяет предыдущий пример и показывает состояния, которые являются результатом запуска трех видов деятельности, присутствующих в окне Product Browser. Состояние, запускаемое событием Update, расширено. Окно Update Product (<<dialog box») содержит четыре деятельности (<<command buttons»). Нажатие на кнопке ОК или Cancel вызывает обратный переход в окно Product Browser. Нажатие на кнопке Save или Clear не изменяет активное окно (если нам требуется зафиксировать изменение состояния внутри активного окна, необходимо расширить нашу модель за счет дополнительных стереотипов).
Модель на рис. 7.23 ограничена объектами GUI. В главе 9 будет показано, каким образом можно дальше развить стереотипы диаграммы видов деятельности, чтобы визуализировать всю логику приложения, включая доступ к базе данных.
Рис. 7.23. Диаграмма навигации по окнам
Диаграмма навигации по окнам для нашего примера должна рассматривать в качестве состояний три окна Contact Management (<<primary window>>), Task/Event Details («dialog box») и Calendar («combo box»). Левую и правую панели главного окна также можно рассматривать как возможные состояния (подокна) главного окна-состояния. Однако, в предлагаемом решении мы пропускаем панели.
Как следует из панели инструментов, показанной на рис. 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 вызывает отображение сообщения с приветствием благотворителю и информационных полей окна с данными о текущем звонке.
В ходе разговора с благотворителем телемаркетер взаимодействует с системой, нажимая различные командные кнопки. На панели инструментов имеется ряд кнопок для записи результатов звонка (таких как заказ на билеты, перепланирование звонка или неудача). Имеется также ряд командных кнопок для просмотра более подробной информации, относящейся к кампании или благотворителю.1
На рис. 7.25 представлена диаграмма навигации по окнам для приведенного выше примера. Хотя Entry Window и Call Window— это одно и то же главное окно («primary window»), мы в явном виде представляем два состояния окна. Состояние' Entry Window становится активным после начального запуска программы, а также в том случае, когда результат звонка неудачен (Unsuccessful). Возможна ситуация, при которой мероприятия во вторичном окне могут возвращать управление окну Entry Window, но это не отражено в модели. Нажатие кнопки выхода Quit в любом состоянии приводит к закрытию приложения.
. • Рис. 7.24. Диаграмма оконной навигации для приложения “Управление контактами
,. с клиентами
«dialog box» «message box»
Weicome Message
Callback Window
«command button» .Welcome Message
«dialog box» Order Window
«command button» v Supporter History v
«tab foider» Supporter Window
«primary window» Entry Window
«primaiy window» Cali Window «toolbar» Call Outcome
«command button»^ /«command button» Next CailQuit
'«command button»
Quit _
«command button»Next Cail
«command button»
Campaign Detaiis v
«dialog box»CampaignWindow
Puc. 7.25. Диаграмма оконной навигации для приложения “Телемаркетинг”
Резюме
Разработка GUI-интерфейса охватывает весь жизненный цикл производства программного продукта — она начинается на этапе анализа и продолжается до реализации. Данная глава обращена к проектированию GUI-интерфейса, в особенности для среды Microsoft Windows. В ней также вводится графическая нотация для представления навигации по окнам.
Проектирование GUI-интерфейса представляет собой междисциплинарн^н) деятельность, требующую объединения усилий различных специалистов. Проектирование должно вестись в соответствии с руководящими принципами, декларируемыми производителями оконного интерфейса, на использование которого ориентирован проект. Эти принципы направлены на решение таких вопросов, как принцип локализации управления на стороне пользователя, соответствие, индивидуализация, настройка, терпимость к ошибкам, обратная связь, эстетичность и удобство использования.
В интерфейсе системы Microsoft Windows различают главное окно и вторичное окно. Главное окно может быть окном просмотра строк, окном просмотра деревьев или
Web-страницей. Вторичное окно может быть диалоговым окном, папкой со вкладками, выпадающим списком или окном сообщений. Вторичное окно может быть по отношению к своему главному окну модальным или немодальным. Дальнейшее уточнение зависимостей между окнами осуществляется применительно к использованию SDI- интерфейса или MDI-интерфейса.
Визуальное проектирование отдельных окон представляет собой лишь один из аспектов разработки GUI-интерфейса. Второй основополагающий аспект разработки связан со схемами перемещения по окнам., которые призваны зафиксировать возможные пути навигации пользователя между окнами приложения. В данной главе были введены диаграммы навигации по окнам как один из подходов к решению этой проблемы. Диаграммы навигации по окнам расширяют диаграммы видов деятельности языка UML. В действительности, они представляют собой новый профиль UML для моделирования навигации по окнам.
■ Вопросы
Перечислите и дайте краткое определение руководящих принципов разработки GUi- интерфейса.
В чем отличие главного окна от вторичного окне?
вз. Что такое панель? В чем она может быть полезной при проектировании GUi-интерфейса?
Что такое папка со вкладками? В чем ее отличие от диалогового окна?
В чем заключается сущность подхода “документ/представление" к построению графического интерфейса?
Д опускает ли MDI-интерфейс использование нескольких главных окон? Объясните свой ответ.
Каким образом окна и элементы управления окнами представляются не диаграммах навигации по окнам? Соответствует ли это представление назначению диаграмм видов деятельности в языке UML? Объясните свой ответ.
ВВУпражненияУпражнения
В
В
Упражнения
Упражнения
Рассмотрите следующие дополнительные требования для приложения Телемаркетинг. ;
Окно Telemarketing Control представляет собой главное окно интерфейса для • приложения Телемаркетинг. Это окно выводит на экран компьютера телемаркетера список вызовов а текущей очереди. Когда телемаркетер запрашивает вызов из оче- > реди, система устанавливает соединение, и телемаркетер получает возможность ; обработать телефонное подключение. При этом на экране отображеется информа- ; ция о звонке (Call Summary) —• выводится время начала, завершения и продолжи- , тельность текущего звонка.i
После установления соединения окно Telemarketing Control отображает информацию о текущем звонке — кому произведен звонок, в рамках какой кампании, какой : тип звонка осущестален. Если для текущего телефонного номера запланировано бо- ; лее одного звонка, телемаркетеру предоставляется возможность осуществить цикл
этих звонкое.:
На любом этапе разговора телемаркетер может просмотреть предысторию благо- । творителя (окно Supporter History), относящуюся к предыдущим кампаниям. I
Аналогично можно просмотреть подробности, относящиеся к кампании, в рамках ко- 1 торой произведен текущий звонок (окно Campaign).i
GUI-интерфейс обеспечивает возможность быстрой фиксации результатов звонка. К ! возможным результатам относятся: “размещение" (т.е. билеты были заказвны), । "обратный вызов", “неудача”, “нет ответа", “занято”, "автоответчик”, "факс”, ? "неверный номер" и "разрыв сеязи".,-
Окн Campaign отображает подробности, относящиеся к кампании, билетам и при- । зам, разыгрываемым в рамках кампании. Подробности, относящиеся к кампании, ! включают: идентификационный номер, назевние, даты начала, окончания и розы- S грыша призов. Подробности, относящиеся к билетам, включают: количество биле- > тов, участвующих в кампании, сколько из них продано и сколько еще имеется в нали- ; чии. Подробности, относящиеся к призам, включают: описвние приза, ценв приза и ( место среди других призов (первое, второе или третье).;
Окно Supporter History отображает предысторию зёонков и предысторию уча- ; стия благотворителя в прошлых кампаниях. История звонков включает перечень по- ; следних звонков, типы зеонков, результаты, а также идентификаторы кампаний и те- | лемаркетеров. Предыстория кампаний содержит информацию размещении биле- | тов и выигрышах призов благотворителем.|
При выборе действия Placement (Размещение) активизируется окно placement, которое позволяет пользователю выделить билеты благотворителю и зафиксировать платеж.|
При выборе действия No Answer или Engaged для каждого текущего звонка в сис- | теме в качестве результата записываются значения “нет ответа" и “занято” соответ- ; ственно. Затем звонки перепланируются системой на другое время следующего дня ' при условии, что каждый звонок не выходит за пределы лимита попыток, установ- | ленного для данного типа звонка.I
При выборе действия Machine в системе в качестве результата записывается зна- ; ■ чение “автоответчик". Продолжительность звонка устанавливается только для пер- ;
вого из текущих звонков. Затем звонки перепланируются системой на другое время следующего дня при условии, что каждый звонок не выходит за пределы лимита попыток, установленного для данного типа двойка.
При выборе действия Fax или Wrong в системе в качестве результата записываются значение “факс" или “неверный номер". Продолжительность звонка устанавливается только для первого из текущих звонков. После этого для каждого благотворителя с текущим номером телефона данные, относящиеся к благотворителю, обновляются, в них заносится признак “испорчанный телефон".
При выборе действия Disconnected в системе в качестве результата записывается значение "разрыв связи". После этого для каждого благотворителя с текущим номером телефона данные, относящиеся к благотворителю, обновляются, в них заносится признак “испорченный телефон".
При выборе действия Callback в системе в качестве результата записывается значение “обратный вызов". Продолжительность звонка устанавливается только для первого из текущих звонков. Чтобы получить время и дату обратного вызова и поместить их, вызывается окно Call Scheduling. Затем звонок перепланируется системой (с присвоением ему нового приоритета) на время и дату, полученные с помощью окна Call , Scheduling. Новому звонку присваивается тип “обратный вызов”.|
Если при выходе из окна Placement все оставшиеся билеты кампании уже распре- | делены, все последующие звонки благотворителям для данной кампании не имеют | смысле. Все подобные звонки должны быть удалены из очереди звонков.>
У1. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диаграмме видов деятельности для книги. Рвссмотрите диаграмму классов из примере 4.7 (разд. 4.2.1.2.3).
Модифицируйте и расширьте диаграмму классов, показанную на рис. 4.4, для поддержки дополнительных требований, которые сформулированы выше.
2. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диаграмме видов деятельности для книги.
Спроектируйте и сделайте набросок главного окна для приложения “Телемаркетинг", т.е. окна Управление телемаркетингом. Объясните, каким образом это окно удовлетворяет соответствующие требования к приложению.
З. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к ■ решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в див- грвмме видов деятельности для книги.
Спроектируйте и сделайте набросок окна Supporter History для приложения “Телемаркетинг". Объясните, каким образом это окно удовлетворяет соответствующие требования к приложению
4. Телемаркетинг — обратитесь к изложенным выше дополнительным требованиям, а также к решениям, предложенным в ходе разбора примера Телемаркетинг, как определено в диаграмме видов деятельности для книги.
Изобразите диаграмму навигации по окнам для приложения Телемаркетинг. Если потенциальное решение оказывается слишком сложным, разделите диаграмму на несколько меньших диаграмм. Старайтесь не слишком поддаваться влиянию диаграммы навигации по окнам из примера 7.6 (разд. 7.6.2). Объясните, каким образом это окно удовлетворяет требования к приложению.
5. Internet-магазин — обратитесь к решениям, приведенным в наставлении по приложению Internet-магазин, как определено в диаграмме видов деятельности для книги.
Спроектируйте и сделайте набросок Web-страницы, которая отображает состояние текущего заказа для клиента. Объясните, с какими сложностями вы встретились.
Уб. Internet-магазин — обратитесь к решениям, приведенным в наставлении по приложению Internet-магазин, как определено в диаграмме видов деятельности для книги.
Изобразите диаграмму навигации по окнам для приложения Internet-магазин. Если потенциальное решение оказывается слишком сложным, разделите диаграмму на несколько меньших диаграмм. Объясните, каким образом это окно удовлетворяет требования к приложению.
Проектирование баз данных
Можно сказать, что информационные системы являются многопользовательскими системами по определению. Это свойство само по себе требует наличия базы данных, с которой могут одновременно работать многие пользователи. Прикладные программы зависят от базы данных, однако, обратное утверждение неверно. Вывод очевиден — надлежащий проект базы данных, который может объединить и поддерживать прикладные программы, является необходимым условием реализации информационной системой предусмотренных функциональных возможностей.
В языке UML диаграмма классов определяет структуры данных, требуемые приложением. Структуры данных, которые постоянно находятся в базе данных, моделируются с помощью классов-сущностей, а также как отношения между классами- сущностями. Классы-сущности необходимо отобразить в структуры данных, распознаваемые базой данных. Эти структуры данных изменяются в зависимости от базовой модели базы данных, которая может быть объектно-ориентированной, объектнореляционной или реляционной.
В этой главе рассматривается отображение объектов в базы данных. Здесь объясняется, каким образом осуществляются преобразования классов-сущностей, ассоциаций, агрегаций и обобщений в структуры данных, имеющиеся в распоряжении каждой из трех моделей баз данных. Рамки книги не позволяют коснуться вопроса “интеграции схемы", т.е. интеграции перекрывающихся структур базы данных, которые возникают в результате требований со стороны многих прикладных программ, конкурирующих за одни и те же ресурсы базы данных.
Уровень постоянных объектов
. базы данных
■ На протяжении всей книги мы постоянно проводили различие между разработкой клиентского приложения и проектированием сервера баз данных. Мы подчеркивали, что модель классов и пакеты классов BCED (разд. 6.1.3.2) отражают классы приложения, а не структуры хранения баз данных.
Классы-сущности представляют постоянные объекты базы данных для приложения, однако, они не являются постоянными классами для базы данных. Классы базы данных инкапсулируют взаимодействие между приложением и базой данных, однако они ни в коей
мере не являются постоянными классами. Нам по-прежнему необходимо спроектировать уровень архитектуры для постоянных объектов базы данных (persistent data base layer).
Архитектурный уровень постоянных объектов базы данных может поддерживаться различными типами СУБД: реляционными (например, Sybase, DB2, OracleS), объектно-реляционными (например, UniSQL, Oracle8) или объектными (например, ОЬ- jectStore, Versant). Маловероятно, чтобы модель хранения для новой системы принадлежала к одному из устаревших типов моделей наподобие иерархической (например, IMS), сетевой (например, IDMS), инвертированной или аналогичной модели (например, Total, Adabas). В некоторых случаях, но не в случае действительно современных приложений ИС, уровень постоянного хранения может быть реализован с использованием простых плоских файлов.
Модели данных
Специалисты по базам данных выработали свое собственное представление о мире моделирования. Базы данных хранят данные. Исторически специалисты по базам данных концентрировались на моделях данных (т.е. на языке UML — моделях состояния). Современные возможности баз данных по хранению и выполнению программ распространили эту перспективу на модели поведения (ориентированные на триггеры и хранимые процедуры), однако моделирование данных по-прежнему остается альфой и омегой разработки баз данных.
Модель данных (data model) (называемая также схемой базы данных (database schema) — это абстракция, которая представляет структуры базы данных в терминах более понятных, чем эти страшные биты и байты. Широко известная классификация уровней модели данных выделяет три уровня абстракции.
Внешняя (концептуальная модель).
Логическая модель данных.
Физическая модель данных.
Внешняя схема (external schema) представляет обобщенную концептуальную модель данных, необходимую для единственного приложения. Поскольку база данных обычно поддерживает много приложений, конструируются несколько внешних схем. Затем они интегрируются в виде одной концептуальной модели данных. Наиболее известным методом концептуального моделирования данных являются ER-диаграммы (entity-relationship — сущность связь) [51].
Логическая схема (logical schema) (иногда называемая также глобальной концептуальной схемой) представляет модель, которая отражает структуры хранения СУБД. Именно глобальная интегрированная модель поддерживает текущие и перспективные приложения, которым требуется доступ к информации, хранимой в базе данных.
•Физическая схема (physical schema) отражает специфику конкретной СУБД. Она определяет способ фактического хранения данных в энергонезависимых устройствах памяти, как правило, это дисковые накопители. Физическая схема касается таких вопросов, как использование индексов и кластеризация данных для повышения эффективности обработки данных.
Конструкторские CASE-средства (т.е. средства, направленные на проектирование и реализацию систем) предоставляют разработчикам единый метод моделирования данных для логической и физической схемы. Обычно такие средства трактуют подобную комбинированную модель как физическую модель данных.
На рис. 8.1 показано, каким образом в UML моделируется отношение приложения и модели постоянно хранимых объектов базы данных. Классы пакетов-сущностей представляют “бизнес-объекты” приложения. Диаграмма классов UML (для классов- сущностей) может заменить ER-диаграмму в качестве альтернативного средства концептуального моделирования баз данных.
Пакеты баз данных не “направляют” процесс моделирования баз данных, они скорее направляются им. Пакет баз данных изолирует модель приложения от модели базы данных, проектируется одновременно с определением уровня архитектуры постоянно хранимых объектов базы данных или после определения этого уровня. Пакет баз данных разъединяет классы-сущности от схемы базы данных. Он устанавливает отображение между объектами и базой данных.
Рис. 8.1. UML и модели постоянно хранимых объектов
Отображение объектов в базу данных
Отображение между приложением и базой данных, за которое отвечает пакет баз данных, может быть очень запуганным вопросом (разд. 6.1.3). В основе трудностей отображения лежат две фундаментальные причины. Во-первых, структуры хранения базы данных могут не иметь практически ничего общего с объектно-ориентированной парадигмой. Во-вторых, база данных почти никогда не проектируется для единственного приложения.
Первая причина равнозначна преобразованию классов пакета сущностей (разд. 5.2.4 и 6.1.3.2) в отличные от объектно-ориентированных структур, обычно — реляционные таблицы. Даже если целевая база данных является объектной базой данных, особенности базы данных потребуют аккуратного преобразования.
Вторая причина требует оптимального проектирования базы данных для всех приложений, а не только для одного приложения, рассматриваемого в данный момент. Приложениям следует назначить приоритеты с точки зрения их значения для бизнес- процессов, так что структуры базы данных настраиваются на те приложения, которые наиболее важны для организации. Не менее важно, чтобы проектировщик базы данных всегда смотрел вперед, предвидел будущие требования к данным со стороны перспективных приложений и проектировал базу данных таким образом, чтобы адаптироваться к этим требованиям.
Уровень постоянно хранимых объектов базы данных имеет все шансы оказаться реляционной базой данных. Технология реляционных баз данных превалирует на рынке. Что касается баз данных больших предприятий, то их переход на объектную технологию может совершаться эволюционным путем и должен обязательно включать промежуточный (если не конечный) этап освоения объектнореляционной технологии.
Мы начнем рассмотрение с представления идеального, хотя и маловероятного, сценария, в котором в качестве постоянного хранилища используется чисто объектная база данных. Затем обсудим отображение из объектной в объектно-реляционную базу данных. И наконец, мы рассмотрим модель реляционной базы данных, отличающуюся наиболее жесткими ограничениями и, поэтому, наиболее трудную для отображения модель.
Модель объектной базы данных
Модель объектной базы данных (ОБД) доставляет меньше всего хлопот при отображении структур данных между прикладной программой и базой данных. В действительности, главенствующей целью объектной СУБД является прозрачная интеграция базы данных с языком программирования, на котором написано приложение.
Консорциум ODMG (Object Data Management Group — Группа по управлению объектными данными) стандартизировал модель ОБД. Организации, входящие в состав ODMG, представляют всех основных поставщиков ПО СУБД. Совсем недавно ODMG изменила направления своей деятельности, сконцентрировав основные усилия на отображении объектов в реляционные и другие типы баз данных. Эти усилия нашли свое выражение в разработке стандартного API-интерфейса объектной памяти (Object Storage API), который способен работать с любыми постоянными источниками данных. В сущности, этот стандарт можно использовать в качестве пакета баз данных (рис. 8.1) для отображения между приложением и базой данных. Последний стандарт (январь 2000 года) получил название объектного стандарта данных (Object Data Standard): ODMG 3.0 [58].
Стандарт определяет, что система управления объектными базами данных (СУОБД) не обеспечивает отдельного языка для баз данных (наподобие SQL) для манипулирования данными в пределах среды языка программирования. Вместо этого он предусматривает появление объектов базы данных в языке программирования приложений в качестве обычных объектов языка программирования. Другими словами, язык программирования расширяется за счет объектов базы данных, которые реализуют функции постоянного хранения объектов, управления транзакциями, навигационные запросы (т.е. запросы, которые позволяют “перемещаться” вдоль отношений) и т.д.
Кроме того, стандарт включает отдельный язык запросов для доступа к базе данных вне среды языка программирования. Обычно такой язык называют “объектным
SQL" (OSQL). Язык OSQL расширяет возможности запросов реляционного SQL заснет навигационных запросов и возможности обработки более сложных типов данных, таких как шаблоны (разд. 6.2.2.5).
Элементарные типы модели ОБД
Базовыми элементарными типами модели объектной базы данных выступают объект и литерал [58], [20]. Каждый объект обладает идентификатором (OID) (разд. 2.1.1.3). У литерала OID отсутствует — роль идентификатор литерала играет его значение.
В ОБД проводится различие между классом (реализацией) и типом (спецификацией}. Тип может обладать несколькими классами. Например, тип Employee (Сотрудник) может быть реализован в виде Smalltalk-класса и/или Java-класса. Семантика типа позволяет отделить спецификацию от ее различных реализаций. Спецификация абстрактного поведения типа называется интерфейсом. Непосредственно материализовать интерфейс нельзя.
Класс ОБД обладает свойствами и операциями. Свойство может быть атрибутом или отношением (т.е. атрибутом, который связывает объект с одним или несколькими другими объектами).
Типы литералов и объектов
Одним из главных преимуществ ОБД является встроенная поддержка типов литералов и объектов. Это делаем ОБД естественной платформой реализации для объектно-ориентированной разработки ИС. Если переход разработчиков ИС к использованию ОБД и не приобрел массового характера, то только из-за того, что ОБД присущи некоторые другие недостатки (наподобие слабой многопользовательской поддержки), а также благодаря коммерческому и политическому влиянию, оказываемому более мощными производителями СУБД.
Стандарт ODMG 3.0 предусматривает следующие типы литералов [58]:
атомический (простой);
структурный;
коллекция (шаблон);
пустой (null).
Атомические литералы принадлежат к одному из следующих подтипов:
числовой
short (короткое целое со знаком);
long (длинное целое со знаком);
. — unsigned short (короткое без знака);
unsigned long (длинное без знака)';
float ((десятичное) число с плавающей точкой одинарной точности);
double (число с Плавающей точкой двойной точности);
буквенно-цифровые и специальные символы
char (одиночный символ);
string (строка символов);
boolean (т.е. логические значения “истина” или “ложь”);
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 (инициал).
«ODB»
Employee empjd: string emp_name: PersonName date_of_blrth: date gender: enum(M,F} phone_num: array<string> salary: float
Puc. 8.2. Объявление типов в объектной базе данных
Отношения и инверсии
Модель ОБД строится на модельных элементах, рассмотренных в предыдущем разделе. Что касается трех типов отношений (т.е. ассоциации, агрегации и обобщения), модель ОБД непосредственно поддерживает ассоциацию и обобщение. Агрегация поддерживается только с помощью ограничения ассоциации.
Ассоциация реализуется с использованием типов объектов-коллекций, в частности, множества (Seto) и списка (Listo). На практике ассоциации отвечают за переход от реляционно-ориентированного доступа к базе данных, характеризуемого значением, назад к навигационному доступу к базе данных. (Здесь употребляется выражение “переход... назад”, поскольку старомодные сетевые базы данных использовали навигацию в качестве присущего им modus operandi.)
На рис. 8.3 показано, каким образом ассоциация типа “многие ко многим” между классами Student и Courseoffering представляется в модели ОБД. Графическая модель проводит различие между атрибутами и отношениями. Между классами не изображается никаких линий, поскольку свойства отношений (crs_off и std) уже реализуют эту ассоциацию.
Ключевое слово inverse, показанное в определении схемы, накладывает на ассоциацию требование ссылочной целостности (referential integrity) и исключает возможность появления зависших указателей (danglingpointers) (т.е. указателей, указывающих на несуществующие (удаленные) объекты. Прим, ред.) Например, чтобы добавить объект Student к объекту Courseoffering, программист может либо добавить объект Courseoffering (если быть точным— OID объекта) к множеству курсов Set<CourseOffering>, или добавить объект Student к списку студентов List<Student>. После того, как программист изменяет один конец ассоциации, противоположный конец (инверсный) автоматически изменяется СУОБД.
Хотя это и не показано в приведенных выше определениях классов, модель ОБД позволяет задавать ключи (key) — уникальные идентифицирующие значения для объектов классов. В отличие от реляционных баз данных ключ не является единственным или даже главным средством идентификации объектов (этой цели служат значения OID). Однако, иногда для поиска данных в ОБД в качестве дополнительной возможности можно воспользоваться значением ключа.
Ключ может быть простым (simple) или составным (compound) (в последнем случае он состоит более, чем из одного атрибута). Поскольку у класса может быть несколько ключей, для того, чтобы отличать эти ключи друг от друга, можно использовать последовательные номера (или другой визуальный метод).
«0ОВ»CourseOffering«attribute» crs_name: string «attribute» semester: string «relationship» std: List<Student>«0ОВ»CourseOffering«attribute» crs_name: string «attribute» semester: string «relationship» std: List<Student>• «ODB» Student «attribute» name: string ■,
«0ОВ»
CourseOffering
«attribute» crs_name: string «attribute» semester: string «relationship» std: List<Student>
«0ОВ»
CourseOffering
«attribute» crs_name: string «attribute» semester: string «relationship» std: List<Student>
«attribute» studjd: string " -■ Л» ’* «relationship» crs off: Set<CourseOffering>
class Student
attributestringname;
attributestringstud_id;
relationshipSet<CourseOffering>crs-off
inverse CourseOffering: :std;
};
class CourseOffering
attribute
stringcrs_name;
attribute .
stringstud_id;
relationship
List<Student>std
inverse Student: :crs off;
Рис. 8.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 использует ключевое слово inieijace при определении абстрактного класса, наподобие Personinterface. Ключевое слово class используется только для определения конкретного класса, который может быть материализован, например, такого как Managerclass и EmployeeClass.
Рис. 8.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)
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 other_list)
void append(in List other_list)
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). В частности, именно в рамках архитектурного проекта должно быть принято начальное решение в отношении того, где должны выполняться различные процессы — на клиенте или на сервере. Это решение влияет на детализированный проект кооперации и проектирование программ клиент/сервер.
Отображение классов-сущностей
Внимательный читатель наверняка обратил внимание на неудобное для работы с UML-моделями предположение, касающееся того, что атрибуты классов определены на элементарных типах данных и на некоторых встроенных структурированных типах данных (Date, Currency). Ассоциативные роли предполагают, что при проектировании будут использоваться коллекции (шаблоны), однако, решение по поводу коллекций обычно откладывается до тех пор, пока не прояснится вопрос их поддержки со стороны выбранной базы данных и среды программирования.
Но что можно ответить на простые вопросы вроде: “Что если у сотрудника несколько телефонных номеров? Каким образом моделировать эту ситуацию в ходе анализа? Действительно ли необходимо держать отдельный класс для телефонных номеров?” Вероятно, можно задать и другие трудные вопросы, например, такие: “Можно моделировать имя сотрудника в виде одного атрибута, обладающего внутренней структурой, отображающей тот факт, что имя состоит из фамилии, собственно имени и инициала посередине? Действительно ли необходимо держать отдельный класс для имен сотрудников?”
Теоретически UML не препятствует расширению системы типов за счет определения новых классов (в ходе анализа) и использования шаблонов (в ходе проектирования). Практически, чтобы избежать разрастания количества маловажных классов, не следует делать этого до тех пор, пока не прояснится вопрос о поддержке, которую
можно получить со стороны платформы реализации для расширяемой системы типов, а равно и для встроенных структурированных типов и коллекций. В результате, вопросы, наподобие приведенных выше, зачастую попросту игнорируются вплоть до этапа проектирования.
Попробуем прояснить эти и аналогичные вопросы, взяв некоторые из наших моделей анализа и отобразив их в схеме классов ОБД. В этом разделе рассматриваются классы, отличные от классов-сущностей. В последующих разделах мы также рассмотрим отношения между классами-сущностями.
Обратитесь к спецификациям классов для приложения Управление контактами с кли- | ентами в примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Рассмотрите классы Contact и ‘ Employee. Заметим, что приведенные выше вопросы сформулированы применитель- f но к этим двум классам.|
Класс Contact обладает атрибутами family_name и first_name, однако, в нем от- I сутствует понятие “контактного имени" (т.е. имен контактного лица). Аналогично i Employee содержит атрибуты f amily_name, first_name и middle_name, но у нас нет I возможности запросить в базе данных “имя работника”, поскольку подобного понятия j просто не существует."
.I
Класс Contact обладает также атрибутами phone, fax и email. Модель в ее настоя- । щем виде не позволяет контактному лицу иметь более одного номера телефона, фак- ( са или адреса электронной почты — на практике подобное предположение довольно | нереально. •'•
Наша задача в данном примере заключается в отображении классов-сущностей ■ Contact и Employee в проект ОБД. Это отображение должно быть обращено на указан- * ные проблемы.i
Один из вариантов искомого отображения показан на рис. 8.5. Мы ввели два ОБД- интерфейса— PersonShortName (Сокращенное имя лица) и PersonLongNarne (Полное имя лица). Первый интерфейс определяет тип данных для “контактного имени” contact_name. Мы задаем тип для contact_name явно внутри класса Contact и дополнительно через отношение ISA. Строго говоря, отношение ISA является здесь избыточным. Классу Contact не требуется наследовать два отдельных атрибута класса PersonShortName. Он использует PersonShortName только в качестве типа своего собственного атрибута contact_name.
Класс PersonLongNarne наследует два атрибута класса через отноЩение ISA и вместе со. своим собственным атрибутом образует тип д ля атрибута employee name. Как и в предыдущем случае, отношение15А между классами Employee и PersonLongNarne дает только визуальную связь, в остальном же оно является избыточным.
Возможность контактного лица (Contact) обладать несколькими телефонами и факсами, а также адресами электронной почты реализуется с помощью типа set — одного из типов коллекций, поддерживаемых ОБД-системами.
Рис. 8.5. Отображение классов-сущностей на проект ОБД (Управление контактами с клиентами)
Отображение ассоциаций
В UML-моделях ассоциации между классами позволяют осуществлять навигацию по объектам этих классов. Это именно то, что составляет сильную сторону объектной базы данных — навигация по объектам, связанным с помощью идентификаторов постоянных объектов.
Поэтому отображение ассоциаций в ОБД — не вызывающая особых затруднений деятельность, что, собственно, и было продемонстрировано на примере ассоциации между классами Student и Courseoffering в разд. 8.2.1.2 (рис. 8.3). Свойство отношения для класса ОБД обозначается именем класса (или коллекции классов), с которым он связан ассоциативной связью.
В свете сказанного может потребоваться в ходе спецификации отображения оптимизировать проект. В частности, можно принять решение о том, что некоторые атрибуты UML (или классы UML) следует моделировать как интерфейсы ОБД, преследуя при этом цель использования данных интерфейсов как типов для свойств классов ОБД (как показано на рис. 8.5).
Обратитесь к спецификациям ассоциаций для приложения Управление контактами с { клиентами в примере 4.8, рис. 4.5 (разд. 4.2.2.3). Обратитесь также к предыдущему ’ примеру отображения классов-сущностей (рис. 8.5).i
Наша задача заключается в отображении модели, представленной на рис. 4.5, в проект ОБД. В процессе отображения может потребоваться выяснить, какие UML-атрибуты или i классы наилучшим образом подходят на роль интерфейсов ОБД. Затем можно исполь- ■ зовать (повторно использовать) эти интерфейсы для релевантных классов ОБД.j
" Одно из возможных решений для нашего примера показано на рис. 8.6. Помимо введенных в предыдущем примере ОБД-интперфейсов (PersonShortName и PersonLongName) мы создали иерархию наследования (inheritance hierarchy) для ОБД-интерфейса Address. Затем ввели атрибуты объектов postal_address и courier_address внутрь ОБД-классов
ISAISA
ISA
ISA
Organization и Contact в качестве вложенных атрибутов (nested attribute). Ассоциативные связи на рисунке не показаны, поскольку отношения представлены как свойства классов.
«ODB Interfase» PersonShortName family_name: string first name: string
«ODB Interfase» PersonLongName middleJnitial; char
«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» contactJd: 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 Class» Employee «key» emplcyeejd: string emplcyee_name: PersonLongName created_task: List<Task> createdevent: Set<Event> due_event: List<Event> completed e/ent: Set<Evant> «ODB Class» Employee «key» emplcyeejd: string emplcyee_name: PersonLongName created_task: List<Task> createdevent: Set<Event> due_event: List<Event> completed e/ent: Set<Evant>
«ODB Class» Employee «key» emplcyeejd: string emplcyee_name: PersonLongName created_task: List<Task> createdevent: Set<Event> due_event: List<Event> completed e/ent: Set<Evant>
«ODB Class» Employee «key» emplcyeejd: string emplcyee_name: PersonLongName created_task: List<Task> createdevent: Set<Event> due_event: List<Event> completed e/ent: Set<Evant>
«ODB Ciass»
Event description: string task: Task created_dt: date created_emp: Employee due_dtsdate h due_emp: Employee completed_dt: date priority: char
«ODB Class»
Task description: string created_dt: date vaiue: floatft
created_emp: Employee event: Ust<Event> organization: Organization contact: Set<Contact>
Puc. 8.6. Отображение ассоциаций на проект ОБД (Управление контактами с клиентами)
Отображение агрегаций
Как было объяснено ранее (разд. 2.1.4, 4.2.3 и 5.4), UML распознает только две семантики в отношении агрегации — собственно агрегацию с семантикой “по ссылке" и композицию с семантикой “по значению”. Ввиду этих ограничений нотация UML для агрегации конечно не поддерживается напрямую реализацией ОБД (и в этом отношении — любой другой базой данных).
В базе данных отношения агрегации можно моделировать как ассоциации или вложенные атрибуты. Если вводить специальную семантику агрегации, то этого можно добиться скорее с помощью процедурных средств (т.е. ввести семантику прямо в программу), чем декларативных (за счет введения семантики структуры данных).
Принцип отображения агрегаций прост. Агрегация UML отображается в модель ОБД так, как будто это ассоциация. Композиция UML превращается в составной класс ОБД, который содержит вложенные атрибуты, представляющие компонентный класс. Поскольку компонентный класс обладает внутренней структурой (т.е. не является атомическим), О БД-интерфейс должен сначала определяться как структурированный тип объекта. Затем вложенные атрибуты принимают значения объектного типа. В целях достижения определенного уровня эффективности, повторного использования, масштабируемости и приспособленности к сопровождению и т.д. возможно применение некоторых вариантов описанной выше стратегии отображения.
пВМ^МЯМИМг^ВВ*^^^^^Р№^^КИМВМЯ111ИВЯЯИЯМВИ1ММИИИ^ЯВН№1^' ^^т т
I Обратитесь к спецификациям агрегаций для приложения Запись на университетские ' I курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
I Наша задача заключается в отображении модели, представленной на рис. 4.6, в проект ■
I ОБД. Чтобы ввести вложенные атрибуты и упростить модель, может потребоваться on-
| ределить и использовать некоторые ОБД-интерфейсы как типы атрибутов классов.'
На рис. 8.7 показана предлагаемая модель. Мы определили два интерфейса: YearSemester и AcademicRecord. Первый носит лишь “косметический” характер — модель может обойтись без него. Второй необходим для определения UML- композиции как вложенного атрибута academic record класса Student.
UML-агрегация между классами Course и Courseoffering моделируется как обычная ассоциация. Семантику агрегации может потребоваться ввести процедурно. Свойства отношения определяют отношение агрегации и ассоциации, представленное на рис. 4.6.
8.2.2Л. Отображение обобщений
Отображение отношения обобщения UML на отношения ISA и EXTENDS ОБД является по существу, отношением "один к одному”. Отношение ISA является результатом наследования от ОБД-интерфейса. Наследование от класса ОБД моделируется с помощью отношения EXTENDS.
Преобразование модели обобщения UML в модель ОБД показано на рис. 8.8. Поскольку иерархия обобщения на рис. 4.7 представляла наследование интерфейса, мы использовали отношение ISA OMG.
Класс, UML Rentalconditions преобразуется в ОБД-интерфейс. Этот ОБД- интерфейс используется как структурированный объектный тип для атрибута rental_cond, встроенного в ОБД-интерфейс VideoMedium. Мы принимаем, что класс Rentalconditions является свойством VideoMedium и, следовательно, должен быть встроен в конкретный класс, наследуемый из интерфейса VideoMedium (т.е. BetaTape, VHSTape и DVDDisk).
«ем^ s^s® ^^>■
т^^йУ?-;;»*#<^ жМж- S^t^^SS^^*^#»^ f
Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в примере 4.10, рис. 4.7 (разд. 4.2.4.3).
Наша задача заключается в отображении модели, представленной на рис. 4.7, в проект ' ОВД. Хотя подклассы UML-модели не содержат саоих собственных атрибутов (пока что), *■ мы предполагаем, что они отличаются по состоянию и поведению и в свое время к этим : классам будут добавлены свойства.
«ODB interfase»YearSemesteryear: datesemester: unsigned short«ODB interfase»YearSemesteryear: datesemester: unsigned short<<ODB Class»
«ODB interfase»
YearSemester
year: date
semester: unsigned short
«ODB interfase»
YearSemester
year: date
semester: unsigned short
Course course_code: string course_name: string
creditjpoints: unsigned short
course offering: list<CourseOffering>
«ODB Class»AcademicRecdrd • course_code: string year_sem: YearSemester grade: string«ODB Class»AcademicRecdrd • course_code: string year_sem: YearSemester grade: string» •-< ^ «ODB Class» -^«Student ■ . student id:string й-student_name: string currentjees: float*course_off: list<CourseOffering> academic ^record: s&<AcademicRecord>» •-< ^ «ODB Class» -^«Student ■ . student id:string й-student_name: string currentjees: float*course_off: list<CourseOffering> academic ^record: s&<AcademicRecord>«ODB Class»Courseoffering year_sem: YearSemester enrolment_quota: unsigned short course: Coursestudent: list<Student> academic in charge: AcademicinCharge«ODB Class»Courseoffering year_sem: YearSemester enrolment_quota: unsigned short course: Coursestudent: list<Student> academic in charge: AcademicinCharge«ODB Class»AcademicinChargecourse off: list<CourseOffering>«ODB Class»AcademicinChargecourse off: list<CourseOffering>
«ODB Class»
AcademicRecdrd • course_code: string year_sem: YearSemester grade: string
«ODB Class»
AcademicRecdrd • course_code: string year_sem: YearSemester grade: string
» •-< ^ «ODB Class» -^
«Student ■ . student id:string й-
student_name: string currentjees: float*
course_off: list<CourseOffering> academic ^record: s&<AcademicRecord>
» •-< ^ «ODB Class» -^
«Student ■ . student id:string й-
student_name: string currentjees: float*
course_off: list<CourseOffering> academic ^record: s&<AcademicRecord>
«ODB Class»
Courseoffering year_sem: YearSemester enrolment_quota: unsigned short course: Course
student: list<Student> academic in charge: AcademicinCharge
«ODB Class»
Courseoffering year_sem: YearSemester enrolment_quota: unsigned short course: Course
student: list<Student> academic in charge: AcademicinCharge
«ODB Class»
AcademicinChargecourse off: list<CourseOffering>
«ODB Class»
AcademicinChargecourse off: list<CourseOffering>
Puc. 8.7. Отображение агрегаций на проект ОВД (Запись на университетские курсы)
Рис. 8.8. Отображение обобщений на проект ОВД (Магазин видеопроката)
Объектно-реляционная модель базы данных
Следующей “большой волной” в области технологий баз данных является объектно-реляционная модель [87]. Как ясно из названия, объектно-реляционная база данных (ОРБД) сочетает в себе старомодную реляционную модель и новомодную объектную модель. Одна и та же объектно-реляционная система управления базами данных (СУОРБД) способна обрабатывать реляционные структуры данных (реляционные таблицы) и объектные структуры данных (объектные таблицы).
Стандарт для модели ОРБД был согласован в 1999 году, после более чем шестилетней разработки (этот стандарт известен под неофициальным именем SQL3). Данный стандарт является результатом труда Американского национального института стандартов (American National Standards Institute — ANSI) и Международной организации по стандартизации (International Organization for Standardization — ISO). Официальное название этого стандарта SQL:1999 [21]. Стандарт оставил многие вопросы, касающиеся ОРБД, нерешенными и должен по положению пересматриваться примерно раз в три года.
Модель ОРБД совместима “снизу вверх’’ с последним стандартом для реляционных баз данных — так называемым стандартом SQL92. Модель расширяет традиционные возможности реляционных таблиц за счет нового механизма, позволяющего хранить объекты в SQL таблицах. Модель также расширяет ограниченную реляционную поддержку для определяемых пользователем типов за счет введения произвольных сложных структурированных типов (чтобы инкапсулировать атрибуты и операции в одном объектном типе — классе).
Хотя стандарт развивался (и продолжает развиваться), большинство поставщиков реляционных баз данных (Oracle, IBM, Informix) взялись за задачу поставки продуктов для СУОРБД, обеспечивающих по меньшей мере частичную поддержку модели ОРБД. Одной из основных проблем для поставщиков остается интеграция ранее существовавших реляционных возможностей с новыми объектно-ориентированными, чтобы сделать возможным беспрепятственный перенос реляционных систем в решения, основанные на использовании ОРБД. Стандарт SQL: 1999 фактически не касается этой проблемы.
В последующем изложении мы стремимся придерживаться спецификаций SQL: 1999 [21], однако, время от времени обращаемся к рассмотрению реальных продуктов СУОРБД (в частности, для Oracle 8), чтобы подчеркнуть различия между теорией и практикой.
Элементарные типы модели ОРБД
Элементарные типы модели ОРБД включают новые объектные элементарные типы и прежние реляционные элементарные типы. Принципиально новым объектным элементарным типом является определяемый пользователем структурированный тин, соответствующий нотации ОБД для интерфейса и нотации UML для класса.
Структурированный тип определяется заданием его атрибутов и операций. Его можно также определить как подтип другого структурированного типа. На самом деле модель ОРБД поддерживает множественное наследование интерфейса (разд. 5.3.3).
В качестве механизма хранения данных используется таблица. Столбцы таблицы могут принимать значения структурированных типов, определяемых пользователем. В некоторых реализациях СУОРБД (например, в OracleS) подобные таблицы называются объектными таблицами, чтобы отличить их от традиционных реляционных таблиц.
В ОРБД также поддерживаются структурированные типы и типы коллекций, введенных для ОБД. Специальный вид структурированного типа— называемого строчным типом (row type) — позволяет задать вложенные структуры данных в рамках объектных таблиц. Строчный тип можно также использовать для определения ссылочного типа (reference type). Ссылки обеспечивают возможности навигации по объектам.
Особые и структурированные типы
Поля столбцов в таблице ОРБД могут принимать значения встроенных типов или типов, определяемых пользователями. Что касается встроенных типов, то возможности ОРБД аналогичны возможностям, которые обычно реализуются ОБД (разд. 8.2.1.1). То же самое можно сказать в отношении встроенных операций.
Типы данных, определяемые пользователями, можно разделить на две категории:
особый тип (distinct type) — выражается в виде единственного предопределенного типа, называемого исходным типом (source type) (особый тип соответствует атомическому объектному типу стандарта ODMG);
структурированный тип (structured type) — выражается в виде списка определений атрибутов и операций (структурированный тип соответствует структурированному объектному типу стандарта ODMG).
Структурированный тип позволяет пользователям вводить свои собственные именованные типы. Определение структурированного типа состоит из объявления следующих компонент.
Атрибуты, представляющие состояние объектов структурированного типа.
Операции, определяющие поведение объектов структурированного типа.
Операции, определяющие эквивалентность/неэквивалентность, упорядоченность и преобразование объектов структурированного типа (необходимы, если нам требуется сравнивать два объекта структурированного типа на эквивалентность, некоторым образом сортировать их или преобразовывать из одного структурированного типа в другой).
Структурированный тип атрибута может определяться с помощью исходного типа, особого типа, типа коллекции или другого структурированного типа. Стандарт SQL: 1999 определяет следующие типы коллекций (продукты ОРБД могут определять больше типов коллекций): -
множество (set);•
список (list);
мультимножество (multiset) (тип, аналогичный типу ба^ОБД);
массив (array).
На рис. 8.9 показано определение структурированного типа для класса Employee, соответствующее определению для ОБД, приведенному на рис. 8.2. При сравнении определений видно, что их различия незначительны и связаны со встроенными исходными типами (если речь не идет о конкретной СУОРБД, их выбор довольно произволен). Атрибут gender (род) введен как char, поскольку типичная СУОРБД, как правило, не поддерживает тип enum. Аналогичного результата для ОРБД можно достичь, задав проверку ограничения (check constraint) на типе gender (разд. 8.4).
«structured type»
Employees
empJd: char(7)
emp_name; PersonName
date_of_birth: date gender:char phonenuni: set(varchar(12)) salary : money
Puc. 8.9. Объявление типов в объект-нореляционной модели базы данных
Объектные таблицы
Таблица (объектная таблица) представляет собой множество строк и столбцов. При этом строка может состоять из стольких полей, сколько столбцов содержит таб-
лица объектов. Строка таблицы {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)). Они, соответственно, позволяют зачитывать и модифицировать каждый атрибут.
Строчные типы
Строчный тип {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) )) ) ; 1
С точки зрения программирования баз данных строчные типы дают возможность хранить полные строки таблицы в переменных, передавая их в качестве входных аргументов операций и возвращая их как выходные аргументы операций или возвращаемых значений.
Ссылочные типы
Структурный тип можно использовать для определения ссылочного типа (reference type). Для определения ссылки используется ключевое слово ref. Например, етр ref (EmployeeTY) представляет собой ссылку в объектной таблице на структурированный тип. В SQL:1999 ссылочные типы обладают областью действия— таблица, на которую они ссылаются, известна во время компиляции (т.е. динамическая классификация не поддерживается (см. разд. 2.1.5.2.3)).
Как И следовало ожидать, значением ссылочного типа является OID, и оно уникально в пределах базы данных; указывает на строку в таблице, которая допускает ссылки на нее (referenceable table). Эта подходящая для ссылок таблица должна быть типизированной таб лицей (typed, table), т.е. таблицей с ассоциированным структурированным типом. Ссылочные типы можно использовать в ОРБД для реализации ассоциаций “один к одному".
‘ Для реализации ассоциаций “многие ко многим" можно использовать коллекции (разд. 8.3;1.1) ссылок— при их наличии. На рис. 8.10 использован пример, представленный на рис. 8.3, чтобы продемонстрировать, каким образом можно представить в ОРБД ассоциацию “многие ко многим" между объектами Student и Courseoffering.
«object table» Courseoffering crs_name: varchar(40) semester: char std: list(ref(Student)«object table» Courseoffering crs_name: varchar(40) semester: char std: list(ref(Student)«object table» Student name: varchar(60) .' ^v studjd:: char(8)
«object table» Courseoffering crs_name: varchar(40) semester: char std: list(ref(Student)
«object table» Courseoffering crs_name: varchar(40) semester: char std: list(ref(Student)
crs off: set(ref(CourseOffering))
Puc. 8.10. Ассоциация в объектно-реляционной модели базы данных
Столбцы, поля и атрибуты
Стандарт SQL:1999 проводит четкое различие между понятием столбцов, полей и атрибутов [83]. Это важное терминологическое уточнение. Ниже приводится смысл различий.
Столбец (column) — это структурный компонент таблицы.
Поле (field) — это структурный компонент строчного типа.
Атрибут (attribute) — это структурный компонент структурированного типа.
Столбец доступен для пустых значений (nullable) и может принимать значения NULL. Он может быть также идентифицирующим столбцом (принимающим значения OID). Типом данных столбца, поля и атрибута может быть ссылочный тип.
Наследование типа OF и UNDER
Стандарт SQL:1999 допускает специализацию существующих типов. В настоящее время допустимо только одинарное наследование. Иерархию таблиц можно создать в соответствии с иерархией типов, т.е. “супертаблица” должна быть объявлена как “принадлежащая” (англ, “of”) супертипу, а “подтаблица” как "принадлежащая” подтипу. Однако, в иерархии таблицы тип может быть “пропущен", как показано на рис. 8.11.
Программа на языке SQL:1999, приведенная ниже диаграммы на рис. 8.11, относится к типу с наиболее сильной специализацией (ManagerTY) и к таблице (Manager). Ключевое слово under используется в SQL: 1999 для установления иерархии типов и иерархии таблиц. Ключевое слово of устанавливает структурированный тип таблицы.
Мы также используем ключевое слово 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 наследование является одинарным наследованием реализации.
Отображение в ОРБД
Так же, как в случае модели ОВД, отображение классов UML, содержащихся в пакете сущностей, в проект схемы ОРБД может быть осуществлено средствами самого UML. Стереотипов UML и других механизмов расширяемости должно быть достаточно для выражения понятий ОРБД.
Заметим, однако, что на практике отображение осуществляется не по отношению к “абстрактному” стандарту SQL:1999, а к реальному продукту ОРБД. Реальный продукт может не поддерживать некоторых возможностей SQL: 1999 и, в то же время, может обладать возможностями, не представленными в SQL:1999.
Поэтому, например, текущая версия Огас1е8 (на момент написания книги — редакция 8.1.5.0.0 Oracle8i) не поддерживала ни наследования, ни строчного типа. В качестве типа коллекции она включала только массив и не включала каких-либо других типов коллекций, а также включала понятие вложенной таблицы, которая допускала вложенную таблицу ссылок. Она включала понятие представления объекта для “преобразования” реляционных таблиц в объекты и т.д.
Отображение классов-сущностей
Обратитесь к спецификациям классов для приложения Управление контактами с клиента- ; ми е примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Обратитесь также к примеру 8.1 (разд. 8.2.2.1). 5 Наша задача заключается в разработке проекта модели ОРБД, семантически соответст- ? вующей проекту ОВД, представленному на рис. 8.5. 1
Рис. 8.12. Отображение классов-сущностей в проект схемы объектнореляционной модели базы данных (Управление контактами с клиентами)
Этот пример требует принять решение по поводу того, каким образом отобразить ОБД-интерфейсы (рис. 8.5). В SQL: 1999 интерфейсы не поддерживаются, но нам по- прежнему необходимо некоторым образом моделировать классы PersonShortName и PersonLongName.
Рис. 8.12 демонстрирует два возможных решения. В случае класса PersonLongName для него создается структурированный тип. Затем он используется в качестве типа атрибута EmployeeTY. В случае класса PersonShortName мы создаем класс (person short name) для “имитации" строчного типа (строчный тип — это не объектно-ориентированное понятие!). Таблица Contact принадлежит типу ContactTY, однако, она включает дополнительный столбец person_short_name, принадлежащий строчному типу. Отношение зависимости по отношению к классу person_short_name используется для отображения структуры строчного типа.
Отображение ассоциаций
Обратитесь к спецификациям ассоциаций для приложения Управление контактами с 5 клиентами в примере 4.8, рис. 4.5 (разд. 4.2.2.3). Обратитесь также к предыдущему : примеру отображения для приложения “Управление контактами с клиентвми”, приве- ! денному в разд. 8.2.2.2 и 8.3.2.1. • j
Задача в этом примере заключается в разработке проекта модели ОРБД, семантически | соответствующей проекту ОВД. представленному на рис. 8.6 (разд. 8.2.2.2). Чтобы уп- i ростить решение и в то же время сконцентрироваться на спецификации ассоциации, j предположим, что все ОБД-интерфейсы, приведенные на рис. 8.6, преобразованы к i | строчному типу нашего проекта ОРБД (в решении нет необходимости показывать опре- ; j деления строчных типов).;
Наше решение для примера показано на рис. 8.18. Объектные таблицы содержат столбцы, типизированные как строчные типы, и столбцы, типизированные как ссылочные типы. Структурные типы содержат атрибуты, типизированные как исходные типы или как коллекции исходных типов.
Отображение агрегаций
j Обратитесь к спецификациям агрегаций для приложения Запись на университетские ' ( курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
j Наша задача в этом примере заключается в отображении UML-модели, показанной на ;
| рис. 4.6, в проект схемы ОРБД. Хотя мы разработали проект ОБД для этой проблемы в
I
" примере 8.3, мы не желаем оказаться под его влиянием при решении данного примера. > Мы предполагаем, что коллекции структурированных типов (не только коллекции элемен- j тарных исходных типов) поддерживаются как типы атрибутов в структурированных типах. ;
При разборе этого примера требуется принять решение по поводу того, каким образом моделировать в терминах ОРБД UML-агрегацию и UML-композицию. Предположение, изложенное в определении примера, дает нам четкие указания. Композицию между классами Student и AcademicRecord можно моделировать в классе Student с помощью атрибута, типизированного как коллекция классов AcademicRecord. Это показано на рис. 8.14. Коллекция представляет собой множество set (AcademicRecordTY).
Рис. 8.13. Отображение ассоциаций в проект схемы объектнореляционной модели базы данных (Управление контактами с клиентами)
UML-агрегацию между классами Course и Courseoffering можно моделировать как обычную ассоциацию — с помощью ссылок. Для каждой таблицы объектов необходимо задать соответствующий структурированный тип. Это необходимо, помимо
прочего, с точки зрения того требования стандарта языка SQL:1999, что значение типа ref должно идентифицировать строку в типизированной таблице (т.е. таблице заданного структурированного типа).
Рис. 8.14. Отображение ассоциаций в проект схемы объектнореляционной модели базы данных (Управление контактами с клиентами)
Отображение обобщений
Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в ; примере 4.10, рис. 4.7 (разд. 4.2.4.3). Обратитесь также к предыдущему примеру ото- 7 бражения обобщений в проект ОВД в разд. 8.2.2.4.
Наша задача заключается в разработке проекта модели ОРБД, семантически соответст- ? вующей проекту ОБД, представленному на рис. 8.8. (разд. 8.2.2.4).
Поскольку у нас нет уверенности в том, каким образом модель ОРБД должна поддерживать i выводимые и статические атрибуты, мы предполагаем, что они вычисляются процедурно и моделировать их в качестве структур данных ОРБД нет необходимости. Рассмотрение каса- " ется двух атрибутов: is_in_stock (взвпасе) и number_currently_available (в наличии).
Основная трудность при решении этого примера имеет только косвенное отношение к отображению обобщения. Основная проблема связана с ограничением стандарта SQL:1999, которое выражается в том, что значение ссылочного типа ref “заключено” в пределах области действия. В области действия типа ref может находиться только одна таблица, и эта область действия должна быть известна статически — во время компиляции.
Перед этим мы связали класс MovieTitle с интерфейсом VideoMedium в предположении, что любой объект VideoMedium (т.е. BetaTape, VHSTape или DVDDisk) связан с MovieTitle. Теперь же, чтобы справиться с проблемой, мы вынуждены создать в MovieTitle три ассоциации. Полностью решение приведено на рис. 8.15.
Рис. 8.15. Отображение обобщения в проект схемы объектнореляционной модели базы данных (Магазин видеопроката)Рис. 8.15. Отображение обобщения в проект схемы объектнореляционной модели базы данных (Магазин видеопроката)
Рис. 8.15. Отображение обобщения в проект схемы объектнореляционной модели базы данных (Магазин видеопроката)
Рис. 8.15. Отображение обобщения в проект схемы объектнореляционной модели базы данных (Магазин видеопроката)
Модель реляционной базы данных
В течение последних двадцати лет реляционная модель господствовала на рынке ПО баз данных. Модель реляционной базы данных (РБД) пришла на смену иерархической и сетевой моделям баз данных. Во второй половине 1990-х годов поставщики реляционных систем управления базами данных (СУРБД) постоянно увеличивали свое внимание к модели объектной базы данных, стандартам ODMG и различным продуктам СУОБД. ,
Как следствие возник целый ряд продуктов СУОБД, которым сегодня прочат ведущую роль в будущем. Поставщики традиционных СУРБД, такие как Oracle, IBM или Informix, предлагают сегодня продукты, которые оказывают наибольшее влияние на этот сегмент рынка. (Компания Informix вместе с соответствующими продуктами была приобретена в 2001 году компанией IBM. Прим. ред.). Между тем слабые продукты СУОБД не увеличили своей рыночной доли, более того, произошел сдвиг в самом их назначении — они превратились в API-интерфейсы хранилищ объектов, предназначенные для поддержки интероперабельности клиентских приложений и различных серверных источников данных, в частности, реляционных баз данных.
Хотя будущее более и не принадлежит моделям РБД, инерция развития бизнеса такова, что должно пройти десятилетие, если не больше, прежде чем станет заметным переход больших систем на технологию ОРБД или ОБД. Кроме того, в ближайшем будущем появится огромное количество приложений, разработанных в технологии РБД, просто потому, что предприятия и организации стремятся избегать сложных и трудных в освоении объектных решений.
Ныне действующий (и последний из разработанных) стандарт для модели РБД известен как стандарт SQL92. Он был принят ANSI и ISO в 1992 году. Подавляющее большинство продуктов СУРБД на рынке (Oracle, DB2, Sybase, Informix, Microsoft SQL Server и др.) соответствуют этому стандарту, хотя каждый в своей собственной манере. Фактически, некоторые концепции РБД (например, триггер (trigger)) уже были широко реализованы в продуктах СУРБД, прежде чем получили официальное признание в рамках стандарта SQL: 1999.
Элементарные типы модели РБД
Элементарные типы модели РБД, конечно же, элементарны по определению. Простота модели РБД, которая вытекает из математического понятия множества, .составляет как сильную, так и слабую стороны этой модели. Математический фундамент, на котором зиждется реляционная модель, определил ее декларативный характер (в противоположность процедурному). Пользователь просто объявляет, что ему требуется получить от базы данных, а не инструктирует систему о том, как именно отыскать нужную информацию (СУРБД знает, как искать данные в своей базе данных).
. Однако то, что кажется простым поначалу, становится довольно сложным вместе с ростом сложности решаемой проблемы. Для сложных проблем нет простых решений. Чтобы решить сложную проблему, требуются тонкие механизмы. Чтобы приступить к моделированию, потребуются развитые элементарные типы данных.
Наверное лучший путь охарактеризовать модель РБД — сформулировать, какие из элементарных типов она не поддерживает. Из основных элементарных типов моделирования, применяемых в моделях ОБД и ОРБД, реляционная модель не поддерживает следующих.
Объектные типы и связанные с ними понятия (такие, как наследование или методы).
Структурированные типы.
Коллекции.
Ссылки.
Основным элементарным типом модели РБД является реляционная таблица (relational table), которая состоит из столбцов. Столбцы таблицы могут принимать только атомические значения — структурированные значения или значения коллекций не допускаются.
Модель РБД ведет себя весьма жестко в отношении любых видимых пользователю навигационных связей между таблицами — они исключаются. Отношения между таблицами поддерживаются с помощью сравнения значений в столбцах. Постоянные связи отсутствуют. Полезное свойство ОРБД по поддержанию предопределенных отношений между таблицами называется ссылочной целостностью (referential integrity).
На рис. 8.16 показаны элементарные типы модели РБД и зависимости между7 ними. Все понятия выражены с помощью существительных в единственном числе, однако, некоторые зависимости применимы, более чем к одному экземпляру понятия. Па- пример, ссылочная целостность определяется на одной или более таблицах. Большая часть понятий, приведенных на рис. 8.16, рассматривается в последующих разделах этой главы. Другие понятия более подробно рассмотрены в главе 9.
Рис. 8.16. Зависимости между элементарными типами модели РБД
Столбцы, домены и правила
Реляционные базы данных определяют данные в столбцах и строках. Значение данных, хранимых на пересечении любого столбца и строки, должно быть простым (неделимым) и однократным (не повторяющимся) значением. Мы. говорим, что столбцы образуют атомические домены (atomic domains) (типы данных).
Домен (domain) определяет допустимое множество значений, которое может принимать столбец. Домен может быть безымянным (например, gender char (1)) или может быть поименован (например, gender Gender). В последнем случае домен Gender был определен ранее и используется в определении столбца. Ниже приводится возможный синтаксис определения домена.
create domain Gender char(l);
Именованный домен.можно использовать для определения многих столбцов в различных таблицах. Это способствует достижению непротиворечивости между этими определениями. Изменения, вносимые в определение домена, автоматически отражаются на определении столбца. Хотя подобная возможность и выглядит на первый взгляд довольно привлекательно, ее использование тут же становится помехой, как только база данных заполняется, т.е. загружается данными.
Со столбцами и доменами могут быть связаны некоторые бизпес-правила, накладывающие на них ограничения. Бизнес-правила могут определять следующие характеристики данных.
Значение, используемое по умолчанию (например, если для города (city) не задано никакого значения, предполагается значение “Сидней”).
Диапазон значений (например, допустимое значение для возраста (аде) лежит в пределах от 18 до 80).
Список значений (например, допустимыми цветами (color) могут быть “зеленый", “желтый” или “красный”).
Регистр, используемый для представления значения (например, значение должно состоять из символов верхнего или нижнего регистра клавиатуры).
Формат значения (например, значение должно начинаться с буквы “К").
С помощью средств задания правил можно определить только простые правила, относящиеся к единственному столбцу или домену. Более сложные правила, охватывающие таблицы, можно определить с помощью правил ограничения целостности. Основным механизмом определения бизнес-правил являются триггеры.
Реляционные таблицы
Реляционная таблица (relational table) определяется фиксированным множеством своих столбцов. Типы данных, которые хранятся в столбцах, относятся к встроенным или определяемым пользователем типам (т.е. доменам). Таблица может содержать произвольное количество строк (или.записей). Поскольку таблица есть не что иное, как математическое множество, повторяющиеся строки в таблице отсутствуют.
Для некоторых столбцов допускается, что значение столбца в определенной строке может принимать значение NULL. Значение NULL означает одну из двух возможностей: “не определенное в данный момент значение” или “неприменимое значение” (разд. 8.2.1.1).
Одним из следствий требования к модели РБД, которое состоит в недопустимости дублирования строк, является наличие у каждой таблицы первичного ключа (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
VARCHA(?(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_hame и first_name. Столбцы не сгруппированы и никак не связаны в модели. В последнем случае мы предпочли решение с двумя’ столбцами (phone numl, phone_num2 ), допускающими наличие максимум двух телефонных номеров у каждого работника.
После того, как таблица определена с помощью CASE-средств, можно автоматически сгенерировать программный код для создания таблицы, как показано ниже. Сгенерированный текст программы включает определение домена Gender и определение бизнес-правила, определенного на этом домене.
— 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’
1,'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) ) ;
Ссылочная целостность
Модель РБД поддерживает отношения между таблицами посредством ограничений ссылочной целостности. Отношения не привязаны к связям отдельных строк между собой. Вместо этого РБД “отыскивает" связи между строками всякий раз, когда пользователь просит систему отыскать соответствующие отношения. Это “нахождение” осуществляется с помощью сравнения значений первичных ключей в одной таблице со значениями внешних ключей в той же самой или другой таблице.
Внешний ключ (foreign kef) определяется как множество столбцов в одной или более таблицах, значения которых либо равны NULL, либо должны совпадать со значениями первичного ключа в той же самой или другой таблице. Это соответствие между первичным и внешним ключом называется ссъигочной уелостностъю. Первичный и внешний ключи, участвующие в определении ссылочной целостности, должны быть определены на одном и том же домене, однако, они не обязательно должны иметь одинаковые имена.
На рис. 8.18 показано графическое представление ссылочной целостности. В результате изображения отношения между таблицами Employee и Department к таблице Employee был добавлен внешний ключ dept_id. Для каждой строки таблицы Employee значение внешнего ключа должно быть либо равно NULL, либо совпадать с одним из значений dept_id в таблице Department (в противном случае сотрудник может работать в несуществующем подразделении).
Department^
Employee
dept id SMALLINT<pk> not null
emp idCHAR(7)<pk> not null
dept_name VARCHAR(SO)not null
address VARCHAR(120)null
deptjdSMALUNT<tk> null
family_nameVARCHAR(30) <ak> not null
first_nameVARCHAR(20)notnull
date_of_birth DATE<ak> not null
genderGendernotnull
phone_num1VARCHAR(12)null
phone_num2VARCHAR(12)null
salaryDEC(8,2)null
deptjd = deptjd Upd(R); Del(R)
O..n
Рис. 8.18. Ссылочная целостность
Дополнительное описание, сопровождающее линию отношения, декларативно определяет поведение, связанное со ссылочной целостностью. Существует четыре возможных декларативных ограничения ссылочной целостности, связанных с операциями delete и update. К именно, вопрос состоит в том, что делать со строками таблицы Employee при удалении или обновлении строк таблицы Department (т.е. обновляется столбец dept_id). На этот вопрос существует четыре варианта ответа.
Upd (R) ; Del (R) — ограничить операции update или delete (т.е. не давать возможности операции выполниться, если только еще в таблице Employee существуют строки, связанные с данным подразделением — Department).
Upd (С) ; Del (С) — каскадировать операцию (т.е. удалить все строки таблицы Employee, связанные с данным подразделением — Department).
Upd (N); Del (N) — установить значение ключа равным null (т.е. обновить или удалить строку таблицы Depar tment и установить ключ dept_id для связанной строки таблицы Employee в NULL).
Upd(D); Del (D) — установить значение ключа равным значению, принятому по умолчанию (т.е. обновить или удалить строку таблицы Department и установить ключ dept_id для связанной строки таблицы Employee равным значению по умолчанию).
Рис. 8.19. Ссылочная целостность для отношений “многие ко многим”
Моделирование ссылочной целостности усложняется, когда отношение между таблицами принимает характер “многие ко многим”, как в случае отношения между классами Student и Courseoffering (рис. 8.3 в разд. 8.2.1.2). Чтобы справиться с проблемой, вызванной ограничением на РБД, которое выражается в недопустимости принятия столбцом множественных значений, нам требуется ввести перекрест таблицу (intersection table) наподобие таблицы StdToCrsOff, показанной на
Единственным назначением этой таблицы является моделирование отгний “многие ко многим" и задание декларативных ограничений ссылочной стности.
Триггеры
равила и декларативные ограничения ссылочной целостности позволяют определять тые бизнес-правила на базе данных. Их недостаточно для определения более ;ных правил или каких-либо исключений из правил. Применительно к РБД ре- <ем данной проблемы (в соответствии со стандартом SQL: 1999) является триг- rigger).
риггер — это небольшая программа, написанная в расширенном языке SQL, коя выполняется автоматически (запускается) в результате операции модифика- таблицы, над которой определен триггер. В качестве операции модификации ;т выступать любой оператор" модификации языка SQL: insert, update или >te..
риггер можно использовать для реализации бизнес-правил, которые выходят за и возможностей оператора rule правил SQL (разд. 8.4.1.1). Например, бизнес- ило, которое запрещает вносить изменения в таблицу Employee во время выход- можно запрограммировать в виде триггера. Любая попытка применить к табли- тератор SQL insert, update или delete в выходные дни приводит к срабатыва- триггера, и база данных отказывается выполнять операцию.
риггер можно также использовать для приведения в действие более сложных ог- [чений ссылочной целостности. Например, наше бизнес-правило может гласить, при удалении строки таблицы Department (подразделение) строка таблицы .оуее, которая представляет информацию о работнике, который является ме- сером этого подразделения, также должна быть удалена. При этом для всех ос- ных работников (не менеджеров) значения dept_id должны быть установлены в j. Подобное би нес-цравило невозможно ввести декларативно. Чтобы привести . исполнение, необходимо задействовать процедурный триггер.
ели для введения ссылочной целостности над базой данных используются триг- I, декларативные ограничения ссылочной целостности обычно ликвидируются, пение процедурных и декларативных ограничений — плохая идея, поскольку зна- льно затрудняет их взаимодействие. Как следствие, сегодня преобладает практи- жх>граммирования ограничений ссылочной целостности только на основе триггеров. Проблема на самом деле не так страшна, как может показаться на первый взгляд, поскольку мощные CASE-средства способны генерировать большую часть программного кода автоматически.,«
Например, ниже приведена программа для триггера, сгенерированная с помощью CASE-средств для СУРБД Sybase. Триггер реализует декларативное ограничение Del (г) — т.е. он не позволяет удалить строку таблицы Department до тех пор, пока существует хоть одна строка таблицы Employee, связанная с ней.
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 разрешается удалить.
Реляционные представления
Реляционное представление {relational view) (иногда называемое сленговым термином взгляд. Прим, ред.) — хранимый и поименованный SQL-запрос. Поскольку результатом любого SQL-запроса является переходная таблица, представление может использоваться вместо таблицы в другом SQL-операторе, выводиться на основе одной или более таблиц и/или одного или более других представлений (рис. 8.16).
EmpNoSalary Employee.emp_id 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. Реляционное представление
На рис. 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.first_name,
Employee.date_of_birth, Employee.gender, Employee.phone_numl, Employee.phone_num2 from Employee;
Теоретически представление являет собой очень мощный механизм, который находит множество применений; использоваться для поддержки безопасности базы данных за счет ограничения круга пользователей, имеющих возможность просмотра таблицы; представить данные пользователю в различных разрезах. Оно может изолировать приложение от изменения определений таблицы, если изменяемое определение не составляет части представления. Оно позволяет упростить выражения для сложных запросов — запрос может быть встроен в манере “разделяй и властвуй” за счет использования нескольких уровней представлений.
На практике использование концепции представления в модели РБД жестко oq>a- ничено из-за невозможности обновления представления. Обновление представления эквивалентно возможности отправки операции модификации (SQL-операторы insert, update или delete) представлению и изменению в результате базовых таблиц базы данных. Поддержка обновления представления в рамках стандарта SQL92 весьма ограничена — она практически отсутствует.
Нормальные формы
Можно с уверенностью утверждать, что одной из наиболее важных, но в то же время недооцениваемых концепций проектирования РБД является нормап изо пил (normalization). Реляционная таблица должна быть представлена в нормальной форме (НФ). Существует шесть типов нормальных форм.
1-я НФ
2-я НФ
3-я НФ
НФБК (Нормальная форма Бойса-Кодда (Boyce-Codd))
4-я НФ
5-я НФ
Таблица, представленная в младшей нормальной форме, также представлена и в более старшей НФ. Она должна быть приведена, по меньшей, мере в 1-й НФ. Таблица, в которой отсутствуют структурированные или многозначные столбцы, выражена в 1й НФ (и это составляет фундаментальное требование модели РБД).
Таблица в младшей НФ может проявлять так называемые аномалии обновления. Аномалия обновления—это нежелательный побочный эффект, возникающий в результате выполнения операции модификации (insert, update, delete) над таблицей. Например, если одна и та же информация многократно повторяется в одном и том же столбце таблицы, обновление этой информации должно осуществляться в каждом месте ее хранения, иначе база данных останется в некорректном состоянии. Можно показать, что аномалии обновления постепенно устраняются по мере перехода к старшим НФ.
Итак, каким образом можно нормализовать таблицу к старшей НФ? Таблиц}' можно привести к старшей НФ, разделив ее по вертикали вдоль столбцов на две или более таблицы меньшего размера. Эти меньшие таблицы, скорее всего, окажутся в старшей НФ и заменят исходную таблицу в проекте модели РБД. Исходная таблица, однако, может всегда быть восстановлена с помощью объединения меньших таблиц с использованием SQL-оператора join.
Рамки этой книги не позволяют нам рассмотреть теорию нормализации сколько- нибудь подробно. За подробностями читатель может обратиться к книгам Дейта (Date) [17], Мацяшека (Maciaszek) [51], Зильберкатца (Silberschatz) [79], Рамакришнана (Ramakrishnan) и Герке (Gehrke) [67]. Единственный момент, который нам хотелось бы подчеркнуть, это то, что надлежащее проектирование РБД проводится на надлежащем уровне нормализации.
Что мы подразумеваем под надлежащим проектом в контексте нормализации? Надлежащий проект означает, что у нас есть понимание того, каков будет характер использования РБД с точки зрения смеси операций обновления и получения информации. Если база данных отличается динамизмом, т.е. подвергается частым операциям обновления, то мы, естественно, должны стремиться создавать небольшие по размерам таблицы для лучшей локализации и осуществления этих действий по обновлению. Таблицы создаются в старшей НФ, и аномалии обновления будут устранены или уменьшены.
С другой стороны, если база данных отличается относительно статичным харак тером, т.е. над ней часто выполняются операции поиска информации, а ее содержимое обновляется время от времени, приобретает смысл денормализованный проект базы данных. Это является следствием того, что поиск в одной таблице большого размера оказывается намного более эффективным, чем аналогичный поиск в нескольких таблицах, которые требуется объединить перед началом поиска.
. Отображение в РБД
При отображении модели классов UML в проект схемы РБД необходимо учитывать ограничения на модель РБД. Речь идет о том, чтобы поступиться некоторой дек ларативной семантикой диаграмм классов в счет процедурных решений проекта логической схемы базы данных. Другими словами, может оказаться невозможным выразить некоторую встроенную декларативную семантику классов в реляционной схеме. Подобная семантика должна получить процедурное разрешение в программах базы данных, т.е. в хранимых процедурах (разд. 9.1.2.1).
Проблемы отображения в модель РБД широко изучались в контексте ER- моделирования и расширенного ER-моделирования (например, [51], [22]). В ходе этих исследований использовались те же принципы и были выявлены все основные вопросы. Так же как в случае моделей ОРБД и ОБД, отображение должно не просто соответствовать некоторым стандартам (в случае РБД это SQL92), но также учитывать особенности целевой СУРБД.
Л. Отображение классов-сущностей
Отображение классов-сущностей в реляционные таблицы должно удовлетворять 1-й НФ таблиц. Столбцы должны быть атомическими типами. Однако, хотя об этом н неудобно напоминать, как мы уже отмечали в разд. 8.2.2.1, атрибуты классов (в противоположность атрибутам отношений) в модели анализа UML уже относятся к атомическому типу. Это упрощает отображение.
с пример :M?$t8PW иШ1; зжмеАмМй
i Обратитесь к спецификациям классов для приложения Управление контактами с клиен- ‘ тами в примере 4.6, рис. 4.3 (разд. 4.2.1.2.3). Рассмотрите также обсуждение, касаю) щееся не атомических атрибутоа в примере 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 middleJnitial CHAR null
Puc. 8.21. Отображение классов-сущностей в проект РБД (Управление контактами с клиентами)
Отображение ассоциаций
Отображение ассоциаций в РБД связано с использованием ограничений ссылочное целостности между таблицами. Любую ассоциацию кратности “один к одному” или ‘"один ко многим” можно непосредственно выразить с помощью помещения внешнего ключа в одну из таблиц для установления соответствия первичному ключу другой таблицы.
В случае ассоциации “один к одному” внешний ключ может быть добавлен к любой из таблиц (решение здесь принимается на основе использования шаблонов ассоциа
ций), а также может быть желательно составить комбинацию из двух классов- сущностей в одной таблице (в зависимости от требуемого уровня нормализации).
Для рекурсивных ассоциаций “один к одному” и “один ко многим" внешний ключ н первичный ключ помещаются в одной таблице. Каждая ассоциация “многие ко многим" (независимо от того, рекурсивна она или нет) требует введения перекрестной табли цы, как показано на рис. 8.19.
totoС Пример»^
to
to
' Обратитесь к спецификациям ассоциаций для приложения Управление контактами с ! клиентами в примере 4 , рис. 4.5 (разд. 4.2.2.3).
’ Отобразите диаграмму, предстааленную на рис. 4.5, в модель РБД.
Этот пример оказывается довольно простым из-за отсутствия в спецификации ассоциаций UML-ассоциаций типа “многие ко многим”. Диаграмма РБД (для СУРБД DB2) показана на рис. 8.22. В соответствии с принципами построения РБД мы создали несколько новых столбцов в качестве первичных ключей; решили сохранить модель, приведенную на рис. 8.21, как частичное решение этого примера. Ради экономии места отказались от отображения способности столбцов принимать значение NULL и индикаторов ключей.
Ограничения ссылочной целостности между таблицами PostalAddress и CourierAddress с одной стороны, и таблицами Organization и Contact с другой стороны моделируются с помощью внешних ключей в таблице адресов. Это отчасти произвольное решение, и ограничения можно было бы моделировать в противоположном направлении (т.е. посредством введения внешних ключей в таблицы Organization и Contact).
Отображение агрегаций
Модель РБД не различает отношений ассоциации и агрегации за исключением случаев их процедурной реализации с помощью триггеров или хранимых процедур. Основные принципы отображения ассоциаций (разд. 8.4.2.2) применимы и к отображению агрегаций. Только в том случае, когда ассоциация может быть преобразована в несколько результирующих реляционных решений, семантика агрегации (как специфической формы ассоциации) оказывает влияние на решение.
-;^^-;^^В случае строгой формы агрегации (т.е. композиции) следует попытаться создать комбинацию подмножества и супермножества класса-сущности в одной таблице. Это возможно в случае агрегации “один к одному”. Для агрегаций типа “один ко многим” класс подмножества (в сильной и слабой форме агрегации) должен моделироваться в виде отдельной таблицы (с внешним ключом, связывающим ее с ее таблицей-владелицей).
-;^^
-;^^
f7 Пример 8511. Запись - ■ герситетские курсы
. Обратитесь к спецификациям агрегаций для приложения Запись на университетские курсы в примере 4.9, рис. 4.6 (разд. 4.2.3.3).
, Отобразите диаграмму, представленную на рис. 4.6, в модель РБД.
Этот пример включает в отношения агрегации — композиция от класса Student к классу AcademicRecord и слабая агрегация от класса Course к классу' CourseOffering. Обе агрегации относятся к типу “один ко многим” и требуют отдельных таблиц “подмножества”.
Event
event idINTEGER
taskjdSMALLINT
created_empjdCHAR(8)
due_empjdCHAR(8)
completed_empld CHAR(8) descriptionVARCHAR(255)
created_dtDATE
due_dtDATE
completed_dtDATE
prioritySMALLINT
Employee
emplcyeejd = created_empid
employee Id CHAR(8) family_name VARCHAR(SO) firstname VARCHAR(20) middleJnitial CHAR(1)
emplcyeejd = due_empjd
emplcyeejd = completed_empjd
Puc. 8.22. Отображение ассоциации в проект РБД (Управление контактами с клиентами)
OrganizationOrganizationorganization id INTEGER organfzation_name VARCHAR(BO)organization id INTEGER organfzation_name VARCHAR(BO)organizatioi iJd = organization idorganizatioi iJd = organization idphone faxemail is_currentphone faxemail is_currentVARCHAR(15)VARCHAR(15)VARCHAR(30)CHARACTERVARCHAR(15)VARCHAR(15)VARCHAR(30)CHARACTERPostalAddressPostalAddresscontact idSMALLINT !organization idINTEGERcontact_nameVARCHAR(50)faxVARCHAR(15)emailVARCHAR(15)contact idSMALLINT !organization idINTEGERcontact_nameVARCHAR(50)faxVARCHAR(15)emailVARCHAR(15)ContactContactorganizationjd = organization Jdorganizationjd = organization Jdpostal id organizationjd contactjd street po_box city state post_code countrypostal id organizationjd contactjd street po_box city state post_code countryINTEGER INTEGER SMALLINTVARCHAR(80)VARCHAR(20)VARCHAR(50)VARCHAR(30)VARCHAR(8)VARCHAR(50)INTEGER INTEGER SMALLINTVARCHAR(80)VARCHAR(20)VARCHAR(50)VARCHAR(30)VARCHAR(8)VARCHAR(50)contact_id = contactjdcontact_id = contactjdCourierAddressCourierAddresscourier id organizationjd contactjdcourier id organizationjd contactjdINTEGER INTEGER SMALLINTINTEGER INTEGER SMALLINTcontact id -contactcontact id -contactorganization Jd = organization Jdorganization Jd = organization Jdstreet_and_directions VARCHAR(255)street_and_directions VARCHAR(255)contactjd = contactjdcontactjd = contactjdorganization Jd = organization Jdorganization Jd = organization Jdtaskjd = taskjdtaskjd = taskjdcity state countrycity state countryVARCHAR(50)VARCHAR(30)VARCHAR(30)VARCHAR(50)VARCHAR(30)VARCHAR(30)TaskTasktask id organizationj contactjd employeeJd description created_dt valuetask id organizationj contactjd employeeJd description created_dt valuejdjdSMALLINT INTEGER SMALLINTCHAR(8) VARCHAR1255) DATE FLOATSMALLINT INTEGER SMALLINTCHAR(8) VARCHAR1255) DATE FLOATcontactjd = contact idcontactjd = contact idContact PhoneContact Phonephone VARCHAR(15) contactjd SMALLINTphone VARCHAR(15) contactjd SMALLINTemployeeJd = employ ее idemployeeJd = employ ее id
Organization
Organization
organization id INTEGER organfzation_name VARCHAR(BO)
organization id INTEGER organfzation_name VARCHAR(BO)
organizatioi iJd = organization id
organizatioi iJd = organization id
phone fax
email is_current
phone fax
email is_current
VARCHAR(15)
VARCHAR(15)
VARCHAR(30)
CHARACTER
VARCHAR(15)
VARCHAR(15)
VARCHAR(30)
CHARACTER
PostalAddress
PostalAddress
contact id
SMALLINT !
organization id
INTEGER
contact_name
VARCHAR(50)
fax
VARCHAR(15)
VARCHAR(15)
contact id
SMALLINT !
organization id
INTEGER
contact_name
VARCHAR(50)
fax
VARCHAR(15)
VARCHAR(15)
Contact
Contact
organizationjd = organization Jd
organizationjd = organization Jd
postal id organizationjd contactjd street po_box city state post_code country
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)
INTEGER INTEGER SMALLINT
VARCHAR(80)
VARCHAR(20)
VARCHAR(50)
VARCHAR(30)
VARCHAR(8)
VARCHAR(50)
contact_id = contactjd
contact_id = contactjd
CourierAddress
CourierAddress
courier id organizationjd contactjd
courier id organizationjd contactjd
INTEGER INTEGER SMALLINT
INTEGER INTEGER SMALLINT
contact id -
contact
contact id -
contact
organization Jd = organization Jd
organization Jd = organization Jd
street_and_directions VARCHAR(255)
street_and_directions VARCHAR(255)
contactjd = contactjd
contactjd = contactjd
organization Jd = organization Jd
organization Jd = organization Jd
taskjd = taskjd
taskjd = taskjd
city state country
city state country
VARCHAR(50)
VARCHAR(30)
VARCHAR(30)
VARCHAR(50)
VARCHAR(30)
VARCHAR(30)
Task
Task
task id organizationj contactjd employeeJd description created_dt value
task id organizationj contactjd employeeJd description created_dt value
jd
jd
SMALLINT INTEGER SMALLINT
CHAR(8) VARCHAR1255) DATE FLOAT
SMALLINT INTEGER SMALLINT
CHAR(8) VARCHAR1255) DATE FLOAT
contactjd = contact id
contactjd = contact id
Contact Phone
Contact Phone
phone VARCHAR(15) contactjd SMALLINT
phone VARCHAR(15) contactjd SMALLINT
employeeJd = employ ее id
employeeJd = employ ее id
Для UML-модели, представленной на рис. 4.6, мы предполагаем (что довольно е< тественно) опосредованную навигационную связь от класса AcademicRecord к кассу Course. Что касается проекта РБД, нам может потребоваться установить непосредс!
венную ссылочную целостность между таблицами AcademicRecord и Course. Кроме того, таблица AcademicRecord обладает атрибутом course_code как частью ее пер вичного ключа. Аналогичный атрибут можно ввести во внешний ключ в таблице Course. Это показано на рис. 8.23 (для СУРБД Informix).
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
student_id = studentJd
course code = course code
Puc. 8.23. Отображение ассоциации в проект РБД (Запись на университетские курсы)
Ассоциация “многие ко многим” между классами Student и Courseoffering ведег нас к другому замечательному наблюдению, хотя и не связанному с отображением <и регации. Результатом ассоциации является перекрестная таблица StdToCrsOfi < первичным ключом, который образуется в результате конкатенации первичных клю чей двух главных таблиц.
Первичный ключ для таблицы Courseoffering может выглядеть как (course_code, year, semester). Однако, подобный ключ имеет результатом гро моздкий первичный ключ для таблицы StdToCrsOff. Поэтому мы останавливаем свой выбор на первичном ключе в таблице Courseoffering, сгенерированном си< темой. Он называется ersoff и обладает типом SERIAL (в СУРБД Informix сгеперн рованные уникальные идентификаторы относятся к типу SERIAL; в других СУРБД. аналогичный тип может называться иначе— например, в Sybase on называется IDENTITY, в Microsoft SQL Server-UNIQUEIDENTIFIER и в Oracle — SE_QUENCE).
8.4.2Л. Отображение обобщений
Отображение отношений обобщения можно осуществить разными способами, од нако, принципы отображения менее сложны, чем можно было бы ожидать. Следует однако, помнить, что выражение обобщения через структуры данных РБД игнорир^ ет вопросы, которые составляют “соль” обобщения — наследование, полиморфизм, повторное использование программного кода и т.д.
Для иллюстрации стратегий отображения агрегации рассмотрим пример, показанный на рис. 8.24. Для преобразования иерархии обобщения в проект модели РБД существует четыре стратегии (хотя для некоторых из этих стратегий возможны дополнительные варианты).
Отобразить каждый класс в таблицу.
Отобразить полную иерархию класса в одну таблицу “суперкласса”.
Отобразить каждый конкретный класс в таблицу.
Отобразить каждый отдельный класс в таблицу.
Рис. 8.24. Иерархия обобщения, иллюстрирующая отображение в модель РБД
Первая стратегия проиллюстрирована на рис. 8.25. Каждая таблица имеет свой первичный ключ. Представленное решение ничего не говорит о том, “наследует" ш таблица “подкласса” некоторые из ее столбцов от таблицы “суперкласса". Например, хранится ли person_name в Person и “наследуется” ли таблицами Employes. Student и StudentEmployee? “Наследование” означает в действительности онера цию соединения, и плата за производительность соедиения может заставить пас продублировать person_name во всех таблицах иерархии.
Вторая стратегия отображения проиллюстрирована на рис. 8.26 (для СУРБД Microsoft SQL Server). Таблица Person должна содержать комбинированное множество атрибутов во все классах иерархии обобщения. Она также содержит два столбца (is_employee и is_student) для фиксирования того, является ли лицо работником, студентом или и тем и другим.
Для иллюстрации третьей стратегии отображения мы предполагаем, что класс Person является абстрактным. Все атрибуты класса Person “наследуются” таблицами, соответствующими конкретному классу. Результат аналогичен показанному на рис. 8.27.
Последняя из стратегий проиллюстрирована на рис. 8.28 (для СУРБД Informix), при этом по-прежнему предполагается, что класс Person является абстрактным. В противоположность модели, показанной на рис. 8.25, мы предполагаем, что нам всегда известен тот факт, является работник также студентом и наоборот. Отсюда заире г на значения null для столбцов типа BOOLEAN.
Рис. 8.25. Отображение каждого класса в таблицуРис. 8.25. Отображение каждого класса в таблицу
Рис. 8.25. Отображение каждого класса в таблицу
Рис. 8.25. Отображение каждого класса в таблицу
Personpersonjd uniqueidentifier <рк> not nullis_employee char(1)null
is_student . char(1)null
Puc. 8.26. Отображение иерархии классов в таблицуPuc. 8.26. Отображение иерархии классов в таблицуРис. 8.27. Отображение каждого конкретного класса в таблицуРис. 8.27. Отображение каждого конкретного класса в таблицу
Puc. 8.26. Отображение иерархии классов в таблицу
Puc. 8.26. Отображение иерархии классов в таблицу
Рис. 8.27. Отображение каждого конкретного класса в таблицу
Рис. 8.27. Отображение каждого конкретного класса в таблицу
Employeeemployee id NCHAR(8) <pk> not null is^student BOOLEAN not nullEmployeeemployee id NCHAR(8) <pk> not null is^student BOOLEAN not nullStudentstudent id NCHAR(10) <pk> not nullis_employee BOOLEANnot nullStudentstudent id NCHAR(10) <pk> not nullis_employee BOOLEANnot null
Employee
employee id NCHAR(8) <pk> not null is^student BOOLEAN not null
Employee
employee id NCHAR(8) <pk> not null is^student BOOLEAN not null
Studentstudent id NCHAR(10) <pk> not nullis_employee BOOLEANnot null
Studentstudent id NCHAR(10) <pk> not nullis_employee BOOLEANnot null
Puc. 8.28. Отображение каждого отдельного конкретного класса в таблицу
Проект РБД (для СУРБД Sybase) на рис. 8.29 содержит таблицу для каждого из грех конкретных классов (BetaTape, VHSTape и DVDDisk). Таблицы дублируют следующую информацию: video_condition, rental_period_in_days и rental charge per_period. Для каждой ленты или диска может быть зафиксировано только по одном)1 параметру rental—period—in_days и one rental—charge_per_period.
^ПрИМерЙ^.М^^ МОЙрОКЯ®
; Обратитесь к спецификациям обобщения для приложения Магазин видеопроката в
• примере 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. Как и в преды- • дущих моделях, для приложения Магазин видеопроката мы игнорируем возможность ; наличия более одного условия аренды для одного и того же видеоносителя (т е. BetaTape, VHSTape и DVDDisk).
movie_code = movie_codemovie_code = movie_codemovie code movie_title director is_in_stockmovie code movie_title director is_in_stockMo/ieTitle char(1O) varchar(IOO) varchar(30) bitMo/ieTitle char(1O) varchar(IOO) varchar(30) bit<pk> not null not null null not null<pk> not null not null null not nullmoviecode = movie_codemoviecode = movie_codeBetaTapeBetaTapebetajd movie_code video_condition rental_period_in_daysbetajd movie_code video_condition rental_period_in_daysI movie_code = movie_codeI movie_code = movie_codeidentity <pk> not null char( 10) <fk> not nullchar(1) null smallint not nullidentity <pk> not null char( 10) <fk> not nullchar(1) null smallint not nullrentai_charge_per_period numericrentai_charge_per_period numericnot nullnot nullis_taped_overbitnot nullis_taped_overbitnot nulldvd ididentity<pk> not nut'moviecodechart 10)<fk> nullvideo_conditionchart 1)nullrental_periodjn_dayssmallintnot nullrental_charge_per_period numericnot nulldifferent-languagesbitnot nulldifferentendingsbitnot nui'dvd ididentity<pk> not nut'moviecodechart 10)<fk> nullvideo_conditionchart 1)nullrental_periodjn_dayssmallintnot nullrental_charge_per_period numericnot nulldifferent-languagesbitnot nulldifferentendingsbitnot nui'DVDDiskDVDDisk
movie_code = movie_code
movie_code = movie_code
movie code movie_title director is_in_stock
movie code movie_title director is_in_stock
Mo/ieTitle char(1O) varchar(IOO) varchar(30) bit
Mo/ieTitle char(1O) varchar(IOO) varchar(30) bit
<pk> not null not null null not null
<pk> not null not null null not null
moviecode = movie_code
moviecode = movie_code
BetaTape
BetaTape
betajd movie_code video_condition rental_period_in_days
betajd movie_code video_condition rental_period_in_days
I movie_code = movie_code
I movie_code = movie_code
identity <pk> not null char( 10) <fk> not null
char(1) null smallint not null
identity <pk> not null char( 10) <fk> not null
char(1) null smallint not null
rentai_charge_per_period numeric
rentai_charge_per_period numeric
not null
not null
is_taped_overbitnot null
is_taped_overbitnot null
dvd id
identity
<pk> not nut'
moviecode
chart 10)
<fk> null
video_condition
chart 1)
null
rental_periodjn_days
smallint
not null
rental_charge_per_period numeric
not null
different-languages
bit
not null
differentendings
bit
not nui'
dvd id
identity
<pk> not nut'
moviecode
chart 10)
<fk> null
video_condition
chart 1)
null
rental_periodjn_days
smallint
not null
rental_charge_per_period numeric
not null
different-languages
bit
not null
differentendings
bit
not nui'
DVDDisk
DVDDisk
VHSTape
vhs id
identity
<pk> not null
movie_code
chart 10)
<fk> not null
video_condition
char(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, different_languages, different_endincis n is_in_stock введены с типом bit. По определению тип bit не допускает значений null (столбец типа bit принимает два значения: “0” и “1”).
Столбец is_in_stock устанавливается равным “истина" (“1”), если в запасе имеется в наличии, по меньшей мере, одна лента или диск с конкретным фильмом. Э го не слишком полезная информация, если клиент интересуется одним из трех видсопог и телей. Лучшим решением было бы введение трех столбцов типа bit или иредполо
жение о том, что эта информация никогда не хранится, т.е. является производной (вычисляемой) всякий раз, когда клиент спрашивает ленту или диск.
Статический атрибут number_currently_available не хранится ни в одной на таблиц, рассматриваемых в нашем проекте. Единственная таблица, в которой он moi бы постоянно храниться, — это таблица MovieTitle. Если принимается решение вс< же хранить его в этой таблице, то к нему применимы те же соображения, что для атрибута isin_stock.
Резюме
Эта глава отражает крайне важную роль, которую играют базы данных при разработм ПО. Неудовлетворительный проект базы данных нельзя компенсировать другими среде ! вами, включая качественную разработку приложений. Были рассмотрены все три основ ные модели баз данных — объектная, объектно-реляционная и реляционная модель.
Существует три уровня моделей баз данных — внешняя, логическая и физичсс кая В этой главе мы сконцентрировались на логической модели. Под отображением объемной в базу данных мы понимаем отображение классов UML-модели в логическую модель ба зы данных.
Отображение в логическую модель ОБД осуществляется наиболее просто. Модель ОБД поддерживает объектные типы наряду со структурированными литералами и лите ралами-коллекциями. Отношения моделируются с помощью инверсии. Для отображения обобщений UML можно использовать наследование двух видов: ISA и EXTENDS. Агрегации UML можно отображать с помощью коллекций.
Логическая модель ОРБД отличается большей сложностью по сравнению с моделью ОБД. Модель ОРБД проводит четкое различие между структурированным тинам п таблицей как единственным механизмом хранения данных. Строчный тин позво вид- задавать вложенные структуры данных — возможность, которая не так просто реализуется в UML. Поддерживаются также ссылки и коллекции ссылок. Для отображения обобщений UML можно использовать наследование двух видов: ОЕи UNDER.
Отображение в логическую модель РБД особенно неудобно. Модель РБД не поддер живает объектные типы, наследование, структурированные таны, коллекции пли ссылки. Данные хранятся в таблицах, связанных ограничениями ссылочной целостности Для программирования семантики, зафиксированной в бизнсс-правилах, вытекаю щих из моделей классов UML, можно использовать триггеры. Кроме того, на отобра жение влияет нормализация таблиц.
■] Вопросы
Дайте пояснения относительно трех уровней моделей баз данных: внешней, логической и физической модели.
Как происходила эволюция стандартов ОБД? Каково практическое значение этой эволю: щи?
В чем заключается различие между типом ОБД и классом ОБД?
Что такое литерал коллекции ОБД? В чем он может быть полезен при отображении из модели классов UML?
Что такое объектный тип коллекции ОБД? В чем он может быть полезен при отображении! из модели классов UML?
Дайте пояснения в отношении семантики и применимости ключевого слова inverse в схеме ОБД.
В чем заключается различие между наследованием по типу ISA и по типу EXTENDS в схеме ОБД >
Как главным образом используется строчный тип (row type) в ОРБД? Можно ли его исподк• зовать для определения ссылочных типов? Объясните свои соображения.
В чем заключается различие между строкой ссылок и коллекцией ссылок в ОРБД?
Поддерживают ли системы ОРБД динамическую классификацию? Поясните свой ответ.
Объясните, в чем заключается различие между столбцом, полем и атрибутом ОРБД?
В чем заключается различие между наследованием по типу OF и по типу UNDER в схеме ОРБД ?
Что такое ссылочная целостность РБД? В чем она может быть полезна при отображении ик модели классов UML?
Дайте пояснение в отношении четырех типов декларативных ограничений ссылочной це лостности.
Что такое триггер РБД? Как он связан со ссылочной целостностью?
Что такое надлежащий уровень нормализации в РБД? Поясните свой ответ.
Упражнения
У1. Телемаркетинг— обратитесь к разбору примера Телемаркетинг, как это определено в. диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему ОБД. Объясните свое решение по отображению.
У2. Телемаркетинг— обратитесь к разбору примера Телемаркетинг, как это определено в диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему ОРБД. Объясните свое решение по отображению.
УЗ. Телемаркетинг— обратитесь к разбору примера Телемаркетинг, как это определено я диаграмме видов деятельности для книги, и к решению примера У1 в главе 7.
Отобразите диаграмму классов на схему РБД. Объясните свое решение по отображении'
Глава
Проектирование программ и транзакций
Следует различать проектирование системы и проектирование программы. Проектирование программы относится к той области системного проектирования, которая связана с моделированием логики выполнения программы и определяет схему кооперативного взаимодействия объектов применительно к архитектуре клиент- сервер. Программы ИС выполняют бизнес-транзакции. Транзакция — это логический элемент базы данных, на который может оказать влияние СУБД при условии, что область действия транзакции определена в программе.
Проект программы и транзакции соединяет воедино артефакты системного проекта и знаменует собой кульминацию процесса системного проектирования. Он вносит логику приложения в проект СЫТинтерфейса и базы данных. Результатом является проектный документ, который содержит достаточно подробные указания для того, чтобы программисты могли начать “кроить программу". На самом деле некоторая начальная программа может быть сгенерирована автоматически (прямое конструирование) на основе проекта. Расширение этой начальной программы, производимое программистами, можно подвергнуть “реконструкции”, вновь вернувшись к проекту и завершая, таким образом, замкнутый цикл конструирования.
Проектирование программы
Проектирование программы— неотъемлемая часть проектирования всей системы (главы 6, 7 и 8). Архитектурное проектирование пакетов классов и компонент устанавливает исходную схему работы приложения. Детализированное проектирование GH интерфейса и баз данных определяет клиентскую и серверную составляющие этой схемы. Проектирование программы заполняет бреши в начальной схеме и превращает ее в проектный документ, который можно передать программистам для реализации.
Проектирование концентрируется одновременно на одной программе приложения. В этом смысле проектирование программы является прямым продолжением про ектирования пользовательского интерфейса, рассмотренного в главе 7. При проекчиро вании программы используется фрагмент (подсхема) проекта базы данных (глава 8) для
определения связанных с ним процедурных аспектов — хранимых процедур и определяемых программно триггеров.
Логика выполнения программы разделена между клиентским и серверным процессами. Клиентский процесс реализует большую часть динамики кооперативных взаимодействий объектов (разд.6.2), воплощенных в программе. Верный выбор соотношения между связностью и связанностью объектов (разд.9.1.1) может помочь справиться со сложностью этих взаимодействий. Серверный процесс, помимо прочего, следит за выполнением бизнес-транзакций, инициированных клиентским процессом.
Связность и увязка классов
Мимоходом, в частности в главах 5 и 6, мы определили основные принципы качественного проектирования программ, правда, по большей части в контексте качественного системного проектирования. Краеугольным камнем создания попятных, удобных в сопровождении и масштабируемых программ является введение иерархии классов. Чтобы избежать создания объектно-ориентированных программ, которые устаревают на следующий день после передачи их заказчикам, необходимо правильно пользоваться такими мощными (в том числе по своей разрушительной силе!) средствами, как наследованием, делегирование.
Надлежащее проектирование программы предполагает сбалансированность между связностью (cohesion) и увязкой (coupling) классов. Термины связность и увязка были выработаны в рамках методов структурного проектирования. Однако, эти термины имеют похожий смысл и значение и для объектно-ориентированного проектирования [60], [77].
Под связностью классов понимают степень внутреннего самоопределения класса. Связность является мерой независимости класса. Классы, обладающие сильной связностью, выполняют одно действие или их функционирование подчинено одной цели. Чем выше уровень связности, тем лучше.
Под увязкой классов понимают, насколько тесно связаны между собой классы. Увязка является мерой взаимозависимости классов. Чем ниже уровень увязки, тем лучше (однако, не следует забывать, что для кооперации классы должны быть “увязаны”!).
Связность и увязка находятся в противоречии друг с другом. Лучшая связность приводит к ухудшению увязки и наоборот. Задачей конструктора является достижение их наилучшей сбалансированности. Риль (Riel) [70] предложил несколько эвристик, посвященных этой проблеме.
Два класса должны быть либо независимы друг от друга, либо один из классов должен зависеть только от открытого интерфейса другого класса.
Атрибуты и связанные методы должны находиться в одном классе (эта эвристика часто нарушается классами, обладающими большим количеством методов открытия доступа (get, set), определенных в их открытом интерфейсе).
Класс должен охватывать одну и только одну абстракцию. Информация, не имеющая отношения к данной абстракции, когда подмножество методов работает на соответствующем подмножестве атрибутов, должна быть перенесена в другой класс.
Системная логика должна быть распределена по возможности равномерно (так, чтобы классы были равномерно загружены совместной работой).
Виды увязки классов
Чтобы взаимодействовать, классы должны быть “увязаны”. Между классом X и классом Y существует увязка, если класс X может непосредственно ссылаться на класс Y. Пейдж-Джонс (Pagejones) [60] приводит восемь типов увязки классов (которые он называет набором непосредственных межклассовых ссылок).
X наследует от Y.
X обладает атрибутом класса Y.
X обладает атрибутом шаблона с параметром класса Y.
X обладает методом со входным аргументом класса Y.
X обладает методом с выходным аргументом класса Y.
X осведомлен о глобальной переменной класса Y.
X осведомлен о методе, содержащем локальную переменную класса Y.
X — класс, дружественный классу Y.
Закон Деметра
Увязка классов необходима для взаимодействия объектов, однако, как мы заметили в разд. 5.2, она должна быть по возможности ограничена рамками уровней иерархии классов (т.е. сведена к увязке внутри уровня). Межуровневое взаимодействие должно быть сведено к минимуму и тщательно направляться. Дополнительные руководящие принципы для ограничения произвольного взаимодействия классов сформулированы в законе Деметра (Demeter) [50].
Закон Деметра определяет, на что могут быть нацелены сообщения в рамках методов класса. Он гласит, что целью сообщений может быть только один из перечисленных ниже объектов [60].
Объект, в котором определен метод (т.е. в C++ — это this, в Java— self, а в Smalltalk — super).
Объект, который является аргументом сигнатуры метода.
Объект, на который ссылается атрибут объекта (включая объект, на который ссылается один из атрибутов коллекции).
Объект, созданный методом.
Объект, на который ссылается глобальная переменная.
Для ограничения увязки, вызванной наследованием, можно ограничить третье- правило атрибутами, определенными в самом классе. Тогда атрибут, унаследованный классом, не может использоваться для обозначения целевого объекта для сообщения. Это. ограничение известно как строгое правило Деметра [60].
Методы открытия доступа и бессмысленные классы
Как упоминалось в разд. 9.1.1, атрибуты и связанные с ними методы должны находиться в одном классе [70]. Класс должен сам “решить свою судьбу". Он может ограничить доступ других классов к своему состоянию за счет запрещения методов открытия доступа в своем интерфейсе. Методы открытия доступа (accessor methods) определяют операции наблюдателя (observer (get)) или мутатора (mutator (set.)) (разд.8.3.1.2).
Методы открытия доступа “открывают” класс для внутренних манипуляций со стороны другого класса. Хотя увязка и подразумевает определенную долю использования объекта другого класса “в своих интересах”, чрезмерная распространенность методов открытия доступа может привести к неравномерному распределению “интеллектуальной" нагрузки на классы. Класс, содержащий слишком много методов, рискует оказаться бессмысленным — другие классы определяют, что для него “хорошо”.
В свете сказанного становится ясно, что существуют ситуации, когда класс должен “открыться” другим классам. Это имеет место всякий раз, когда необходимо реализовать некоторую политику (или стратегию) “отношений” между двумя или более классами [70]. За примером недалеко ходить.
Предположим, что у нас имеется два класса INTEGER и REAL и нам необходимо реализовать “политику” преобразования целых (integer) чисел в вещественные (real) и наоборот. Для этого требуется ответить на некоторые вопросы. В каком из двух классов должна быть реализована политика? Требуется ли нам специальный класс- преобразователь CONVERTER для реализации этой политики? В противном случае, по крайней мере, один из классов должен допускать использование методов открытия доступа и вследствие этого может стать “бессмысленным” по отношению к этой политике.
Здесь уместно будет привести знаменитое высказывание Пейдж-Джонса: “На объект! ю- ориентированной ферме и молоко объектно-ориентированное. Значит ли это, что объектно-ориентированная корова должна отправлять объектно-ориентированному молоку сообщение uncow_yourself (“освободиться от коровы"), или объектно-ориентированное молоко должно отправлять объектно-ориентированной корове сообщение unmilk_yourself (“избавиться от молока”)” (из выступления Пейдж-Джонса на конференции OOPSLA'87).
! В главе 8 мы разработали схему кооперации для части приложения "Запись на универ- i ситетские курсы” (примеры 6.3 и 6;4 в разд. 6.2.4.1 и 6.2.4.2). Модели кооперации г обеспечивают относительно равномерное распределение функциональной нагрузки, j однако, при этом никакие альтернативные решения не рассматривались.
; Предположим, к примеру, что нам необходимо добавить студента в список слушателей : курса. Для этого следует осуществить две проверки. Во-первых, необходимо выявить, ' изучение каких курсов является обязательным условием для прослушивания данного - курса. Во-вторых, необходимо проверить учебное личное дело студента, чтобы выяс- I нить, удовлетворяет ли студент этим обязательным условиям. Зная это, мы можем прит нять решение, можно ли студента внести в число слушателей курса.
* Предположим, что сообщение enrol () (записать [на предлагаемый курс]) должно от-
5 правляться пограничному объекту :Enrolmentwindow. Предположим также, что три : класса — CourseOffering, Course, и Student (Предлагаемый курс, Курс и Студент) I кооперируются для выполнения задачи. Наша задача заключается в том, чтобы вырабо-
. ; тать круг возможных диаграмм кооперации для решения проблемы. Рассмотрите аргу- : менты за и против различных вариантов решения.
На рис. 9.1 показан первый вариант решения. Пограничный объект: Enrolmentwindow инициирует транзакцию с помощью отправки сообщения enroll () объекту aCourse. Объект aCourse запрашивает у объекта aStudent данные относительно учебного досье и сравнивает их с обязательными условиями. Объект aCourse решает, может ли объект aStudent быть внесен в список, и дает указание объекту aCourseOffering добавить aStudent в его список студентов.
Сценарий, показанный на рис. 9.1, дает слишком много полномочий объекту aCourse. Объект aCourse становится, так сказать, “вершителем политики”. В этих условиях роль объекта aStudent лишена смысла. Решение не сбалансировано, однако, ясного выхода из ситуации не видно.
Можно переместить акценты с объекта aCourse на объект aStudent, в результате получим решение, показанное на рис. 9.2. Теперь пограничный объект : Enrolmentwindow требует от объекта aStudent выполнить основную работу. Объект aStudent вызывает метод-наблюдатель getPrereqt) объекта aCourse. Объект aStudent решает, возможна ли запись, и дает указание объекту aCourseOf fering записать студента.
Рис. 9.3 является иллюстрацией более сбалансированного решения, при котором вершителем политики является объект aCourseOf fering. Решение “беспристрастно” по отношению к объектам aCourse и aStudent, но оно делает существование этих двух объектов довольно бесполезным и бессмысленным. Объект aCourseOffering действует подобно “главной программе" (по выражению Рисля (Riel) [70], играет роль класса “Бог”).
Решение, представленное на рис. 9.3, можно улучшить за счет введения управляющего объекта, призванного обрабатывать “политическую информацию” (см. подход ВСЕ— разд.5.2.4). Управляющий объект :EnrolmentPolicy на рис. 9.4 устраняет увязку трех классов-сущностей из политики записи на курсы. Это сулит определенные преимущества, так как любые изменения политики инкапсулированы в пределах одного управляющего класса. Однако, существует риск, что класс Enrolmentpolicy может вырасти в класс “Бог”.
Рис. 9.1. Объект aCourse в качестве “вершителя политики” (Запись на университетские курсы)
Рис. 9.2. Объект aStudent в качестве “вершителя политики” (Запись на университетские курсы)
Рис. 9.3. Объект aCourseOffering в качестве “вершителя политики” (Запись на университетские курсы)
Рис. 9.4. Класс: EnrolmentPolicy в качестве “вершителя политики” (Запись на университетские курсы)
9 Л Л.4. Динамическая классификация и связность классов со смешанными экземплярами
В разд.2.1.5.2.3 мы поднимали вопрос относительно динамической классификации и заметили, что наиболее распространенные объектно-ориентированные среды программирования ее не поддерживают. Цена, которую приходится платить за отсутс г- вие подобной поддержки, зачастую выражается в проектировании классов, которые отличаются связностью смешанных экземпляров.
Пейдж-Джонс дает следующее определение подобного класса: “Класс со связностью смешанных экземпляров (mixed-instance cohesion) обладает некоторыми свойствами, которые не определены для некоторых объектов класса”. Некоторые методы класса при менимы только к подмножеству объектов этого класса, и некоторые атрибуты имею смысл только для подмножества объектов.
Например, класс Employee может определять объекты, которые являются как “обычными” работниками, так и менеджерами. Менеджерам выплачивается надбавка. Отправка сообщения о выплате надбавки payAllowance объекту Employee не имеет смысла, если этот объект Employee не принадлежит к подмножеству объектов-менедже{юв.
Для того, чтобы избавиться от связности смешанных объектов, не требуется расширять иерархию обобщения для выделения подклассов Employee, таких как OrdinaryEmployee и Manager. Однако, объект Employee может в один день принадлежать категории обычных работников OrdinaryEmployee, а в другой день перейти в категорию менеджеров Manager или наоборот. Для того, чтобы исключить связность смешанных объектов, нам требуется разрешить объектам динамически из
менять принадлежность классу во время выполнения программы — как говорится, “опять двадцать пять”, если динамическая классификация не поддерживается.
Ж-И-й*^"®-^? —^»^^^у^-^^.—.™^. „— «... -«~ ,..—... ^.^... ^,. > ,.,.
J Рассмотрите следующие варианты примера 9.1.
I ■ Посещение вечернего курса возможно только для студентов-вечерников.
| ■ Студенты стационарного обучения могут записываться только на дневные курсы.
i ■ Если студенты-вечерники желают записаться на вечерние курсы, они должны внести ! небольшую дополнительную плату.
I ■ Студенты-вечерники автоматически рассматриваются как студенты стационара, если они записываются более, чем на шесть кредитных пунктов (т.е. обычно более, чем на два предложенных курса) в данном семестре (и наоборот).
Наша задача заключается в том, чтобы предложить сильно связную структурную модель кооперации без связности смешанных экземпляров. Затем предложенную модель следует подвергнуть критической оценке и выдвинуть и обсудить альтернативное решение, s позволяющее избежать проблем с динамической классификацией.
Чтобы исключить связность смешанных экземпляров, требуется произвести специализацию класса Student в виде двух подклассов PartTimeStudent (Студент-заочник) и FullTimeStudent (Студент стационара) (рис. 9.5). Если каждый студент должен быть отнесен к категории студентов вечерней или дневной формы обучения, класс Student является абстрактным классом. Сообщение о необходимости внести дополнительную плату payExtraFee (crs_of f) никогда не отправляется t объекту класса FullTimeStudent, поскольку FullTimeStudent не содержит методов его обработки.
Рис. 9.5. Структурная схема кооперации, исключающая связность смешанных экземпляров (Запись на университетские курсы)
Следует согласиться, что у нас по-прежнему остались проблемы. Студент-вечерник может отдать предпочтение изучению дневного курса (т.е. evening_preference = 1 False 1), и при этом никакая дополнительная плата не вносится. Другими словами,
для подкласса PartTimeStudent мы по-прежнему сталкиваемся с проблемой связности смешанных экземпляров. Отправка сообщения payExtraFee (crs_off) объекгу PartTimeStudent не имеет смысла, если студент берет дневной предлагаемый курс.
На рис. 9.6 показано расширение схемы кооперации, позволяющее исключить второй аспект связности смешанных экземпляров. Для этого введен новый специализированный класс, отражающий существование студентов-вечерников, отдающих предпочтение прослушиванию дневных курсов обучения. Класс DayPrefPartTimeStudent не обладает методом payExtraFee(crs_off). Однако, что делать, если объект DayPrefPartTimeStudent вынужден “брать” предложение вечернего курса, поскольку на дневном курсе обучения нет свободных мест? Наверное, в этом случае применим какой-то другой вид дополнительной оплаты. Должны ли мы продолжать развивать нашу специализацию классов, чтобы дойти до производного класса, отражающего существование студентов-вечерников, отдающих предпочтение прослушиванию дневных курсов обучения, которым нб удается попасть на эти курсы — UnluckyDayPrefPartTimeStudent?
Рис. 9.6. Расширенная структурная схема кооперации, исключающая еще один аспект связности смешанных экземпляров (Запись на университетские курсы)
Чтобы не оказаться в нелепом положении, следует отказаться от идеи все дальше и дальше продолжать процесс исключения связности смешанных экземпляров. И больше мы не станем упоминать динамическую классификацию... В действительности, текущее значение атрибута current_sem_credit_points определяет, является лй студент студентом-вечерником или студентом дневной формы обучения.
Аналогично, студент может в любой момент изменить свое предпочтение в отношении вечернего или дневного времени посещения предложенного курса. В отсутствие поддержки динамической классификации со стороны среды программирования обеспечение возможности для объекта изменить принадлежность классу во время исполнения программы является прерогативой программиста. Это грубый метод — очень грубый в случае постоянных объектов, значения OID которых содержат идентификаторы класса.
Альтернативное решение состоит в том, чтобы ограничить глубину иерархии наследования, исключить необходимость динамической классификации и вновь возвратиться к наличию определенного уровня связности смешанных экземпляров. Например, мы можем настоять на использовании структурной кооперации, схема которой приведена на рис. 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 manipulation language —DML) или язык запросов {query language). Термин язык запросов, однако, неверен, поскольку SQL на уровне 2 служит не только цели доступа к данным, но и их модификации (включая операции вставки, обновления и удаления).
SQL уровня 2 применяет широкий круг пользователей, начиная с неискушенных случайных пользователей и заканчивая опытными DBA. На этом уровне SQL представляет собой язык интерактивного взаимодействия, а это означает, что пользователь может сформировать запрос вне какой-либо среды программирования и немедленно
выполнить его над базой данных. SQL уровня 2 является отправной точкой в изучении более развитых 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 Database Connectivity — открытый интерфейс доступа к базам данных) или JDBC (Java Database Connectivity — интерфейс организации доступа Java-приложений к базам данных). Для программирования с использованием этих интерфейсов требуется
программный драйвер 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). Программы сервера можно вызвать изнутри клиентской программы, как рассматривается далее.
Хранимые процедуры
Хранимые процедуры (storedprocedure) впервые были введены в СУБД Sybase и сейчас составляют неотъемлемую часть всех основных коммерческих СУБД. Хранимые процедуры превращают базу данных в активную программируемую систему.
Хранимая процедура представляет собой расширение SQL, допускающее такие конструкции, как переменные, циклы, ветвления и операторы присваивания. Хранимые процедуры получают имя, могут принимать входные и выходные параметры, они компилируются и хранятся в базе данных. Клиентская программа может вызвать хранимую процедуру во многом аналогично тому, как она вызывает подпрограмму.
Рис. 9.8 является иллюстрацией преимуществ вызова клиентской программой хранимой процедуры вместо отправки полного запроса серверу. Запрос, сформированный в клиентской программе, пересылается серверу по сети. Запрос может содержать синтаксические ошибки и ошибки других типов, но клиент не в состоянии исключить их — единственное место, где можно осуществить подобную верификацию, — система базы данных. После верификации СУБД проверяет, обладает ли вызывающая сторона правами, достаточными для выполнения запроса. Если это так, то запрос оптимизируется для определения наилучшего плана доступа к данным. Только после этого запрос компилируется, выполняется, и результат возвращается клиенту.
С другой стороны, если запрос (или весь набор запросов) написан в виде хранимой процедуры, он оптимизируется и компилируется с последующим сохранением па сервере баз данных. Клиентской программе нет необходимости пересылать (воз-
можно, довольно объемный) запрос по сети — вместо этого она отправляет короткий вызов, содержащий имя процедуры и список фактических параметров. Если повезет, процедура может располагаться в кэш-памяти СУБД. Если нет, она переносится в память из базы данных.
Полномочия пользователя внимательно анализируются так же, как и в случае SQL- запроса. Все фактические параметры подставляются вместо формальных параметров, и хранимая процедура выполняется. Результат возвращается вызывающей программе.
Как видно из приведенного выше сценария, хранимые процедуры дают значительно более эффективный способ доступа к базе данных из клиентской программы. Преимущества в производительности являются следствием экономии сетевого трафика и отсутствия необходимости синтаксического разбора и компиляции всякий раз при получении клиентского запроса. Что еще более важно, сопровождение хранимой процедуры локализовано в единственном месте, а вызываться она может из многих клиентских программ.
SQL-запрос(из клиентского приложения)SQL-запрос(из клиентского приложения)Вызов хранимой процедуры(из клиентского приложения)Вызов хранимой процедуры(из клиентского приложения)
SQL-запрос(из клиентского приложения)
SQL-запрос(из клиентского приложения)
Вызов хранимой процедуры(из клиентского приложения)
Вызов хранимой процедуры(из клиентского приложения)
Синтаксический разборСинтаксический разборРасположение процедуры(возможно в процедурном кзшв)Расположение процедуры(возможно в процедурном кзшв)Проверка синтаксисаи объектных ссылокПроверка синтаксисаи объектных ссылок
Синтаксический разбор
Синтаксический разбор
Расположение процедуры(возможно в процедурном кзшв)
Расположение процедуры(возможно в процедурном кзшв)
Проверка синтаксисаи объектных ссылок
Проверка синтаксисаи объектных ссылок
Проверка авторизацииПроверка авторизацииСервер баз данныхСервер баз данныхОптимизацияОптимизацияПроверка авторизацииПроверка авторизацииПодстановка параметровПодстановка параметров
Проверка авторизации
Проверка авторизации
Сервер баз данных
Сервер баз данных
Оптимизация
Оптимизация
Проверка авторизации
Проверка авторизации
Подстановка параметров
Подстановка параметров
Компиляция
Выполнение
Рис. 9.8. Сравнение вызова из клиентской программы SQL-запроса и хранимой процедуры
Триггеры
Триггеры (разд.8.4.1.4) представляют собой особый вид хранимой процедуры, которую нельзя вызвать, — они либо запускают себя, либо добавляют (insert), обновляют (update) или удаляют (delete) события из таблицы. Это значит, что каждой таблице можно сопоставить до трех триггеров. Конечно, в некоторых системах это так и есть (например, Sybase). В других системах (например, Oracle) выделяются дополнительные варианты событий, что приводит к возможности держать для каждой таблицы более трех триггеров. (Тем не менее, доступность большего количества типов триггеров не придает большей выразительной силы триггерным программам).
Триггеры можно программировать для введения некоторых бизнес-правил, которые применяются к базе данных и не могут быть нарушены ни одной клиентской про-
граммой или интерактивным DML-оператором языка SQL. Это означает, что триггеры можно использовать поверх процедурного способа обеспечения ограничений ссылочной целостности (как было рассмотрено в разд.8.4.1.4). Например, можно создать триггер, который запретит доступ к базе данных в течение определенных периодов времени или в некоторые дни.
Пользователь клиентского приложения может даже не знать о том, что триггеры “ожидают”, когда в базе данных произойдут какие-либо модификации. Если модификации не нарушают бизнес-правил, триггеры невидимы для программ. Триггер “выказывает” себя пользователю при попытке выполнить недопустимую DML- команду. Он оповещает пользователя о проблеме, отображая информационное сообщение на экране программы и отказываясь выполнить DML-операцию.
9.2. Навигация по программе
При наличии активной базы данных количество программных объектов возрастает, и кооперативное взаимодействие объектов становится более сложным. Диаграмм навигации по окнам, используемых в качестве проектного документа, больше недостаточно для того, чтобы программист мог взяться за реализацию. Их необходимо расширить (включить в) до более полных диаграмм навигации по программе.
В рамках UML не существует какой-либо стандартизованной концепции в отношении программной навигации. Тем не менее, это основополагающая абстракция моделирования, необходимая для преодоления разрыва между проектом и реализацией системы. Альтернативой может быть только плохая инженерия программных средств — архитектура и логика программы не документированы и отдаются на откуп программистам.
Стереотипы диаграммы видов деятельности для навигации по программе
Для преобразования диаграммы навигации по окнам в диаграмму навигации по программе требуется добавить серверные стереотипы к диаграммам видов деятельности UML. Необходимо ввести стереотипы как для состояний (прямоугольники со скругленными углами), так и для видов деятельности (овалы). Стереотипы должны учитывать особенности модели СУБД или даже особенности конкретной СУБД. (Это может служить основной причиной или, скорее, оправдывает отсутствие диаграмм навигации в UML).
Для проектирования диаграмм навигации по программам применительно к РСУБД можно использовать приводимый ниже перечень стереотипов. В зависимости от уровня абстракции, на котором должны быть сконструированы диаграммы навигации, перечень может сократиться или, наоборот, расшириться за счет дополнительных объектов.
■ Состояния (объекты данных)
— База данных
- Реляционная таблица
Столбец
Запись
- Реляционное представление
Столбец
Запись
Индекс
Кластер
Виды деятельности (программные объекты)
Хранимая процедура
Триггер
' Триггер типа 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 необходимо вызвать хранимую процедуру (Seleet Product). Эта же хранимая процедура задействуется, когда пользователь осуществляет прокрутку окна броузера вверх и вниз и информационное наполнение окна должно обновляться из базы данных.
Р7 Пример 9.4. Управление контактами с клиентами
Рассмотрите следующие расширения примера 7.5 (разд.7.6.2).
I ■ Хранимые процедуры используются для модификации мероприятий (операции 1п- :sert, Delete, Update, Complete).
; ■ Для отслеживания операций Insert и Update над таблицей мероприятий Event ис; пользуются триггеры.
« Наша задача заключается в проектировании диаграммы навигации по программе для
•‘ той части приложения "Управление контактами с клиентами”, которая обрабатывает мо; дификацию мероприятий.
Рис. 9.9. Диаграмма навигации по программе
В левой части диаграммы можно увидеть, что нажатие кнопки ОК или Save в диалоговом окне Update Product (<<dialog box») вызывает хранимую процедуру Update Product (<<stored procedure»). Триггер контролирует результат модификации данных о товарах (On Update Product).
Наше решение для примера (рис. 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.
Рис. 9.10. Диаграмма навигации по программе (Управление контактами с клиентами)
Проектирование транзакций
Транзакция— это логическая единица работы, которая состоит из одного или более операторов SQL, выполняемых пользователем. Транзакция также является единицей измерения непротиворечивости базы данных— состояние базы данных после завершения
транзакции непротиворечиво. Для обеспечения этой непротиворечивости используется программа менеджера транзакций, которая служит двум целям: восстановлению базы данных (database recovery) и управлению параллельным выполнением операций (concurrency control). (Последний вид управления называется также контролем совпадений или контролем противоречивых запросов к распределенной базе данных. Прим. ред.).
Согласно стандартам SQL транзакция начинается с первого исполняемого SQL- оператора (в некоторых системах требуется явный оператор начала транзакции наподобие begin transaction). Транзакция завершается операторами commit или rollback. Оператор commit записывает изменения в базу данных как постоянные. Оператор rollback стирает любые изменения, произведенные транзакцией.
Транзакция отличается свойством атомарности (atomic) — результат всех SQL- операторов, содержащихся в транзакции, либо полностью подтверждается (commit), либо отвергается (rollback). Пользователь определяет продолжительность (длину) транзакции. В зависимости от характера бизнес-требований, области приложения, стиля взаимодействия пользователя с компьютером транзакция может быть совсем короткой, состоящей из одного SQL-оператора, или содержать последовательность SQL-операторов.
Короткие транзакции
Для большинства традиционных приложений ИС требуются короткие транзакции. Короткая транзакция содержит один или более SQL-операторов, которые должны быть выполнены как можно быстрее, так, чтобы не задерживать другие транзакции.
Рассмотрим систему бронирования мест авиакомпании. Несколько туристических агентств принимают заказы от путешественников на билеты для полетов рейсами этой авиакомпании по всему миру. Существенным моментом здесь является быстрое выполнение СУБД каждой транзакции заказа, так чтобы постоянно иметь доступ к обновленной информации о наличии мест и база данных была готова к обработке следующей транзакции, ожидающей в очереди.
Л. Пессимистическое управление параллельностью
Архитектура традиционных СУБД — ОСУБД составляют здесь заметное исключение — ориентирована на короткие транзакции. Эти системы работают в соответствии с алгоритмом пессимистического управления параллельностью (pessimistic concurrency control). При обработке транзакцией каждого постоянного объекта она запрашивает блокиров ку (lock). Существует четыре типа блокировок по объектам.
Привилегированная блокировка (exclusive lock) (по записи) — другие транзакции должны ожидать, пока транзакция, удерживающая подобную блокировку, завершится и освободит блокировку.
Я. Блокировка, обновления (update lock) (по возможной записи) — другие транзакции могут читать объект, однако, транзакции, удерживающей блокировку, гарантируется возможность выполнить обновление в привилегированном режиме, как только у нее возникнет в этом потребность.
Блокировка чтения (read lock) (с разделением) — другие транзакции могут читать и, возможно, получить блокировку обновления по объекту.
Отсутствие блокировки (по lock) — другие транзакции могут обновлять объект в любой момент; подходит только для приложений, допускающих “черновое чте ниё’, — т.е. транзакция зачитывает данные, которые могут быть модифицированы или даже удалены (другой транзакцией) до завершения транзакции.
Уровни изолированности
Описанным выше четырем типам блокировки соответствуют четыре уровня изоли рованности (levels of isolation) (или уровня развязки) между параллельно выполняющимися транзакциями. Решение о том, какой уровень изолированности подходит для смеси транзакций на базе данных, является прерогативой системного проектировщика. Ниже перечислены эти уровни [41].
Возможно черновое чтение— транзакция tl модифицировала объект, но еще не получила подтверждения; транзакция t2 зачитывает объект; если tl осуществляет откат транзакции, то t2 получает объект, который в известном смысле никогда не существовал в базе данных.
Возможно неповторяемое чтение— транзакция tl зачитала объект; t2 обновляет объект; tl зачитывает тот же объект снова, но в этот момент она получает другое (по сравнению с первоначальным) значение для того же объекта.
Возможно возникновение фантомного объекта — транзакция tl зачитала набор обь- ектов; t2 вставляет новый объект в набор; tl повторяет операцию чтения и обнаруживает “объект-фантом”.
Повторяемое чтение— транзакции tl и t2 могут продолжать выполнение, но перемежающееся выполнение этих транзакций даст тот результат, что и их выполнение одна за другой (это называется выполнением, поддающимся сериалиации (serializable execution)).
Типичное интерактивное приложение ИС, основанное на использовании GUI- интерфейса, требует коротких транзакций. Однако, уровни изолированности различных транзакций в одном и том же приложении могут отличаться. Для этой цели можно использовать SQL-оператор set transaction. Сущность компромисса ясна— увеличение уровня изолированности ведет к общему снижению уровня параллелизма системы.
Одно из критически важных проектных решений, однако, не зависит от рассмотренных выше вопросов. Начало транзакции всегда должно откладываться до послед ней секунды. Неприемлемо начать транзакцию из окна клиентской программы, а затем заставлять транзакцию ждать, пока она не получит некоторой дополнительной информации от пользователя прежде, чем сможет фактически завершить работу.
Пользователь при предоставлении этой информации может выказать чрезмерную медлительность или решить отключить компьютер, хотя транзакция продолжает выполняться. Перерыв в транзакции в конце концов приведет к откату транзакции, по это успеет негативно отразиться на общей производительности системы.
Автоматическое восстановление
Закон Мерфи гласит, что если что-то может испортиться, то оно испортится. Программы могут содержать ошибки, выполняющийся процесс может зависнуть или бы ть прекращен, электропитание может дать сбой, головки диска могут поломаться и т.д. К счастью, в большинстве ситуаций СУБД имеет возможность обеспечить автоматическое восстановление системы после отказа. Только в случае физической утраты данных
на диске требуется вмешательство АБД, чтобы дать указание СУБД о восстановлении данных с помощью последней резервной копии базы данных.
В зависимости от состояния транзакции в момент отказа СУБД автоматически выполняет откат (rollback) или повтор всех завершенных операций (roll forward) транзакции сразу после устранения причин возникшей проблемы. Восстановление осуществляется автоматически, однако, АБД может контролировать время, необходимое на восстановление, за счет установления частоты контрольных точек. Контрольная точка (checkpoint) — это процедура, которая заставляет СУБД временно приостановить все транзакции и записать все изменения, произведенные транзакциями (с момента запуска предыдущей контрольной точки) над базой данных.
На рис. 9.11 показаны основные моменты, связанные с автоматическим восстановлением системы после отказа [43]. Транзакция tl подтверждена после прохождения контрольной точки, но до отказа системы. Поскольку СУБД не известно, были ли физически записаны все изменения после контрольной точки в базу данных, она повторяет все завершенные операции транзакции tl после восстановления системы.
К транзакции t2 применяется откат между контрольной точкой и отказом. Как и в случае транзакции tl, СУБД не известно, достигли ли диска изменения, связанные с откатом, — СУБД вновь выполняет откат.
подтверждение
откат
.- подтверждение
1^1
14откат
отказотказМ1
отказ
отказ
точка контроля
Рис. 9.11. Автоматическое восстановление
Остальные транзакции стартуют после контрольной точки. Для транзакции t3 вновь повторяются все завершенные операции, чтобы убедиться, что произведенные ею изменения достигли базы данных. Аналогично транзакция t4 повторяется, т.е. для нее выполняется откат.
Транзакция t5 может не требовать никаких корректирующих действий со стороны СУБД, поскольку она выполнялась во время отказа. Любые изменения, произведенные транзакцией t5 до отказа, не были записаны в базу данных. Все промежуточные изменения были записаны только в файл журнала. Пользователь поставлен в известность о том, что транзакция выполнялась во время отказа, и может перезапустить транзакцию после того, как СУБД восстановится и вновь начнет функционировать.
Программируемое восстановление
Хотя после непредвиденных отказов системы СУБД выполняет автоматическое восстановление, проектировщики и программисты должны контролировать и прогнозировать проблемы, связанные с транзакциями. СУБД обеспечивает набор возможностей по откату, которые можно задействовать программным способом, так что проблемы восстановления могут быть решены довольно изящно, при этом пользователь, возможно, даже не заметит, что в некоторый момент дела пошли не так.
Для начала заметим, что принципы разработки GUI-интерфейса, такие как контроль на стороне пользователя или терпимость к ошибкам (разд.7.3), требуют, чтобы программа позволяла пользователям совершать ошибки и была способна обеспечить восстановление системы. Откат, контролируемый программистом и применяемый в нужном месте программы, может восстановить предыдущее состояние базы данных (т.е. отменить ошибочные действия) при условии, что транзакция не подтверждена.
Если транзакция подтверждена, у программиста все еще остается возможность написать компенсирующую транзакцию (compensating transaction). Впоследствии пользователь может потребовать выполнения компенсирующей транзакции для отмены изменений в базе данных. Компенсирующие транзакции проектируются специально для того, чтобы разрешить программируемое восстановление, и должны быть отражены в моделях прецедентов.
Точка сохранения
Точка сохранения (savepoint) — это оператор программы, который делит длинную транзакцию на более короткие части. Именованная точка сохранения помещается в стратегически важных пунктах программы. Впоследствии программист имеет возможность осуществить откат выполненной работы к точке сохранения, а не к началу транзакции.
Например, программист может поместить точку сохранения прямо перед операцией update. Если операция update завершилась неуспешно, программа выполняет откат к точке сохранения и пытается повторить обновление. Вместо этого программа может предпринять любые другие действия, чтобы избежать полного аварийного прекращения транзакции.
В программах большого объема точки сохранения можно помещать перед каждой подпрограммой. Если подпрограмма отказывает, имеется возможность осуществить откат к началу подпрограммы и повторить ее выполнение с исправленными параметрами. При необходимости специально спроектированные и запрограммированные подпрограммы восстановления могут выполнить очистку, так что транзакция может возобновить выполнение.
Триггерный откат
Триггерный откат (trigger rollback) представляет собой особый вид точки сохранения. Как объяснялось в разд.9.1.2.2, триггер можно использовать для программирования бизнес-правил любой сложности. В некоторых случаях откат всей транзакции неприемлем, когда триггер отказывается модифицировать таблицу (из-за того, что транзакция пытается нарушить бизнес-правило). Транзакции может потребоваться предпринять корректирующие действия.
Вследствие приведенных выше причин СУБД может обеспечить возможности программирования триггера для отката либо всей транзакции, либо только триггера. В последнем случае программа (возможно, хранимая процедура) может проанализировать проблему и принять решение о дальнейших действиях. Даже если необходимо постепенно свернуть всю транзакцию, программа будет иметь возможность более тщательной интерпретации причины ошибки и отображения более осмысленного сообщения для пользователя.
Проектирование хранимых процедур и триггеров
Диаграмму навигации по программе (разд.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
Хранимая процедура DeleteEvent содержит операторы delete для удаления записей из таблиц Event и Task. Данные операторы delete должны запускать триггеры удаления на этих таблицах, если они существуют. Если алгоритм для этих триггеров выходит за пределы обычной проверки ссылочной целостности, проектировщик также должен предоставить для них спецификацию псевдокода (включая решение по стратегии отката — триггерный откат или откат транзакции).
Длинные транзакции
Некоторые новые классы приложений ИС поощряют кооперативные взаимодействия между пользователями. Эти приложения известны как приложения вычислений для рабочих групп (workgroup computing') или приложения совместной работы, поддерживаемой компьютером (computer-supported cooperative work - CSCW). В качестве примеров можно привести многие офисные приложения, системы творческой кооперации, системы автоматизированного проектирования, CASE-системы и т.д.
Во многих отношениях приложения для рабочих групп выдвигают требования к базам данных, которые являются ортогональными по отношению к традиционным моделям баз данных. Последние отличаются короткими транзакциями и изолируют пользователей друг от друга. Приложения для рабочих групп требуют длинных транзакций, управления версиями, управления кооперативной параллельностью и т.д.
Модель ОБД дает схему групповых вычислений, и многие продукты ОСУБД нацелены именно на эту область приложений. Пользователи, работающие с приложениями для рабочих групп, совместно используют информацию и осведомлены о работах, выполняемых ими над разделяемыми данными. Они работают в рамках собственной рабочей среды, используя персональные базы данных, включающие данные, выбранные (скопированные) из общей базы данных рабочей группы; работают с длинными транзакциями, которые могул занимать несколько сеансов работы с компьютером (пользователь может прерваться, затем возвратиться и продолжить работу с той же длинной транзакщ сей).
Отличительно^ чертой длинной транзакции является то, что для нее недопус тим автоматический откат вследствие отказов без отслеживания системой хода транзакции. Чтобы понять это требование, представьте мое отчаяние, если бы для этого учебника сейчас был произведен “откат” из-за компьютерного сбоя! Откат для длинных транзакций контролируется пользователями с помощью процедур точек (охране ния, которые постоянно сохраняют объекты в личной базе данных пользователя.
Понятие короткой транзакции не исчезло из сферы приложений для рабочих групп. Короткие транзакции необходимы для обеспечения атомарности и изолированности во время операций извлечения данных из групповой базы данных в личную базу и возврата данных (после их обработки в собственной рабочей среде) из личной базы данных в общую базу данных. После выполнения описанных коротких транзакций короткие блокировки освобождаются, а групповая база данных накладывает длинные постоянные блокировки на все извлеченные из нее объекты.
Модель длинных транзакций включает несколько взаимосвязанных целей, среди которых можно, в частности, выделить следующие [35], [52].
Обеспечение обмена информацией (даже если она является временно противоречивой) между сотрудничающими пользователями.
Обнаружение противоречий в данных и их согласованное разрешение.
Использование преимуществ поддержки множества версий объектов для обеспечения управляемого совместного использования информации без потери результатов работы в случае отказа системы.
Замкнутое конструирование
Итеративный и наращиваемый процесс (разд. 1.1.3.1) современного производства ПО требует четкой поддержки замкнутого конструирования, осуществляемого циклически между проектированием и реализацией. Замкнутое конструирование (round-trip engineering) определяется как сближение направленной вперед генерации программного кода и обратного конструирования, направленного от анализа программного кода к моделям проектирования. Замкнутое конструирование дает “...возможность работать как с графическим, так и с текстовым представлением, в то время как инструментальные средства поддерживают непротиворечивость обоих представлений” [8].
В случае приложений клиент-сервер замкнутое конструирование применяется по отдельности к клиентским прикладным программам и серверным программам баз данных. Возможно и, конечно, желательно применение различных CASE-средств для проектирования клиентской и серверной частей одного и того же проекта. Кроме того, CASE- средства, применяемые для замкнутого конструирования, должны быть тесно интегрированы с конкретной клиентской и серверной средами программирования.
Замкнутое конструирование для клиентских программ
Принципы замкнутого конструирования для клиентских приложений относительно просты — “дьявол кроется в деталях”. На рис. 9.12 представлена диаграмма видов деятельности для типичного цикла замкнутого конструирования с использованием объектного языка программирования [61], [68]. UML-модели хранятся в CASE-репозитории (как мимоходом было объяснено, CASE-репозиторий представляет собой системы баз данных, часто — объектную базу данных).
Проектная UML-модель (UML-состояние) должна быть специально разработана с ориентацией на язык программирования. Генерация кода (вид деятельности UML) использует Проектную UML-модель для генерации Исходного кода (файлов заголовков и реализации). Любые поддерживаемые пользователем определения и вспомогательные объявления, внесенные на предыдущих итерациях замкнутого конструирования, подлежат сохранению.
Исходный код позже подвергается обычным для программы изменениям и расширениям. Модифицированный код подвергается процедуре реинжиниринга, результат которой представлен в виде UML-модели реализации. Вид деятельности, соответствующий процедуре реинжиниринга, на рис. 9.12 обозначен как Генерация UML.' Для выявления изменений в проекте с помощью сравнения текущей UML-модели реализации и последней Проектной UML-модели используется некоторый вид инструментального средства под названием Различение моделей. Все принятые изменения распространяются на Проектную UML-модель, после чего возможно начинать следующую итерацию замкнутого конструирования.
Как мы заметили выше, "дьявол кроется в деталях”. На практике многие связующие звенья между “пониманием” языка программирования CASE-средствами и реалиями конкретного компилятора для этого языка зачастую оказываются утерянными. CASE-
средство может сообщить о наличии ошибок в чисто скомпилированном коде, поскольку оно не распознает нюансов, характерных для конкретной версии компилятора.
Рис. 9.12. Замкнутое конструирование в случае клиентской программы
CASE-средство может оказаться не в состоянии разрешить некоторые ссылки на объявления в зависимых от компилятора или библиотеки исходных файлах. Например, ссылки могут быть неразрешимы, если исходный файл ссылается на символы, определенные в другом файле и явно не включенные в данный файл. Хотя для подобных проблем и могут существовать обходные пути, они неизменно приводят к неидеальным решениям, требующим ручной корректировки.
Указанные трудности не означают, что от проведения замкнутого конструирования для клиентских программ следует вообще отказаться. Недоработки можно откорректировать вручную, и уже откорректированные UML-модели дают разработчикам надлежащую документацию для текущей версии программы. Альтернативой является полная потеря контроля над реализацией приложения.
Замкнутое конструирование для баз данных
В процессе замкнутого конструирования для баз данных [53] со стороны проекта участвует физическая моделъ данных (ФМД) (physical data model— PDM), a co стороны реализации — база данных (БД). Модель используется вместо UML-модели, поскольку' UML не поддерживает физического проектирования баз данных (разд.8.4). Физическая модель данных должна быть ориентирована на конкретную СУБД.
На рис. 9.13 представлена диаграмма видов деятельности для замкнутого конструирования реляционной базы данных. После построения ФМД для базы данных (состояние Начальная ФМД) ее можно поместить в архив (вид деятельности Архив). Сравнение архивной и текущей ФМД позволяет зафиксировать последние изменения в модели.
Прямое конструирование модели Начальная БД на основе модели Начальная ФМД осуществляется с помощью вида деятельности Создание БД. В результате этой деятельности генерируется схема БД, включая триггеры. Начальная БД заполняется данными с помощью рекурсивного вида деятельности Загрузка. Вид деятельности Модификация БД вводит изменения в схему и вызывает переход базы данных в состояние Текущая БД.
Рис. 9.13. Замкнутое конструирование в случае базы данных
Рис. 9.14. Экран сеанса реинжиниринга по преобразованию БД Sybase в ФМД PowerDesigner
На этом этапе существуют две возможности: изменения в Текущей ФМД могут быть синхронизированы с Текущей БД (вид деятельности Синхронизировать ФМД с БД) или
наоборот—изменения в Текущей БД могут быть синхронизированы с Текущей ФМД (вид деятельности Синхронизировать БД с ФМД). В результате этих видов деятельности может потребоваться перенести в архив Текущую PDM, а Текущую БД перегрузить.
На рис. 9.14 показан один из экранов сеанса реинжиниринга (вид деятельности Синхронизировать с БД) Текущей БД (Sybase), в результате которого мы получаем Текущую ФМД (PowerDesigner).
В процессе замкнутого конструирования баз данных необходимо учитывать приведенные ниже факторы [53].
Архивирование и поддержка версий ФМД может осуществляться с использованием CASE-средств, однако, типичная РСУБД или ОРСУБД не обладает встроенными возможностями поддержки версий БД (отличных от простого создания новой БД).
После генерации начальной схемы БД база загружается данными, и начинается программирование серверной программы. Программистам необходима возможность модифицировать (или требовать модификации) схемы БД по мере того, как модификации постепенно синхронизируются с текущей моделью ФМД. Вид деятельности Синхронизировать ФМД с БД должен полностью выполняться во время синхронизации, после чего должно осуществляться архивирование PDM-модели.
Любые последующие изменения в архивной PDM-модели, которые требуют синхронизации с БД, должны быть внесены методом прямого конструирования в новый экземпляр БД (при отсутствии версий БД).
Реинжиниринг реляционных баз данных в объектно-реляционные
В главе 8 упоминалось о том, что следующее поколение технологий баз данных должно основываться на модели ОРБД. Поэтому следует ожидать возрастания потребности в переносе существующих (унаследованных) реляионных баз данных на объектно-ориентированные платформы. Реинжиниринг (reengineering) — это процесс, направленный на изучение и изменение унаследованной системы для реконструкции ее проекта и ее повторной реализации в новом виде.
Реинжиниринг и замкнутое конструирование разделяют технологии прямой и об ратной разработки. Разница заключается в том, что замкнутое конструирование связано с эволюционным развитием новой системы. Реинжиниринг предшествует замкнутому конструированию и связан с получением начальной ФМД в результате изучения унаследованного программного кода.
Сегодня большинство проектов по реинжинирингу направлены на то, чтобы переориентировать устаревшие системы на основе языка COBOL на технологию реляционных баз данных. В будущем роль унаследованных систем перейдет к реляционным базам данных, которые на основе реинжиниринга будут превращаться в решения на основе ОРБД или ОБД. Однако, рынок чистых ОБД вряд ли будет расти так же быстро, как рынок ОРБД — отчасти из-за естественной инерции в переходе к совершенно новым технологиям, а отчасти из-за того, что ОСУБД обращены прежде всего к рыночной нише систем мультимедиа и кооперативной обработки.
На рис. 9.15 представлена диаграмма, отображающая последовательность видов деятельности в процессе реинжиниринга, целью которого является переход от сис-
темы РБД к системе ОРБД. Здесь также показан последовательный процесс замкнутого конструирования ОРБД.
Модификация модели для ОРБД
Рис. 9.15. Реинжиниринг реляционной базы данных в объектно-реляционную
Выполняется анализ Реализации существующей РБД (вид деятельности Анализ РБД) для определения структур базы данных, бизнес-правил и логики прикладных программ. Анализ приводит к построению проектной UML-модели, которая отражает текущее состояние существующей (унаследованной) реализации РБД. UML-модель затем модифицируется для Реализации ОРБД.
Теперь можно сгенерировать схему ОРБД, триггеры и методы (процедуры) и загрузить ОРБД данными. Для ОРБД создаются и тестируются прикладные программы. Это неизбежно приводит к изменениям в ОРБД, которые требуется отразить в проектной UML-модели. После этого можно сказать, что изменения подверглись реинжинирингу и первая итерация замкнутого конструирования завершена.
Процесс конструирования и замкнутого конструирования объектно-реляционных баз данных сталкивается с двумя основными проблемами. Первая касается аспектов замкнутого конструирования, а вторая связана с выразительными возможностями моделей UML.
Переход от проектах моделей UML к реализациям ОРБД в процессе замкнутого конструирования аналогичен замкнутому проектированию для реляционной базы данных, как было рассмотрено в предыдущем разделе. Несмотря на аналогию, основополагающие технические вопросы для ОРБД значительно более трудны. Это связано с тем, что модель ОРБД более сложна и семантически более богата, чем модель РБД (глава 8). Начнем с того, что CASE-средства должны быть ориентированы на новый стандарт SQL 1999 и “понимали” различные варианты SQL 1999 применительно к коммерческим ОРСУБД.
Так же, как в случае модели РБД, рассчитывать на поддержку возможностей ФМД для систем ОРБД особенно не приходится. UML — это преимущественно язык анализа систем. Существуют профили UML, предназначенные для моделирования систем [56], однако, они не обеспечивают возможностей детализированного конструирования, связанных с пониманием всех нюансов ОРСУБД, включая нюансы, относящиеся к различным версиям одной и той же ОРСУБД.
Например, СУБД Oracle 8 использует объектные представления для облегчения перехода от реляционной к объектно-реляционной базе данных. Подобно другим объектам ОРБД, объектное представление может быть обозначено как класс- стереотип и ему, возможно, может быть присвоена собственная графическая пиктограмма. Безусловно стереотипному классу должна быть придана собственная точная семантика, так что CASE-средство может понять любые ограничения и возможности, связанные со стереотипным классом (например, какие типы отношений и других связей допустимы между стереотипным классом и любым другим класом модели). Низкоуровневые CASE-средства от компании Oracle (в данном случае) имеют значительно больше шансов помочь правильно решить подобные вопросы, чем исходный язык UML наряду со стереотипами.
Резюме
В этой главе мы остановились на некоторых более внутренних концепциях проектирования программ и транзакций и описали проектную деятельность, которая лежит на линии перехода между проектированием и реализацией. Были рассмотрены диаграммы навигации по программе. Мы также объяснили подход к замкнутому конструированию клиентских программ и серверных программ баз данных.
Программа, спроектированная надлежащим образом, отличается высоким уровнем связности классов при низком уровне увязки классов. Этого требования в отношении связности и увязки можно достичь, если проект подчиняется закону Деметра, который определяет допустимые целевые объекты для сообщений в рамках методов классов. Чрезмерное использование методов открытия доступа может привести к появлению “бессмысленных классов". Хотя связность смешанных экземпляров и представляется нежелательным явлением, иногда она все же допустима, поскольку среды программирования не поддерживают динамическую классификацию.
При разработке кооперации клиент-сервер необходимо принимать во внимание существование пяти уровней SQL-интерфейсов. Особый интерес представляет SQL уровня 5, поскольку позволяет пользователю непосредственно программировать базу данных. Хранимые процедуры и триггеры оказывают существенное влияние на серверный аспект проектирования программы. Диаграммы навигации ио программе расширяют диаграммы навигации по окнам, позволяя учитывать наличие базы данных.
Транзакция — это единица работы базы данных, которая начинается, когда база данных находится в непротиворечивом состоянии, и по завершении которой база данных гарантированно окажется в непротиворечивом состоянии. Транзакции обеспечивают возможности по реализации параллелизма и восстанавливаемости баз данных. Традиционные приложения баз данных требуют коротких транзакций. Некоторые новые приложения баз данных работают с длинными транзакциями.
Замкнутое конструирование— это процесс, при котором проектные модели и программы синхронизированы, однако могут развиваться самостоятельно. Замкнутое конструирование определяется как сочетание направленной вперед генерации программного кода и обратного конструирования, направленного от анализа программного кода к моделям проектирования. Обычно замкнутое конструирование применяется по отдельности к клиентским программам и программам баз данных.
[М] Вопросы
Какое влияние на проектирование оказывают принципы, связанные со связностью и увязкой?
Какие объекты могут выступать в качестве целевых объектов для сообщений согласно закону Деметра?
Что такое ‘бессмысленный класс”?
Объясните связь между динамической классификацией и связностью смешанных экземпляров.
Кратко опишите пять уровней SQL-интерфейсов.
В чем преимущество вызова из клиентской программы хранимой процедуры в сравнении с SQL-запросом, пересылаемым базе данных? Существуют ли ситуации, при которых мы вынуждены использовать SQL-запрос вместо вызова удаленной процедуры?
Перечислите основные серверные объекты, моделируемые как состояния и виды деятельности диаграмм навигации по программе.
Кратко опишите виды блокировок при пессимистическом управлении параллельностью.
Кратко опишите уровни изолированности транзакций.
Может ли проектировщик или АБД управлять продолжительностью восстановления базы данных? Объясните ваш ответ.
Что такое компенсирующая транзакция? Как ее можно использовать при проектировании программы?
Что такое точка сохранения? Как ее можно использовать при проектировании программы?
В чем заключается функция дифференцирования модели при замкнутом конструировании клиентской программы?
У традиционных баз данных отсутствуют встроенные возможности поддержки версий базы данных. Как это влияет на замкнутое конструирование программ для подобных баз данных?
В| Упражнения
У1. Телемаркетинг—обратитесь к разбору примера “Телемаркетинг", как это определено в диаграмме видов деятельности для книги, и к решению примера У4 в главе 7.
Расширьте диаграмму навигации по окнам для приложения “Телемаркетинг” до диаграммы навигации по программе. Если решение оказывается слишком сложным, разделите диаграмму на несколько меньших диаграмм. Объясните, каким образом предложенное вами решение удовлетворяет требо ания к приложению.
У2. Управление контактами с клиентами — обратитесь к решениям примера “Управление контактами с клиентами", как это определено в диаграмме видов деятельности для книги. В частности, рассмотрите диаграмму навигации по окнам в примере 7.5 (разд.7.6.2).
Идентифицируйте хранимые процедуры, триггеры и другие объекты базы данных (которые до сих пор не идентифицированы), необходимые для системы управления контактами с клиентами.
Тестирование и управление изменениями
Тестирование и управление изменениями — это не отдельные этапы ЖЦ разработки ПО — они охватывают весь жизненный цикл. Тестирование — это совсем не отладка программ. Артефакты разработки каждого этапа ЖЦ должны быть протестированы. Аналогично, понятие управления изменениями применимо не только в отношении усовершенствований, требуемых заказчиками, или ошибок, обнаруженных в ходе тестирования. Управление изменениями представляет собой фундаментальный аспект управления проектом в целом —■ запросы на изменения должны быть документированы, а влияние каждого изменения на артефакты разработки должно отслеживаться и перепроверяться после их реализации. В основе тестирования и управления изменениями лежит понятие прослеживаемости. Прослеживаемость обеспечивает фиксацию, связь и отслеживание всех важных артефактов разработки, включая требования. Конечная цель прослеживаемости — дать возможность выработать полную документацию на систему, которая является заведомо корректной и непротиворечивой применительно к различным документам и моделям, начиная с требований и заканчивая технической и пользовательской документацией. Элементами прослеживаемости могут быть текстовые и графические модели. Прослеживаемость устанавливает явные связи между элементами прослеживаемости. Связи могут быть прямыми и косвенными. Они позволяют проводить анализ последствий при изменении любого элемента, находящегося на пути прослеживаемости. Ранее в этой книге мы провели различие между системными услугами и системными ограничениями.
' ■ Прослеживаемость, тестирование и управление изменениями часто ассоциируются с системными услугами, которые заявляют о себе в требованиях, выражаемых прецедентами. Однако, не следует забывать о необходимости отслеживания того, как выдерживаются системные ограничения, и, соответственно, тестирования и управления их изменениями.
Тестирование системных сервисов
Скэч (Schach) [77] проводит различие между неформальным и методическим тестированием системных сервисов. Каждый разработчик выполняет неформальное тестирование при моделировании или реализации системных сервисов. По своему харак-
теру неформальное тестирование несовершенно. Тот, кто разрабатывает сервис, менее всего заинтересован в том, чтобы в программе, реализующей этот сервис, были обнаружены ошибки.
Значение неформального тестирования незначительно, и оно должно быть дополнено методическим тестированием. Существует два основных вида методического тестирования [77].
Тестирование без выполнения программы (формальные пересмотры) (formal reviews)
Сквозной контроль
Инспекция
- 2. Тестирование, основанное на выполнении программы
Тестирование по спецификации
Тестирование по программному коду
Сквозной контроль
Сквозной контроль (walkthrough) представляет собой один из видов формального пересмотра артефактов методом "мозгового штурма”, который может проводиться на любом этапе разработки. Это дружественная встреча разработчиков, тщательно спланированная, с ясно определенными целями, повесткой дня, продолжительностью и составом участников. Многие бригады ИТ-разработчиков проводят сквозной контроль еженедельно. За несколько дней до совещания по сквозному контролю участникам раздаются материалы (описания моделей, документы, программы и т.д.), которые подлежат пересмотру на совещании. Материалы участникам собирает и раздает модератор сквозного контроля. Участники изучают материалы и передают модератору свои замечания еще до начала совещания. Само совещание относительно непродолжительно (самое большее два-три часа). Во время совещания модератор представляет замечания и открывает обсуждение по каждому вопросу. Цель освещения состоит в том, чтобы уточнить проблему, а не выводить разработчиков “на чистую воду”! Разработчик, который стоит за проблемой, в данном случае не важен и может вообще оставаться неизвестным (хотя обычно это не так). Общая идея состоит в том, чтобы подтвердить существование проблемы. При этом не следует предпринимать попыток решить проблему. О полезности и эффективности сквозного контроля свидетельствуют многие факты. Он придает процессу разработки четкость и профессионализм, вносит существенный вклад в достижение высокой продуктивности и способствует выполнению работы в срок, имеет очень важное значение с точки зрения информированности участников проекта и, в конечном итоге, позволяет повысить качество разрабатываемого ПО.
Инспекция
Подобно сквозному контролю инспекция (inspection) представляет собой совещание, проводимое в дружелюбном духе, но под пристальным наблюдением со стороны руководства проекта. Ее целью также является выявление дефектов, подтверждение того, что они действительно являются дефектами, их фиксация и назначение сроков их устранения и лиц, ответственных за это.
В отличие от сквозного контроля инспекции проводятся не так часто, могут быть посвящены только отдельным, имеющим критическое значение, вопросам и носят более формальный и более строгий характер. Инспекция организована в виде нескольких этапов. Она начинается с этапа планирования, на котором определяются участники инспекции и целевая область инспектирования.
До начала инспекционного заседания необходимо провести короткое информационное совещание. Во время информационного совещания разработчик, продукт которого подлежит инспектированию, вводит участников в курс дела. Инспекционные материалы раздаются участникам во время или перед информационным совещанием.
Информационное совещание обычно проводится за неделю до инспекционного совещания. Это дает инспекционной бригаде время изучить материалы и подготовиться к совещанию. Во время совещания дефекты идентифицируются, фиксируются и нумеруются. Сразу после совещания модератор готовит журнал дефектов — в идеале он ведется с использованием средств управления изменениями, связанными с проектом.
Обычно от разработчика требуется быстро решить проблемы, связанные с дефектами, и зафиксировать принятое решение с помощью средств управления изменениями. Модератор должен проверить отчет об устранении дефекта и решить, требуется ли повторное инспектирование. В случае если он удовлетворен решением проблемы, модератор, проконсультировавшись с руководителем проекта, направляет разрабатываемый модуль группе обеспечения качества ПО (Software Quality Assurance— SQA) организации (если такая группа существует).
Группа SQA должна состоять из лучших специалистов, имеющихся в организации. Группа никак не должна быть связана с проектом за исключением своей роли по обеспечению качества. Группа (а не истинные разработчики!) несет ответственность за конечное качество продукта.
Тестирование по отношению к спецификации
Тестирование по отношению к спецификации представляет собой одну из разновидностей тестов, основанных на выполнении (прогоне) программы. Оно применимо к исполняемым программным продуктам, а не документам или моделям. Этот вид тестирования также известен под другими названиями, такими как тестирование по методу •черного ящика, функциональное тестирование, тестирование по входу-выходу и т.д.
Принцип тестирования по отношению к спецификации заключается в том, что разработчик рассматривает тестируемый модуль как “черный ящик”, на вход которого подается некоторая информация и который вырабатывает некоторый выход. При этом не делается никаких попыток понять программную логику или вычислительные алгоритмы.
При тестировании по отношению к спецификации необходимо выработать тестовые требования, исходя из требований-прецедентов, а затем идентифицировать и зафиксировать их в отдельных документах, представляющих тест-план и тестовые прецеденты. Эти документы предоставляют в распоряжение специалиста по тестированию сценарий тестирования (test scenario). Сценарий можно записать с помощью специальных средств автоматизации тестирования, а затем использовать его многократно. Подобные средства получили название средств “записи-воспроизведения". Такие средства особенно полезны в случае регрессионного тестирования (разд. 1.3.10).
Тестирование по отношению к спецификации подходит для выявления дефектов, которые трудно “поймать” другим способом. В частности, тестирование по спецификации позволяет обнаружить пропущенные функции— что-то, что (надо надеяться) было
документировано как требование-прецедент (а следовательно, и тестовое требование), однако, так и не было запрограммировано. Этот вид тестирования позволяет также выявить пропущенные функции, которые не были оформлены документально в виде прецедентов, но явно пропущены в реализации системы.
Тестирование по отношению к программному коду
Тестирование по отношению к программному коду представляет собой второй вид тестирования, основанный на выполнении программы. Он также известен под названиями тестирования по методу прозрачного ящика, тестирование по методу стеклянного ящика, тестирование путем покрытия логики программы и тестирование путем покрытия путей программы. Тестирование по отношению к программному коду начинается с тщательного анализа алгоритмов программы. С целью испытания программы выводятся прецеденты — это дает определенные гарантии проверки всех возможных выполняемых ветвей программы. Для выполнения программы специальным образом продумывается организация данных.
Для поддержки тестирования по отношению к программному коду также существуют средства “записи-воспроизведения” сценариев тестирования, используемые для регрессионного тестирования. Однако, характер тестирования по коду требует привлечения к использованию этих средств программистов. Многие сценарии “проигрывания” тестов должны быть написаны программистами, а не сгенерированы средствами автоматизации. Даже если сценарии и генерируются автоматически, может потребоваться существенно модифицировать их с помощью программистов.
Подобно всем прочим видам тестирования, основанным на выполнении программы, тестирование по отношению к программному коду не может носить исчерпывающего характера из-за комбинаторного взрывоподобного роста количества возможных тестовых прецедентов даже при умеренном росте сложности программы. Даже если существует возможность тестирования каждой выполняемой ветви программы, нет никаких гарантий, что все дефекты будут обнаружены. Старая мудрость тестирования по-прежнему остается в силе — тестирование способно устранить некоторые ошибки, но не в состоянии доказать правильность программы!
Тестирование системных ограничений
Тестирование системных ограничений преимущественно факта реализации ограничений в соответствии с перечнем требований и тестовой документацией основано на выполнении программы. Его цель состоит в установлении ограничений. Тестирование системных ограничений включает ряд вопросов, некоторые из них приводятся ниже.
Тестирование пользовательского интерфейса.
Тестирование баз данных.
Тестирование контроля доступа.
Тестирование производительности.
Тестирование в утяжеленном режиме.
Тестирование при отказе.
Конфигурационное тестирование.
Инсталляционное тестирование.
Первые два типа тестирования системных ограничений — тестирование пользовательской) интерфейса и баз данных— очень тесно связаны с тестированием системных услуг. Они обычно проводятся в параллель с тестированием системных ограничений. Поэтому включаются в тестовые документы (разд. 10.3), вырабатываемые для тестирования системных услуг.
Тестирование пользовательского интерфейса
Тестирование GUI-интерфейса пронизывает весь процесс разработки ПО. Оно начинается на ранней стадии этапа выработки требований, сопровождая такие виды деятельности, как работа с архивными документами, включение эскизов окон в документы описания прецедентов и разработка прототипов GUI-интерфейса. Эти ранние тесты GUI-интерфейса концентрируются на удовлетворении функциональных требований и удобстве использования приложения.
Позже, после реализации системы требуется послереализа-ционное тестирование GUI- интерфейса. Вначале тестирование проводится разработчиками, затем специалистами по тестированию и— перед выпуском ПО— заказчиками ^пилотное тестирование) . Ниже приведен примерный перечень вопросов тестового документа, разработанного для послереализационного тестирования [9].
■ Соответствует ли название окна его функции?
■ Является ли окно модальным или немодальным? Каким оно должно быть?
■ Введено ли визуальное различие между обязательными и необязательными полями?
■ Можно ли изменить размеры окна, переместить его и восстановить? Необходимо ли это?
■ Пропущены ли какие-либо поля?
■ Есть ли орфографические ошибки в названиях, метках, именах приглашений для ввода и т.д.?
■ Нет ли противоречий в использовании командных кнопок (OK, Cancel, Save, Clear и т.д.) в каких-либо диалоговых окнах?
■ Возможно ли всегда отменить текущую операцию (включая операцию удаления)?
■ Все ли статические поля защищены от изменения пользователем? Может ли приложение изменить статический текст, корректно ли это делается?
■ Применяются ли для статических текстовых полей согласованные шрифты и размеры?
■ _ Соответствуют ли размеры полей редактирования диапазону принимаемых ими значений?
■ Все ли поля редактирования инициализированы верными значениями при открытии окна?
■ Проверяются ли значения, вводимые в поля редактирования, клиентской программой?
■ Правильно ли заполняются из базы данных значения выпадающих списков?
■ Используются ли маски редактирования в полях ввода в соответствии с определением?
■ Доходчивы ли сообщения об ошибках и легко ли работать с ними?
Тестирование баз данных
Аналогично тестированию GUI-интерфейса тестирование баз данных связано со многими другими видами тестирования. Так, тестирование по методу черного ящика (тестирование по отношению к спецификации) зачастую основано на использовании входной и выходной информации для базы данных. Однако, это не исключает необходимости в отдельной методике тестирования баз данных.
Послереализационное тестирование баз данных включает всестороннее тестирование по методу прозрачного ящика (в соответствии с программным кодом). Наиболее существенной частью тестирования баз данных является тестирование транзакции Тестирование некоторых других аспектов баз данных — производительности, параллелизма, проверка полномочий пользователей — иногда выделяют в отдельные группы тестов.
Аналогично тестированию GUI-интерфейса некоторые тесты баз данных требуется проводить повторно для всех различных функций приложения. Вопросы, требующие рассмотрения при тестировании баз данных, необходимо оформить в виде общего документа. Этот общий документ следует затем присовокупить к описанию всех функциональных тестов (тестов системных услуг). Ниже приводится примерный перечень вопросов, на которые следует обратить внимание при тестировании баз данных [9].
■ Проверить, выполняется ли транзакция надлежащим образом при правильных входных данных. Корректна ли обратная связь системы с GUI-интерфейсом? Корректно ли содержимое базы данных после транзакции?
■ Проверить, выполняется ли транзакция надлежащим образом при неправильных входных данных. Корректна ли обратная связь системы с GUI-интерфейсом? Корректно ли содержимое базы данных после транзакции?
■ Прервать транзакцию до ее завершения. Корректна ли обратная связь системы с GUI-интерфейсом? Корректно ли содержимое базы данных после транзакции?
■ Запустить одну и ту же транзакцию параллельно во многих процессах. Сознательно заставить одну из транзакций заблокировать ресурс, необходимый другим транзакциям. Получают ли пользователи понятное объяснение ситуации? Корректно ли содержимое базы данных после транзакций?
■ Извлечь каждый из клиентских SQL-операторог из клиентской программы и выполнить их над базой данных в интерактивном режиме. Совпадают ли полученные результаты с ожидаемыми, а также соответствуют ли они результатам при выполнении SQL-операторов в составе программы?
■ Выполнить интерактивное тестирование каждого более сложного SQL-запроса (выдаваемого из клиентской программы или хранимой процедуры) по методу прозрачного ящика, включая внешние соединения, объединения, подзапросы, значения типа null, функции агрегации и т.д.
Тестирование авторизации
Тестирование авторизации можно рассматривать как естественное расширение тестирования первых двух типов системных ограничений. Как клиентские (пользовательский интерфейс), так и серверные (базы данных) объекты должны быть защищены от несанкционированного использования. Тестирование авторизации должно обеспечить проверку того, что механизмы безопасности, встроенные в клиентскую и серверную части системы, в действительности защищают систему от несанкционированного проникновения.
Хотя нарушение безопасности безусловно сказывается на базах данных, защита начинается с клиентской части системы. Пользовательский интерфейс программы должен быть в состоянии динамически настраивать собственную конфигурацию в соответствии с уровнем полномочий текущего пользователя (который подтверждается (аутентифицируется) идентификатором и паролем пользователя). Пункты меню, командные кнопки и даже целые окна могут стать недоступны пользователям, если у них нет соответствующих прав.
Не все “проходы” в защите системы могут быть обращены в сторону пользователей. Поддержка авторизации является существенной компонентой любой СУБД. Пользователю могут быть предоставлены выборочные права доступа к серверным объектам, при этом права (полномочия) пользователя по отношению к серверу распадаются на две категории.
Доступ к отдельным серверным объектам (таблицам, представлениям, столбцам, хранимым процедурам и т.д.).
Выполнение SQL-операторов (select, update, insert, delete и т.д.).
Полномочия для пользователей можно назначать непосредственно на уровне пользователей или на групповом уровне. Группы позволяют администратору системы защиты назначать права доступа группе пользователей с помощью однократного ввода соответствующих параметров. Пользователь может как не принадлежать ни к одной группе, так и принадлежать к нескольким группам.
Для обеспечения большей гибкости при работе с авторизацией большинство СУБД вводят дополнительный уровень авторизации — ролевой уровень. Роли позволяют администратору системы защиты назначать права доступа всем пользователям, которые играют определенную роль в организации. Роли могут носить вложенный характер, т.е. права, предоставленные разным ролевым именам, могут перекрываться.
Для больших приложений ИС проектирование авторизации требует скрупулезной работы. Зачастую наряду с прикладной базой данных создается база данных авторизации для хранения и манипулирования клиентскими и серверными полномочиями. После входа пользователя в систему прикладная программа обращается к базе данных, чтобы установить уровень полномочий пользователя и настроить свою конфигурацию применительно к этому пользователю.
Любые изменения в правах доступа к базам данных осуществляются через базу данных авторизации — т.е. никто, включая администратора системы защиты, не имеет возможности непосредственно изменить права доступа к базе данных без предварительного обновления базы данных авторизации. На рис. 10.1 приведен пример проекта базы данных авторизации.
co_type = {menu item, action button, window,...}
Puc. 10.1. Проект базы данных авторизации
Тестирование других ограничений
Помимо описанных выше тестирование системных ограничений включает следующие виды тестирования.
Тестирование производительности.
Тестирование в утяжеленном режиме.
Тестирование при отказе.
Конфигурационное тестирование.
Инсталляционное тестирование.
Тестирование производительности направлено на измерение ограничений производительности, требуемых заказчиком. Ограничения связаны со скоростью транзакций и пропускной способностью. Тестирование проводится при различной рабочей загрузке систем, включая предполагаемую пиковую загрузку. Тестирование производительности является важной составляющей настройки системы.
Тестирование в утяжеленном режиме проектируется таким образом, чтобы вывести из стоя систему при предъявлении к ней завышенных требований — из-за недостатка ресурсов, необычной конкуренции за ресурсы, непредусмотренной частоты, величины или объема требований к ресурсам. Тестирование в утяжеленном режиме часто сочетается с тестированием производительности и может потребовать соответствующей аппаратной и программной оснастки.
Тестирование при отказе направлено на изучение реакции системы на различные аппаратные, сетевые или программные сбои. Этот вид тестирования тесно связан с процедурами восстановления, поддерживаемыми СУБД.
Конфигурационное тестирование связано с проверкой функционирования системы при различной аппаратной и программной конфигурации. Для большинства производственных сред предполагается, что система способна функционировать на различных клиентских рабочих станциях, которые подключаются к базе данных с использованием различных сетевых протоколов. На клиентских рабочих станциях может быть инсталлировано различное ПО (например, драйверы), которое может конфликтовать с предусмотренными установками.
Инсталляционное тестирование является расширением конфигурационного тестирования. Оно связано с проверкой надлежащего функционирования системы на каждой из платформ, на которых она инсталлируется. Это означает фактическое повторение тестирования системных услуг.
Документация по тестированию
■ и управлению изменениями
Документация по тестированию и управлению изменениями составляет неотъемлемую часть остальной системной документации, включая документацию по прецедентам, рис. 10.2. Системные функции, определенные в модели бизнес-прецедентов (разд. 3.5.2), можно использовать для написания первоначального тест-плана. Затем модель прецедентов используется для написания документации по тест-прецедентам и определения тестовых требований. Дефекты, обнаруженные во время тестирования, фиксируются в документации по дефектам. В документации по усовершенствованию отражаются все не-
реализованные требования-прецедентък При использовании CASE-средств у разработчиков существуют следующие возможности по созданию документации.
Разработка описательных документов и их последующее использование для создания требований (тестовые требования, требования-прецеденты и т.д.) в С ASE-репозитории.
Использование CASE-средств для ввода требований в репозиторий и последующая генерация документации на их основе.
На рис. 10.3 показан фрагмент документации по тест-прецедентам, используемой для ввода тестовых требований в репозиторий. Аналогично требованиям- прецедентам тестовые требования нумеруются и организуются в виде иерархии. Некоторые тестовые требования непосредственно соответствуют требованиям- прецедентам. Отсюда основной раздел документа называется “Соответствие спецификации прецедентов”.
Остальные разделы документа по тестовым прецедентам должны идентифицировать требования к тестированию GUI-интерфейса, тестированию баз данных и тестированию повторно используемых компонент. Этот вид тестов следует включить в виде составной части в тестовые или функциональные модули по двум причинам. Во- первых, для тестирования GUI-интерфейса, баз данных и общих компонент (например, таких, которые оформляются в виде библиотек DLL) нам необходим функциональный контекст, в рамках которого имеют смысл входные и выходные данные. Во-вторых, дефекты GUI, баз данных и общих компонент могут проявиться только в контексте некоторых, но далеко не всех функциональных тестов.
Документация по тестовым прецедентам используется для фиксации результатов. Отсюда три столбца после каждого тестового требования, показанные на рис. 10.3. Тестовое требование может завершиться неудачным тестированием, пройти испытание условно или безусловно
Рис. 10.2. Документация по тестированию и управлению изменениями
Puc. 10.3. Документация no тест-прецедентамPuc. 10.3. Документация no тест-прецедентамApplication Name : OnLine ShoppingApplication Name : OnLine ShoppingUnit Name : |TCR1 Order Configured Computer] Version : [Location: \\Kosciuszko\Projects\Test Cases\Test_OrdConfCmp Use Case : OnLineShopping :: Order_Conf_CompUnit Name : |TCR1 Order Configured Computer] Version : [Location: \\Kosciuszko\Projects\Test Cases\Test_OrdConfCmp Use Case : OnLineShopping :: Order_Conf_CompTester:Tester:Test Results Mill itsTest Results Mill itsNo of Classes:No of Classes:Coding Eirors :$£|Database En ol's : ЙИCoding Eirors :$£|Database En ol's : ЙИNo of Methods:No of Methods:Design Errors :GUIEn-ors:Design Errors :GUIEn-ors:Conformance to Use Case SpecsConformance to Use Case SpecsfrCRl. 1,1 The title of the foi m is "Older YourfrCRl. 1,1 The title of the foi m is "Older YourNo of Lines:No of Lines:Specification Errors :Specification Errors :FailFailPass conditionallyPass conditionallyPassPass
Puc. 10.3. Документация no тест-прецедентам
Puc. 10.3. Документация no тест-прецедентам
Application Name : OnLine Shopping
Application Name : OnLine Shopping
Unit Name : |TCR1 Order Configured Computer] Version : [
Location: \\Kosciuszko\Projects\Test Cases\Test_OrdConfCmp Use Case : OnLineShopping :: Order_Conf_Comp
Unit Name : |TCR1 Order Configured Computer] Version : [
Location: \\Kosciuszko\Projects\Test Cases\Test_OrdConfCmp Use Case : OnLineShopping :: Order_Conf_Comp
Tester:
Tester:
Test Results Mill its
Test Results Mill its
No of Classes:
No of Classes:
Coding Eirors :$£|
Database En ol's : ЙИ
Coding Eirors :$£|
Database En ol's : ЙИ
No of Methods:
No of Methods:
Design Errors :
GUIEn-ors:
Design Errors :
GUIEn-ors:
Conformance to Use Case Specs
Conformance to Use Case Specs
frCRl. 1,1 The title of the foi m is "Older Your
frCRl. 1,1 The title of the foi m is "Older Your
No of Lines:
No of Lines:
Specification Errors :
Specification Errors :
Fail
Fail
Pass conditionally
Pass conditionally
Pass
Pass
Управление изменениями
Тестирование приводит к обнаружению дефектов. Дефекты необходимо исправлять. Чтобы исправить дефекты, их необходимо отправить в виде запросов на изменение {change requests) и адресовать разработчикам. Некоторые запросы на изменение связаны с усовершенствованием, а не исправлением дефектов. Как дефекты, так и усовершенствования изменяют свой статус, им могут быть присвоены различные приоритеты, за их сопровождение могут отвечать различные лица, их необходимо отслеживать в связи с их источниками в виде документации по тестированию и прецедентам и т.д.
Управление изменениями для любого программного проекта, в котором принимает участие большое количество разработчиков, представляет собой сложную и ответственную задачу. Рассмотрим сценарий, в рамках которого исправление двух различных дефектов поручено двум различным разработчикам, при этом оказалось, что исправление этих на первый взгляд несвязанных дефектов требует внесения изменении в одну и ту же программную компоненту. До тех пор, пока разработчики не будуг знать об этом возможном конфликте, оба разработчика могут одновременно работать
над исправлением, и в конце концов более позднее исправление приведет к отмене исправления, сделанного раньше.
Для надлежащего управления изменениями необходимо применение средств управления запросами на изменения (как правило, входящих в состав CASE-средств). Подобные средства обеспечивают возможность интерактивного управления изменениями и гарантируют работу всех разработчиков с последними версиями документов. Изменения, внесенные в документ одним из участников проекта, тут же становятся достоянием остальных разработчиков. Потенциальные конфликты разрешаются с помощью механизмов блокировки или управления версиями. В первом случае заблокированный документ становится временно недоступен другим разработчикам. В последнем случае возможно создание нескольких версий одного документа, а конфликты между версиями разрешаются позднее посредством согласования.
Отправка запроса на изменение
Обычно запрос на изменение связан либо с дефектом, либо с усовершенствованием. Запрос на изменение вводится в проектный репозиторий. После ввода в репозиторий разработчики могут отслеживать продвижение запроса на изменение, наблюдать за его статусом и действовать в соответствии с ним. Действия, выполняемые над запросом на изменение, зависят от текущего статуса запроса.
На рис. 10.4 показана основная вкладка диалогового окна ввода информации о дефектах [69]. Дефекты нумеруются и подробно описываются.
Рис. 10.4. Окно подготовки информации для отправки запроса на изменение
Информацию о приоритете, серьезности, проекте и ответственном исполнителе можно ввести с помощью выбора подходящих значений выпадающего списка
(значения атрибутов, содержащихся в выпадающем списке и в других местах формы, можно настроить в соответствии с нуждами проекта). Остальные поля позволяют вводить описательную информацию, включая возможность присоединения документации, имеющей отношение к дефекту, в частности, фрагментов программного кода.
Действие по отправке запроса на изменение может привести к автоматическому уведомлению участников проектной бригады через электронную почту. После этого запрос на изменение переходит в состояние Submitted. Руководство проекта может настроить инструментальные средства таким образом, чтобы в каждом состоянии выполнялись заранее определенные действия. Например, в состоянии Submitted могут быть допустимы следующие действия: Assign (Назначить [задание]) (участнику бригады), Modify (Модифицировать (некоторые детали запроса)), Postpone (Отложить), Delete (Удалить) (без исправления). Close (Закрыть) (возможно, в результате исправления).
Отслеживание запросов на изменение
Каждый запрос на изменение назначается члену бригады. Член бригады может открыть (Open) запрос на изменение.
Рис. 10.5. Диаграмма измерений
Если запрос находится в состоянии Орт, никто из других членов бригады не может модифицировать статус запроса. После разрешения проблемы, связанной с запросом на изменение, разработчик может выполнить над ним действие Resolve. Подробности решения можно ввести в форму и отправить по электронной почте уведомление руководству проекта и специалистам по тестированию. Последним может потребоваться выполнить действие по верификации (Verify) разрешенного запроса на изменение.
На любом этапе средства управления изменениями могут отследить запросы и выработать легкие для понимания диаграммы и отчеты (проектные показатели (project metrics)). Диаграммы и отчеты могут содержать данные по оценке количества не распределенных по членам бригады дефектам помогают выявить загрузку каждого члена бригады, показать, сколько осталось неразрешенных дефектов и т.д.
На рис. 10.5 показана диаграмма распределения актуальных дефектов по приоритетам. Шесть дефектов должны быть разрешены немедленно, на пятьдесят пять следует обратить более пристальное внимание, шестьдесят семь находятся в обычной очереди и шестьдесят восемь имеют низкий приоритет.
Прослеживаемость
Прослеживаемость, тестирование и управление изменениями — не самоцель, и их значение не следует переоценивать. Разработчики должны концентрироваться на разработке, а не на отслеживании, тестировании или управлении изменениями. С этими проблемами, как правило, связаны значительные проектные расходы. Однако, в долгосрочной перспективе отсутствие управления этими проблемами влечет не менее значительные затраты.
Поскольку основу тестирования и управления изменениями составляет прослеживаемость, рамки и глубину прослеживаемости проекта следует определять с использованием анализа затрат и результатов. По меньшей мере прослеживаемость следует поддерживать между требованиями на основе прецедентов и дефектами. В более развитой модели между требованиями-прецедентами и дефектами в маршрут прослеживаемости можно добавить тестовые требования. В еще более сложной модели прослеживаемости рамки прослеживаемости могут включать системные функции, тестовые прецеденты, усовершенствования, точки тестовой верификации и другие артефакты разработки ПО.
Оставшаяся часть этой главы посвящена рассмотрению модели прослеживаемости, которая соответствует связям между системной документацией, показанной на рис. 10.2. В документации на бизнес-прецеденты перечислены системные функции. Документ, описывающий тесгплан, идентифицирует тестовые прецеденты. Функции связаны с тестовыми прецедентами и требованиями-прецедентами, что отражено в документации по прецедентам. Тестовые требования, представленные в документе по тестовым прецедентам, можно проследить назад к тестовым прецедентам и требованиям-прецедентам. Тестовые требования, связанные с дефектами и усовершенствованиями, прослеживаются до прецедентов-требований. Прослеживать дефекты до усовершенствований не требуется.
Прослеживаемость от системных возможностей к прецедентам и прецедентным требованиям
Функциональные возможности системы представляют собой общую часть функций, которые должны быть реализованы в системе. Это бизнес-процесс, представляющий собой существенную часть системы с точки зрения ее эффективности. Обычно сне-
темные функциональные возможности соответствуют бизнес-прецедентам модели биз- нес-прецедентов (разд. 3.5.2). Если модель бизнес-прецедентов формально не разрабатывалась, системные возможности идентифицируются в документе, отражающем стратегическое видение системы (в технологии Rational Rose подобный документ так и называется — Vision. Прим. ред.)
Каждая системная возможность реализуется с помощью требований-прецедентов, выраженных в виде одного или нескольких прецедентов. Прослеживание прецедентов обратно к потребностям заказчиков (выраженные в системных возможностях) помогает проверить обоснованность и правильность модели прецедентов. Эта стратегия “очерчивает рамки” фиксации требований и способствует выполнению этапа установления требований. Она также помогает осуществлению наращиваемой разработки и предоставлению программного продукта заказчикам.
Данная стратегия может стать источником проблем, если требования-прецеденты в рамах каждого прецедента связаны с функциями только косвенно. Это может привести к ситуации, при которой между функцией и прецедентом существует траектория, хотя большая часть требований-прецедентов не имеет отношения к функции. Принятие решения о том, обоснованно ли существование траектории между функцией и прецедентом, может оказаться тяжелой и неблагодарной задачей.
Рис. 10.6. Прослеживаемость от функций до прецедентов и требований-прецедентов
Чтобы избежать масштабирования и долговременных проблем, связанных с этой стратегией, матрица прослеживаемости должна отслеживать функции не только по
отношению к прецедентам, но также непосредственно по отношению к требованиям- прецедентам. Это возможно в том случае, если сам прецедент рассматривается как обобщенное требование-прецедент, под которым находится иерархия специализированных требований-прецедентов.
Это показано на рис. 10.6. Столбцы содержат прецеденты и требования-прецеденты в рамках прецедентов. Иерархическое представление требований-прецедентов можно свернуть или раскрыть. Стрелки обозначают траектории от функций к прецедентам и требованиям-прецедентам. Некоторые стрелки перечеркнуты. Это подозрительные траектории (suspect traces'). Траектория становится подозрительной, когда она направлена от или к изменению требований. Прежде, чем разорвать подозрительные связи, разработчику следует проанализировать их.
Прослеживаемость от тест-плана к тест- прецедентам и тестовым требованиям
Документ описания тест-плана играет для тест-прецедентов ту же роль, что документ описания бизнес-прецедентов для прецедентов. Тест-план идентифицирует обобщенную проектную информацию и программные компоненты (тест-прецедент ы), которые требуется протестировать. Тест-план описывает также стратегию тестирования для проекта, необходимые для тестирования ресурсы, усилия и затраты.
Рис. ЮЛ. Прослеживаемость от тест-плана к тест-прецедентам и тестовым требованиям
Каждый тест-прецедент, идентифицированный в тест-плане, должен быть описан в виде документа по тестпрецеденту. Отображение тестовых требований на тест прецеденты и тестпланы дает преимущества, аналогичные преимуществам применения прослеживаемости между функциями, прецедентами и требованиями-прецедентами — ограничение области тестирования, масштабируемость и т.д.
На рис. 10.7 показана матрица прослеживаемости от тест-плана к тест-прецедентам и тестовым требованиям в рамках тестпрецедентов. Иерархическое представление требований-прецедентов можно свернуть или раскрыть.
Прослеживаемость от UML-диаграмм к документам и требованиям
Прослеживаемость и управление требованиями применимо не только к описательным документам и требованиям, представленным в текстовом виде, которые хранятся в CASE-репозиторйи. Репозиторий хранит также UML-модели. Графические объекты UML-диаграмм могут быть связаны гиперссылками с документами и требованиями.
Прослеживаемость от визуальных артефактов UML к любым другим записям репозитория (в частности, документам и требованиям) можно установить для различных графических пиктограмм UML. Пожалуй, наиболее важными из этих пиктограмм являются пиктограммы прецедентов на диаграммах прецедентов.
Maintain Ad Duration Тolerances Maintain Ad LinksMaintain AdsMaintain Advertiser GroupsMaintain Agency GroupsMaintain Billboard Splits Maintain Category-Product Links [ModifyAdLinks [OrganizationAdvertiserMDEV OrganizationEV [Organization-OutletMDEVMaintain Ad Duration Тolerances Maintain Ad LinksMaintain AdsMaintain Advertiser GroupsMaintain Agency GroupsMaintain Billboard Splits Maintain Category-Product Links [ModifyAdLinks [OrganizationAdvertiserMDEV OrganizationEV [Organization-OutletMDEVitegoryTBV rntactEVitegoryTBV rntactEVrntactRBVrntactRBV:ilter Displayed Data ifteredDisplayedData:ilter Displayed Data ifteredDisplayedDataAssociate Document In Use Case ’Mnininm Ads'Associate Document In Use Case ’Mnininm Ads''AH Docmv e'it wpe'AH Docmv e'it wpePuc. 10.8. Установление в документе гиперссылок на графические пиктограммы прецедентовPuc. 10.8. Установление в документе гиперссылок на графические пиктограммы прецедентов
Maintain Ad Duration Тolerances Maintain Ad Links
Maintain Ads
Maintain Advertiser Groups
Maintain Agency Groups
Maintain Billboard Splits Maintain Category-Product Links [ModifyAdLinks [OrganizationAdvertiserMDEV OrganizationEV [Organization-OutletMDEV
Maintain Ad Duration Тolerances Maintain Ad Links
Maintain Ads
Maintain Advertiser Groups
Maintain Agency Groups
Maintain Billboard Splits Maintain Category-Product Links [ModifyAdLinks [OrganizationAdvertiserMDEV OrganizationEV [Organization-OutletMDEV
itegoryTBV rntactEV
itegoryTBV rntactEV
rntactRBV
rntactRBV
:ilter Displayed Data ifteredDisplayedData
:ilter Displayed Data ifteredDisplayedData
Associate Document In Use Case ’Mnininm Ads'
Associate Document In Use Case ’Mnininm Ads'
'AH Docmv e'it wpe
'AH Docmv e'it wpe
Puc. 10.8. Установление в документе гиперссылок на графические пиктограммы прецедентов
Puc. 10.8. Установление в документе гиперссылок на графические пиктограммы прецедентов
На рис. 10.8 показано диалоговое окно для установления гиперссылок между графическими пиктограммами прецедента (Maintain Ads) и документом. Гиперссылка устанавливается изнутри UML-диаграммы прецедентов В качестве связанного документа может выступать любой документ репозитория, включая документы, показанные на рис. 10.2.
На рис. 10.9 показано диалоговое окно для установления гиперссылок между графическими пиктограммами прецедента (Maintain Ads again) и требованием- прецедентом. В общем случае возможно установить связь между пиктограммой и любым типом требования.
UC. Use Case Requirement TypeUC. Use Case Requirement TypeAll locationsAll locationsUC10 Filter Displayed DatajiUC18: Maintain Ad Duration Tolerances|UC18.1: Create Ad Duration ToleranceIUC18.2: Update Ad Duration ToleranceUC18.3: Delete Ad Duration ToleranceUC18.4: Invalid RangeUC18.5: Invalid DateUC18.6: Ambiguous ToleranceUC18.7: Cannot Alter Historical ToleranceUC18.8: The system retrieves and displays the following information for aUC19: Maintain Ad LinksUC19.1: Modify Ad RelationshipsUC19.2: Make Changes|UC19.3: Modify Start DateluC19.4: Raw Ads Associated With Ad LinkUC19.5: List of Ad Relationships УС19-6: Updo Business Chw^ ,,UC10 Filter Displayed DatajiUC18: Maintain Ad Duration Tolerances|UC18.1: Create Ad Duration ToleranceIUC18.2: Update Ad Duration ToleranceUC18.3: Delete Ad Duration ToleranceUC18.4: Invalid RangeUC18.5: Invalid DateUC18.6: Ambiguous ToleranceUC18.7: Cannot Alter Historical ToleranceUC18.8: The system retrieves and displays the following information for aUC19: Maintain Ad LinksUC19.1: Modify Ad RelationshipsUC19.2: Make Changes|UC19.3: Modify Start DateluC19.4: Raw Ads Associated With Ad LinkUC19.5: List of Ad Relationships УС19-6: Updo Business Chw^ ,,Associate Requirement to Use Case "Maintain Ads'Associate Requirement to Use Case "Maintain Ads'Рис. 10.9. Установление гиперссылок требования на графические пиктограммы прецедентовРис. 10.9. Установление гиперссылок требования на графические пиктограммы прецедентов
UC. Use Case Requirement Type
UC. Use Case Requirement Type
All locations
All locations
UC10 Filter Displayed Dataj
iUC18: Maintain Ad Duration Tolerances
|UC18.1: Create Ad Duration Tolerance
IUC18.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
luC19.4: Raw Ads Associated With Ad Link
UC19.5: List of Ad Relationships УС19-6: Updo Business Chw^ ,,
UC10 Filter Displayed Dataj
iUC18: Maintain Ad Duration Tolerances
|UC18.1: Create Ad Duration Tolerance
IUC18.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
luC19.4: Raw Ads Associated With Ad Link
UC19.5: List of Ad Relationships УС19-6: Updo Business Chw^ ,,
Associate Requirement to Use Case "Maintain Ads'
Associate Requirement to Use Case "Maintain Ads'
Рис. 10.9. Установление гиперссылок требования на графические пиктограммы прецедентов
Рис. 10.9. Установление гиперссылок требования на графические пиктограммы прецедентов
Прослеживаемость от требований-прецедентов к тестовым требованиям
Прослеживаемость между требованиями-прецедентами и тестовыми требования ми является критическим фактором при оценке того, удовлетворяет ли приложение бизнес-требованиям, установленным для него. Связи между этими двумя типами требований позволяют пользователю прослеживать дефекты через тестовые требования назад к требованиям-прецедентам и системным функциям (см. рис. 10.2).
На рис. 10.10 показана матрица прослеживаемости, включающая траектории между требованиями-прецедентами и тестовыми требованиями. Обратите внимание, что как требования-прецеденты, так и тестовые требования организованы иерархически. Иерархические уровни, на которых определяются траектории, могут быть определены заранее.
Рис. 10.10. Прослеживаемость от требований-прецедентов к тестовым требованиям
Прослеживаемость от требований к дефектам
Документация по тест-прецедентам представляется в виде сценариев, содержащих тестовые требования, которые требуют верификации при тестировании. Сценарии используются при ручном тестировании, но многие из этих сценариев можно автоматизировать для использования в тестовых средствах “записи-воспроизведения". Тестовые требования в документации по тест-прецедентам можно затем использовать для установления точек верификации в этих автоматизированных тестах.
Точка верификации {verification point) — это требование, содержащееся в сценарии, которое используется (при регрессионном тестировании) для подтверждения состояния тестового объекта в рамках различных версий (скомпонованных версий) тестируемого приложения. Существуют различные типы точек верификации [69]. Точка верификации может быть установлена для проверки отсутствия изменений в тексте, точности числового значения, идентичности двух файлов, отсутствия изменений в пунктах меню, соответствия полученных результатов вычислений ожидаемым и т.д.
Автоматизированное тестирование требует работы с двумя файлами данных— базисным файлом данных и файлом фактических данных. Во время записи процедура точки ве рификации записывает информацию об объекте в базисный файл данных. Эта информация представляет собой базис для сравнения при последующих тестах {воспроизведении). Резуль-
AdEx2000 - iModify Ad Link Edit View (E'AdEx2000 - iModify Ad Link Edit View (E'птптAdExOOOOOI 41 AdPart Numbers / BillboardsAdExOOOOOI 41 AdPart Numbers / BillboardsAdExOOOOOI 42 Adding anew columnAdExOOOOOI 42 Adding anew columntftf*•141 r‘ • '^. -1;Ы1^*•141 r‘ • '^. -1;Ы1^I Split Billboard E a it View (EMI Split Billboard E a it View (EMdFart NumberdFart NumberAdEx2000 - Undo Billboard Split Edit VieAdEx2UC0 - ! Ad Links Row Browse ViewAdEx2000 - Undo Billboard Split Edit VieAdEx2UC0 - ! Ad Links Row Browse ViewAdEx2000- Product Split ReportAdEx2000- -Split Billboard Edit View (E VAdEx2000- Product Split ReportAdEx2000- -Split Billboard Edit View (E VAdExOOOOOI 32 jModify Ad Links screen labels AdExOOOOOI 38 iReporttoo large to print message AdExOOOOOI 39 I Incorrect SpecificationsAdExOOOOOI 32 jModify Ad Links screen labels AdExOOOOOI 38 iReporttoo large to print message AdExOOOOOI 39 I Incorrect SpecificationsPuc. 10.11. Прослеживаемость от тестовых требований к дефектамPuc. 10.11. Прослеживаемость от тестовых требований к дефектамSisSis
AdEx2000 - iModify Ad Link Edit View (E'
AdEx2000 - iModify Ad Link Edit View (E'
пт
пт
AdExOOOOOI 41 AdPart Numbers / Billboards
AdExOOOOOI 41 AdPart Numbers / Billboards
AdExOOOOOI 42 Adding anew column
AdExOOOOOI 42 Adding anew column
tf
tf
*•141 r‘ • '^
. -1;Ы1^
*•141 r‘ • '^
. -1;Ы1^
I Split Billboard E a it View (EM
I Split Billboard E a it View (EM
dFart Number
dFart Number
AdEx2000 - Undo Billboard Split Edit Vie
AdEx2UC0 - ! Ad Links Row Browse View
AdEx2000 - Undo Billboard Split Edit Vie
AdEx2UC0 - ! Ad Links Row Browse View
AdEx2000- Product Split Report
AdEx2000- -Split Billboard Edit View (E V
AdEx2000- Product Split Report
AdEx2000- -Split Billboard Edit View (E V
AdExOOOOOI 32 jModify Ad Links screen labels AdExOOOOOI 38 iReporttoo large to print message AdExOOOOOI 39 I Incorrect Specifications
AdExOOOOOI 32 jModify Ad Links screen labels AdExOOOOOI 38 iReporttoo large to print message AdExOOOOOI 39 I Incorrect Specifications
Puc. 10.11. Прослеживаемость от тестовых требований к дефектам
Puc. 10.11. Прослеживаемость от тестовых требований к дефектам
Sis
Sis
таты того сравнения запоминаются в файле фактических данных. Результаты каждой неудачной процедуры точки верификации требуют дальнейшего изучения и, при необходимости, внесения в репозиторий средств управления изменениями в качестве дефекта
Безусловно все дефекты, обнаруженные с помощью средств автоматизации или вручную, должны быть сопоставлены с тестовыми требованиями. На рис. 10.11 показано средство, которое отображает все дефекты с помощью строкового броузера в верхней части окна. Текущий выбранный дефект можно сопоставить с одним или более тестовым требованием. В приведенном примере показана траектория от двух тестовых требований к выделенному дефекту'.
Прослеживаемость от требований-прецедентов к усовершенствованиям
Дефекты необходимо прослеживать непосредственно до тестовых требований. Усовершенствования (которые должны быть реализованы в последующих выпусках продукта) должны содержать соответствующие пояснения о требованиях-прецедентах. Изредка, в ситуации, когда дефект был преобразован в усовершенствование, связь по прослеживаемости между требованиями-прецедентами и тестовыми требованиями может позволить пользователю проследить путь дефекта до усовершенствования.
На рис. 10.12 продемонстрировано то же средство (см. рис. 10.11), которое можно использовать для управления усовершенствованиями и дефектами, как, впрочем, и для любых других типов запросов на изменения.
6b Rational ClenrQuest - [AdEx Clearquest database tor AdEx2000 system (All Det
Entering a years worth of On-sale Dates for a publication! AdEx20GG - Data CollectionEntering a years worth of On-sale Dates for a publication! AdEx20GG - Data CollectionDual monitoring of the same outlet log. Collection Status attached to a Media GroupDual monitoring of the same outlet log. Collection Status attached to a Media GroupAdExOOOOOI 02 Electronic Logs tor Cinema & OutdoorAdExOOOOOI 02 Electronic Logs tor Cinema & Outdoor|AdEx2000 - Quality Control l!AdEx2000 - Quality Control lAdEx2000 - Quality Control|AdEx2000 - Quality Control l!AdEx2000 - Quality Control lAdEx2000 - Quality Control[AdEx2000 - Data Collection I AdFx20U0 - Data Collection iAdEx2000 - Data Collection[AdEx2000 - Data Collection I AdFx20U0 - Data Collection iAdEx2000 - Data CollectionAdExOOOOOI 01AdExOOOOOI 87 AdExOO666ll4 |AdEx00000t)56 [AdMOClOOIM AdEx000Q025CAdExOOOOOI 01AdExOOOOOI 87 AdExOO666ll4 |AdEx00000t)56 [AdMOClOOIM AdEx000Q025CVertical & Horizontal Scroll Bars Setting Merges to run afterhours.Minimise button tor the A. .ink Merge windowVertical & Horizontal Scroll Bars Setting Merges to run afterhours.Minimise button tor the A. .ink Merge window^ Rational CleorQuest (AdEx. Clearquest database lor AdEx2000 system (All Enhanc.^ Rational CleorQuest (AdEx. Clearquest database lor AdEx2000 system (All Enhanc.Puc. 10.12. УсовершенствованияPuc. 10.12. Усовершенствования
Entering a years worth of On-sale Dates for a publication! AdEx20GG - Data Collection
Entering a years worth of On-sale Dates for a publication! AdEx20GG - Data Collection
Dual monitoring of the same outlet log. Collection Status attached to a Media Group
Dual monitoring of the same outlet log. Collection Status attached to a Media Group
AdExOOOOOI 02 Electronic Logs tor Cinema & Outdoor
AdExOOOOOI 02 Electronic Logs tor Cinema & Outdoor
|AdEx2000 - Quality Control l!AdEx2000 - Quality Control lAdEx2000 - Quality Control
|AdEx2000 - Quality Control l!AdEx2000 - Quality Control lAdEx2000 - Quality Control
[AdEx2000 - Data Collection I AdFx20U0 - Data Collection iAdEx2000 - Data Collection
[AdEx2000 - Data Collection I AdFx20U0 - Data Collection iAdEx2000 - Data Collection
AdExOOOOOI 01
AdExOOOOOI 87 AdExOO666ll4 |AdEx00000t)56 [AdMOClOOIM AdEx000Q025C
AdExOOOOOI 01
AdExOOOOOI 87 AdExOO666ll4 |AdEx00000t)56 [AdMOClOOIM AdEx000Q025C
Vertical & Horizontal Scroll Bars Setting Merges to run afterhours
.Minimise button tor the A. .ink Merge window
Vertical & Horizontal Scroll Bars Setting Merges to run afterhours
.Minimise button tor the A. .ink Merge window
^ Rational CleorQuest (AdEx. Clearquest database lor AdEx2000 system (All Enhanc.
^ Rational CleorQuest (AdEx. Clearquest database lor AdEx2000 system (All Enhanc.
Puc. 10.12. Усовершенствования
Puc. 10.12. Усовершенствования
Резюме
В этой последней главе книги мы обратились к вопросам тестирования и управления изменениями. Деятельность по тестированию и управлению изменениями охватывает весь ЖЦ разработки ПО, однако, наибольшее внимание ей уделяется ближе к завершению проекта. Тестирование и управление изменениями предполагает существование связей по прослеживаемости между системными артефактами, которые надлежащим образом поддерживаются в течение всей разработки.
Тестирование подразделяется на тестирование системных услуг и тестирование системных ограничений. Тестирование системных услуг может быть основано на выполнении программы или проводиться без выполнения программы. Тестирование без выполнения программы включает сквозной контроль и инспекции. Тестирование с прого ном программы может быть тестированием по отношению к спецификации или тестированием по отношению к программному код.
Тестирование системных ограничений включает широкий набор относительно самостоятельных тестов, которые относятся к таким вопросам, как пользовательский интерфейс, базы данных, авторизация, производительность, утяжеленный режим, поведение при отказах, конфигурация и инсталляция приложения. Некоторые из тестов системных ограничений проводятся в параллель с тестированием системных услуг, другие выполняются независимо.
Тестирование и управление изменениями требуют разработки специальной документации, такой как документы по планированию тестов, документы по тестовым прецедентам, документы по дефектам и усовершенствованиям. Тестовые требования идентифицируются в документах по тестовым, прецедентам и увязываются с документами по требованиям-прецедентам и прецедентам. Запрос на изменение обычно связан с дефектом или усовершенствованием.
Средства управления изменениями позволяют отправлять запросы на изменения и отслеживать их продвижение после обращения к ним разработчика. Важная часть средств управления изменениями связана с установлением путей прослеживаемости между запросами на изменения и другими системными артефактами, в частности, тестовыми требованиями и требованиями-прецедентами.
Вопросы
Bl.
В чем отличие сквозного контроля от инспекции?
В2.
В чем заключается роль группы обеспечения качества (SQA-группы) в организации?
ВЗ.
Что такое база данных авторизации? Какова ее роль в разработке и тестировании системы?
В4.
Какие виды тестирования системных ограничений тесно связаны с тестированием в утяжеленном режиме? Поясните свой ответ.
В5.
Какие виды тестирования системных ограничений тесно связаны с инсталляционным тестированием? Поясните свой ответ.
Вб.
Какие действия возможны в ответ на отправленный запрос на изменения?
В7.
Что такое “подозрительная траектория”? Приведите пример.
В8.
Что такое точке верификации?
В9.
Объясните различие между файлом базисных данных и фактическими данными.
Литература
Allen, Р. and Frost, S. Component-Based Development for Enterprise Systems. Applying the SELECT Perspectives, Cambridge University Press, 1998, 462 pp.
Angell, 1.0. and Smithson, S. Information Systems Management. Opportunities and Risks, Macmillan, 1991, 248 pp.
Arthur, LJ. Rapid Evolutionary Development. Requirements, Prototyping and Software Creation, John Wiley&Sons, 1992, 222 pp.
Bahrami, A Object Oriented Systems Development, Irwin McGraw-Hill, 1999, 412 pp.
Bennett, S. McRobb, S. and Farmer, R. Object-Oriented Systems Analysis and Design Using UML, McGraw-Hill, 516 pp., 1999
Bochenski, B. Implementing Production-Quality Client/Server Systems, John Wiley&Sons, 1994, 442 pp.
Bollinger, T.B. and McGowan, C. A Critical Look at Software Capability Evaluations, IEEE Software, 4, 1991, pp. 25-41
Booch, G. Rumbaugh, J. and Jacobson, I. The UniKDed Modeling Language. User Guide, Addison-Wesley, 1999, 482 pp.
Bourne, K.C. Testing Client/Server Systems, McGraw-Hill. 1997, 572 pp.
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
Buschmann, F. Meunier, R. Rohnert, H. Sommerlad, P. and Stal, M. Pattern-Oriented Software Architecture. A System of Patterns, John Wiley & Sons, 1996,458 pp.
The Capability Maturity Model: Guidelines for Improving the Software Process. Addison- Wesley, 1995, 442 pp.
Coad, P. with North, D. and Mayfield, M. Object Models. Strategies, Patterns, and Applications, Yourdon Press, 1995, 506 pp.
Collins, D. Designing Object-Oriented User Interfaces, Benjamin/Cummings Publ., 1995, 590 pp.
Conallen, J. Building Web Applications with UML, Addison-Wesley, 2000, 300 pp.
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.
Date, CJ. An Introduction to Database Systems, Addison-Wesley, 7th edit., 2000,938 pp.
Davenport. Т.Н.Process Innovation: Reengineering Work through Information Technology, -Harvard Business School Press, 1993, 338 pp.
Davenport, Т.Н. and Short, J. The New Industrial Engineering. Information Technology and Business Process Redesign. Sloan Management Review. Cambridge, Summer, 1990, pp. 11, 17.
Eaglestone, B. and Ridley, M. Object Databases, McGraw-Hill, 1998, 380 pp.
Eisenberg, A. and Melton, J. SQL:1999, Formerly Known asSQL3, ACM SIGMOD Rec., 1, 1999, pp. 131-138.
Elmasri, R. and Navathe, S.B. Fundamentals of Database Systems, 3rd edn, Addison-Wesley, 2000, 956 pp.
Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997, 358 pp.
Fowler, M. UML P Current Status for Version 1.3, http://ourworld.compuserve.com/_homepages/Martin_Fowler/umlst.htm, 1999, 2 pp.
Fowler, M. and Scott, K.UML Distilled. A Brief Guide to The Standard Object Modeling Language, 2nd edn, Addison-Wesley, 2000, 186 pp.
Fowler, S.GUI Design Handbook, McGraw-Hill, 1998, 318 pp.
Galitz. W.O.The Essential Guide to User Interface Design. An Introduction to GUI Design Principles and Techniques, John Wiley&Sons, 1996, 626 pp.
Gamma, E. Helm, R. Johnson, R. and Vlissides, J.Design Patterns. Elements of Reusable Object- Oriented Software. Addison-Wesley, 1995, 396 pp.
Gray, N.A.B.Programming with Class, John Wiley&Sons, 1994, 624 pp.
Hammer, M.Reengineering Work: DonXt Automate, Obliterate, Harvard Business Review, Boston. Jul/Aug, 1990, p. 104.
Hammer, M. and Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution, Allen&Unwin, 1993, 224 pp.
Hammer. M. and Champy, J.The Promise of Reengineering. Fortune. 9.1993. p. 94.
Hammer, M. and Stanton, S.How Process Enterprises Really Work, Harvard Business Review, Boston, Nov/Dec, 1993, pp. 108-118.
Harmon, P. and Watson, M.Understanding UML: The Developer’s Guide. With a Web-Based Application in Java, Morgan Kaufmann, 1998, 368 pp.
Hawryszkiewycz, I. Karagiannis, D. Maciaszek, L. and Teufel, B.RESPONSE P Requirements Specific Object Model for Workgroup Computing, Int. J. of Intelligent & Cooperative Information Systems, 3, 1994, pp. 293-318.
Henderson-Sellers, B.Object-Oriented Metrics. Measures of Complexity, Prentice Hall. 1996, 230 pp.
Hoffer, J.A George, J.F. and Valacich, J.S.Modern Systems Analysis and Design, 2nd edit, Addison-Wesley, 1999, 854 pp.
Horton, 1.Beginning Visual C++ 5, Wrox Press, 1997, 1054 pp.
9. Jacobson, I.Object-Oriented Software Engineering. A Use Case Driven Approach, Addison- Wesley, 1992, 524 pp.
Jordan, E.W. and Machesky, J.J.Systems Development. Requirements, Evaluation, Design, and Implementation, PWS-KENT Publ. Company, 1990, 648 pp.
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.
' Kimball, R.The Data Warehouse Toolkit. Practical Techniques for Building Dimensional Data Warehouses, John Wiley&Sons, 1996, 388 pp.
Kirkwood, J.High Performance Relational Database Design, Ellis Horwood, 1992. 266 pp.
Koesller, A.The Ghost in the Machine, Hutchinson, 1967, 384 pp.
Koestler, A.Janus. A Summing Up, Hutchinson, 1978, 354 pp.
Kotonya, G. and Sommerville, I.Requirements Engineering. Processes and Techniques. John Wiley&Sons, 1998, 282 pp.
Kruchten, P.The Rational Unified Process, Addison-Wesley, 1999, 256 pp.
Lakos, J.Large-Scale C++ Software Design, Addison-Wesley, 1996, 846 pp.
Lee, R.C. and Tepfenhart, W.M.UML and C++. A Practical Guide to Object-Oriented Development, Prentice-Hall, 1997, 446 pp.
Lieberherr, KJ. and Holland, LM-Assuring Good Style for Object-Oriented Programs, IEEE Soft., 9, 1989, pp. 38-48.
Maciaszek, L.A.Database Design and Implementation, Prentice-Hall, 1990, 384 pp.
Maciaszek, L.A. Object Oriented Development of Business Information Systems P Approaches and Misconceptions, Proc. 2nd Int. Conf, on Business Information Systems BISX98, Poznan, Poland, 1998, pp. 95-111.
Maciaszek, L.A.Process Model for Round-Trip Engineering with Relational Database, in: Challenges of Information Technology Management in the 21st Century, 2000 Information Resources Management Association International Conference, Anchorage, Alaska. USA, Idea Group Publishing, pp. 2000, 468-472.
Maciaszek, L.A. De Troyer, O.M.F GettaJ.R. and Bosdriesz, J.Generalization 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.
Maciaszek, L.A. Getta, J.R. and Bosdriesz, J.Restraining Complexity in Object System Development P the ‘AD-HOC’ Approach, Proc. Sth Int. Conf, on Information Systems Development ISDX96, Gdansk, Poland, 1996, pp. 425-435.
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 Resources Management Association International Conference, Anchorage, Alaska, USA, Idea Group Publishing, 2000, pp. 473-477.
NEXTNext Generation Computing. Distributed Objects for Business, ed. P. Fingar, D. Read and J. Stikeleather, SIGS Books&Multimedia, 1996, 306 pp.
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.
Olsen, D.R.Developing User Interfaces. Morgan Kaufmann Publ., 1998, 414 pp.
Page-Jones, M.Fundamentals of Olyect-Oriented Design in UML, Addison-Wesley, 2000, 458 pp.
ParadigmParadigm Plus. Round-trip Engineering with Microsoft Visual C++, Platinum Technology, 1997, 36 pp.
Pfleeger, S.L.Software Engineering. Theory and Practice, Prentice-Hall, 1998, 576 pp.
Porter, M.Competitive Advantage: Creating and Sustaining Superior Performance, Free Press, 1985, 558 pp.
Porter, M.E. and Millar, V.E.How Information Gives You Competitive Advantage, Harvard Business Review, Jul/Aug, 1985, pp. 149-161.
Pressman, r.S.Software Engineering. A Practitioner’s Approach, 4th edn, McGraw-Hill, 1997, 852 pp.
Quatrani, T.Visual Modeling with Rational Rose 2000 and UML, Addison-Wesley, 2000, 256 pp.
Ramakrishnan, R. and Gehrke, J.Database Management Systems, McGraw-Hill, 2000, 906 pp.
RationalRational Rose 98. Roundtrip Engineering with C++, Rational Software Corp., 1998, 454 pp.
RationalRational Solutions for Windows, OnLine Documentation April 2000 Edition, Rational Software Corp., 2000.
Riel, AJ.Object-Oriented Design Heuristics, Addison-Wesley, 1996, .380 pp.
Robertson, J. and Robertson, S.Volere Requirements Specifications Template, Edition 6.1, Atlantic Systems Guild, http://www.atlsysguild.com, 2000, 52 pp.
Robson, W.Strategic Management and Information Systems. An Integrated Approach, Pitman Publ., 1994, 570 pp.
Ruble, D.A.Practical Analysis and Design for Client/Server and GUI Systems, Yourdon Press, 1997, 516 pp.
Rumbaugh, J. Blaha, M. Premerlani, W. Eddy, F. and Lorensen, W.Object-Oriented Modeling and Design, Prentice-Hall, 1991, 500 pp.
Rumbaugh, J.Getting Started. Using Use Cases to Capture Requirements, J. Object-Oriented Prog., Sept., 1994, pp. 8-10, 12, 23.
Rumbaugh, J. Jacobson, I. and Booch, G.The Unified Modeling Language Reference Manual, Addison-Wesley, 1999, 550 pp.
Schach, S.Classical and Object-Oriented Software Engineering, 3rd edn, Irwin, 1996, 604 pp.
Schmauch, C.H.ISO 9000 for Software Deevelopers, ASQC Quality Press, 1994,156 pp.
Silberschatz, A. Korth, H.F. and Sudershan, S.Database System Concepts, 3rd edn, McGraw-Hill, 1997, 864 pp.
Smith, J.M. and Smith, D.C.P.Database Abstractions: Aggregation and Generalization, ACM Trans. Database Syst., 2, 1977, pp. 105-133.
Sommerville, I. and Sawyer, P.Requirements Engineering. A Good Practice Guide, John Wiley&Sons, 1997, 392 pp.
Sowa, J.F. and Zachman, J.A.Extending and Formalizing the Framework for Information Systems Architecture, IBM Syst. J., 3, 1992, pp. 590-616.
SQL Database Language SQL P Part 2: Foundation (SQL/Foundation), ISO-ANSI Working Draft, March 2000, 1170 pp.
Stein, L.A. Lieberman, H. Ungar, D.A Shared View of Sharing: The Treaty of Orlando, in: Object-Oriented Concepts, Databases, and Applications, ed. W. Kim and F.H. Lochovsky, Addison- Wesley, 1989, pp. 31-48.
Stevens, P. and Pooley, R.Using UML Software Engineering with Objects and Components, Addison-Wesley, 2000, 256 pp.
Stodder, D.Tlie Database Dozen, Database Prog, and Design, Industry in Focus Issue, Dec., 1997, pp. 9-24.
Stonebraker, M. and Moore, D.Object-Relational DBMSs. The Next Great Wave, Morgan Kaufmann Publ., 1996, 216 pp.
Szyperski, C.Component Software. Beyond Object-Oriented Programming, Addison-Wesley. 1998,412 pp.
Treisman, H.How to Design a Good Interface Design, Software Magazine, Australia, August, 1994, pp. 32-36.
Umar, A.Object-Oriented Client/Server Internet Environments, Prentice Hall. 1997, 528 pp.
Whitten, J.L. and Bentley, L.D.Systems Analysis and Design Methods, 4th edn, Irwin McGraw- Hill, 1998, 724 pp.
WindowsThe Windows Interface Guidelines for Software Design, MSDN Library, CDROM collection. Microsoft, 2000
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.
Wirfs-Brock, R. Wilkerson, B. and Wiener, L.Designing Object-Oriented Software, Prentice-Hall, 1990, 342 pp.
Wood, J. and Silver, D.Joint Application Development, 2nd edn, John Wiley&Sons, 1995, 402 pp.
Yourdon, E.Object-Oriented Systems Design. An Integrated Approach. Yourdon Press. 1994,
400 pp.
Zachman, J.AA Framework for Information Systems Architecture, IBM Syst. J., 3,1987, pp. 276-292.
Предметный указатель
А
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-системы, ПО
ЕИ:диаграммы, 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
MDl-приложение дочернее окно, 304 родительское окно, 304
N
NSAPI, 265
О
Object Management Group. См. OMG
ODBC, 265
ODMG, 318
OID. См. Идентификатор объекта
OLAP, 216
OMG, 38
OSQL, 319
R
RAD. См. Метод быстрой разработки приложений
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
единичная кратность, 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
КАО-МСТОД,^,'! : V анкетирование, 119; изучение документов и я. -. программных систем, 120 интервью, 1171
наблюдение, 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' ; >4 ' " ‘" навигации по окнам, '307 - 11 пакетов., 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
Значения атрибута, 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
Методология реинжиниринга бизнес- процессов. См. Подход 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
реализация ассоциации, 321
стандарт ODMG 3.0,318
типы литералов, 319
типы литералов, атомические, 319
типы литералов, коллекция, 320 типы литералов, пустой (null), 320 типы литералов, структурированный, 320 типы объектов, 320 элементарные типы данных, 319
Модель ОРБД множественное наследование интерфейса, 332 наследование типа of, 336 наследование типа under, 335 объектная таблица. 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
состояние, 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
реализация с помощью кооперации, 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
Пользовательский интерфейс, 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
Серверная страница, 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
баз данных, 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
ш
событийный, 146
Шаблон, 241 анализа, 241 определение, 241 параметризованный тип, 252 проектирования, 241
Шаблоны для классов, 146
Шаблоны для классов (по Барами) класс, 146 местоположений, 146 организационный, 146 понятийный, 146
Шаблоны для классов (по Рамбау) бизнес-класс, 146 компьютерный, 146 логический, 146 поведенческий, 146 прикладной, 146 физический,146
э
Элементарный тип, 67
Элементы размещения, 246
2. Присвоение большинства ученых степеней является прерогативой одного факультета, но некоторые ученые степени находятся в совместном ведении двух и более факультетов.
3. Новые студенты получают уведомление о приеме и инструкции по записи на курсы по почте. Студенты, продолжающие учебу, которые имеют право перезаписаться на курсы, получают (также по почте) инструкции по записи вместе в уведомлением об экзаменационных результатах.
4. Инструкции по записи на курсы включают расписание аудиторий для предлагаемого курса.
5. В период записи на курсы студенты могут получить консультацию у научного руководителя на факультете, на котором они числятся, по вопросу составления программы обучения.|
6. Студенты не ограничены в изучении только тех курсов, которые предлагаются их фа- | культетом, и в любой момент могут сменить факультет, на котором они числятся * (заполнив форму изменения программы, которую можно получить в деканате).)
7. Чтобы взять определенные курсы, студент должен сначала пройти обязательные курсы, получив требуемые оценки (простого прохождение курса может быть недос- [