Вигерс Карл. Разработка требований к программному обеспечению

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

OK;

выход из функции

запроса

Падвердать,

что

запрос

тр«ш

запросить отменить

размещение

запроса

весь запрос

отправить запрос

для

количества

химикатов

больше

нуля

Слисок

екуощ

запвосов

г~

удалить химикат

1вг

из списка

запросить

другой химикат

неправильное

р"-^"-—

™~-^-"*",

UUuJndHtrhilc

*«"•«••

Отобразить

химиката

сообщение i

[

обошибке

1 у

дг

. .

„.,

ик

._„..ж.......

Ввести

«ймикат

язагчэа

^ЖГ

отменить

добавление

нового химиката

отменить

добавление

нового химиката

запросить

хшикат

vJ^

у поставщика

*™*

npt

;

запросить

другой химикат

запросить химикат запросить

на

склад

выбрать контейнер

добавить к списку

е д

•

Список

В1

брать поставщика

убавить

к списку

сок

поставщиков!

ко

орых

можно j

юбэести

химикат

ПООСИТЬ

химикат

у поставщика

RUT

запрость историю

контейнера

возврат

Рис.

-5. Карта диалогов для варианта использования «Запрос химиката»

в системе Chemical Tracking System

Глава

11.

Любое изображение стоит

1024

слов

225

Некоторые переходы на карте диалогов позволяют пользователю

откатить операцию. Пользователей раздражает, если они уже переду-

мали, а им все-таки приходится завершать задачу. Карты диалогов по-

зволяют облегчить и упростить работу, предлагая функции отката и от-

мены в стратегических точках.

Пользователь, изучающий карту диалогов, может обнаружить не-

достающее требование. Например, осторожный пользователь может

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

избежать непроизвольной потери данных. Дешевле добавить такую

функцию на этапе анализа, чем встраивать ее в уже законченный про-

дукт, Поскольку карта диалогов представляет концептуальные элемен-

ты, участвующие во взаимодействии пользователя и системы, не пы-

тайтесь зафиксировать все детали пользовательского интерфейса на

этапе работы над требованиями. Лучшее применение этих моделей —

помочь всем, кто заинтересован в проекте, выработать общее понима-

ние предполагаемой функциональности системы.

Диаграмма классов

Объектно-ориентированная разработка ПО вытеснила структурный

анализ и разработку, породив

объектно-ориентированные

анализ и

разработку. Как правило, в предметной или рабочей области объекты

(objects) соотносятся с объектами реального мира. Они представляют

отдельные экземпляры, выведенные из родового шаблона, который

называется класс (class). В описания классов входят атрибуты (дан-

ные)

действия,

которые можно выполнять с этими атрибутами.

Диа-

грамма классов (class diagram) — это графический способ отобразить

классы, идентифицированные в ходе объектно-ориентированного

анализа, и взаимоотношений между ними.

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

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

ний. Дело

том, что требования отражают то, что пользователям необ-

ходимо сделать с помощью системы, и особенности предполагаемой

функциональности, а не то, как она будет создана. Пользователям не

придется вникать в объекты и классы. Однако если вы собираетесь

разрабатывать систему с помощью объектно-ориентированных прие-

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

нов, их атрибутов и поведения. Это упростит переход от анализа к ди-

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

226 Часть II. Разработка

требований

к ПО

системными объектами и детализирует атрибуты и операции

каждого

класса.

Стандартным языком объектно-ориентированного моделирования

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

Modelino

Language,

UML)

(Booch,

Rumbaugh и Jacobson, 1999). На уровне

абст

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

исполь

зовать систему обозначений

UML

в диаграмме классов, как показано

на рис.

11-6

для

части—

вы правильно

угадали—

Chemical

Tracking

System. Дизайнер переработает эти концептуальные диаграммы

клас-

сов, не зависящие от особенностей реализации, в более

подробны»:;

диаграммы классов для объектно-ориентированного дизайна и

реали-

зации. Взаимодействия классов и сообщения, которыми они

обмени

ваются,

демонстрируют диаграммы последовательностей и диаграм-

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

baugh; Jacobson

(1999)

и Lauesen (2002).

На рис.

11-6

показано

4 класса — каждый в большом прямоугольни-

ке: Сотрудник, разместивший заказ на химикат, Каталог

поставщика.

Запрос химиката и Элемент строки запроса. Вы видите, что информа-

ция на этой диаграмме классов и данные на другой

модели

анализа, из

тех, что показаны в этой главе, похожи

(неудивительно

— везде

обсуж-

дается одна и та же проблема). Сотрудник, разместивший заказ на хи-

микат, показан на диаграмме «сущность — связь» на рис.

11-2,

где он

представляет действующее лицо — член класса пользователей Хими-

ки или Сотрудники склада химикатов. На диаграмме

потоков

данных

рис.

11-1

также

видно,

что оба эти класса могут размещать запросы

химикатов. Кстати, не путайте класс пользователей и класс

объектом,

невзирая на схожесть названий, они не связаны

между

собой.

Атрибуты (attributes), связанные с классом Сотрудник, разместив-

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

рый обозначает их класс: имя,

Ю_сотрудника,

Номер_отдела и Но

мер_офиса (правило применения заглавных букв довольно

распро-

странено в

UML

диаграммах). Это свойства или элементы

данньк,

связанные с каждым

объектом

— членом класса Сотрудник, разместив-

ший заказ на химикат. Похожие атрибуты могут содержаться в опреде-

лении хранилищ на диаграмме потоков данных или в

словаре

данных.

Операции (operations) — это службы, которые объект каждого клас-

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

д,

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

классов,

представляющей дизайн, эти операции соответствуют функциям

или

методам

класса,

а аргумент функции часто заключен в скобки. В

мо-

дели анализа класса просто должно быть показано, что Сотрудник,

Глава

11.

Любое изображение стоит 1024 слов 227

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

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

химиката-

ми. Операции на диаграмме классов весьма приблизительно

соответ-

ствуют процессам, показанным в кружках на диаграммах потоков дан -

ных

нижних уровней.

Сотрудник,

размесшшш

заказ

на

хишкат

name

employeeNumber

department

roomN

umber

iner()

Запрос

химиката

requestNumber

requesterName

chargeNumber

fulfiilfnentLocation

submitn

cancelfl

postponed

retrieve})

vendqrName

chemicalld

catalogNumber

containerSizesAvailable

displaylnformationO

chemicalld

vendqrName

quantity

quantityUnits

add()

delete!)

Рис.

-6. Диаграмма классов для части Chemical

Tracking

System

Линии,

соединяющие прямоугольники классов на рис.

-6, симво-

лизируют связи между классами. Цифры на них указывают на множе-

ственность связи, точно так же, как линии на диаграммах «сущность —

связь"

— на множественность взаимоотношений между объектами. На

рис.

11-6

знак звездочки обозначает связь «один ко многим» между

классами Сотрудник, разместивший заказ на химикат, и Запрос хими-

ката: один сотрудник может разместить множество запросов, но каж-

дый

запрос

принадлежит только одному сотруднику.

228

Часть II. Разработка требований к ПО

Таблицы решений и деревья решений

Часто система ПО управляется сложной логикой, учитывающей раз-

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

различ-

ное поведение системы. Например, если водитель нажимает

кнопку

ускорения на системе круиз-контроля

автомобиля

и автомобиль в

дан-

ный момент

двигается,

то система увеличит скорость автомобиля,

противном случае команда игнорируется. Для спецификации

требова-

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

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

Однако условие легко пропустить, в результате чего пропускается и

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

спецификации вручную.

Таблицы решений и деревья

решений—

это два альтернативных

приема для представления того, что система должна делать, когда в

игру вступают сложные логика и решения (Davis,

1993).

В таблице

ре-

шений (decision table) перечислены различные значения для всех фак-

торов, влияющих на поведение

системы,

и приведены ожидаемые

действия системы в ответ на каждую комбинацию факторов. Факторы

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

true и false, либо как вопросы с возможными ответами «да» или «нет»

Естественно, вы также можете использовать таблицы решений с

фак-

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

Ловушка Не нужно создавать и таблицу решений, и дерево решений, чтобы по-

казать один и тот же фрагмент информации; вполне достаточно одного из них.

В табл.

11-2

показана таблица решений с

логикой,

управляющей

принятием или отклонением запроса нового химиката Chemical

Track

ing System. На решение влияет четыре фактора:

авторизирован ли пользователь, создающий запрос;

1 имеется ли химикат в наличии на складе или у поставщика;

I включен ли химикат в список опасных химикатов, для работы с

кото

рыми

необходима специальная подготовка;

1 есть ли у

пользователя,

создающего запрос, соответствующая

под-

готовка для работы с этим типом опасного вещества.

Каждый из этих четырех факторов имеет два возможных условия,

true или false. В принципе это увеличивает на

или 16 различные ком-

бинации true/false для

вероятных отдельных функциональных

требо-

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

Глаеа

11.

Любое изображение стоит 1024 слов 229

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

запроса химикатов, то система не примет запрос, и таким образом ос-

тальные условия несущественны

{показаны

прочерками в таблице ре-

шений). Таблица показывает, что результат различных логических

комбинаций — лишь пять отдельных функциональных требований.

Таблица

-2. Пример таблицы решений

для

Chemical Tracking System

Номер

требования

Условие

Пользователь авторизован

Химикат есть в наличии

Химикат считается опасным

Сотрудник, разместивший заказ на хими-

кат, прошел соответствующую подготовку

Действие

Принять

запрос

Отклонить запрос

false

true

tnji

true

:'•'

false

true true

false true

x x

Рис.

11-7.

Пример дерева решений для Chemical Tracking System

На рис.

11-7

показано дерево решений, представляющее ту же ло-

гику. Пять прямоугольников обозначают пять возможных результатов

принятия или отклонения запроса на химикат. Таблицы решений и

де-

ревья

решений—

это хорошие способы документации требований

230

Часть II. Разработка требований к ПО

(или бизнес-правил), позволяющие не пропустить ни одну комбина-

цию условий. Даже сложная таблица или дерево решений более про-

сты для чтения, чем повторяющиеся требования в текстовом виде.

Последнее напоминание

У каждого приема моделирования, описанного в этой книге, есть и

свои

преимущества,

и свои ограничения. Эти приемы позволяют

представить одни и те же области, поэтому вам не надо создавать для

своего проекта все типы диаграмм. Например, если вы создаете диа-

грамму «сущность — связь» и словарь данных, не стоит рисовать диа-

грамму классов (или наоборот). Помните, что вы создаете модели ана-

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

взаимодействия, чем тот, что дает текстовая спецификация

требова-

ний к ПО или любое другое представление требований. Старайтесь не

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

иногда случаются в мире методов и моделей разработки ПО. Вместе

этого, используйте все доступные средства для того, чтобы как

можнс

лучше объяснить требования к вашей системе,

Что теперь?

I Опробуйте на практике приемы

моделирования,

описанные в этой главе, задоку-

ментировав разработку существующей системы.

Например,

нарисуйте карту ди-

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

1 Определите часть спецификации требований к ПО, трудную для восприятия, или

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

которая подходит для представления этой части требований. Нарисуйте модель

и оцените, помогла бы она решить проблему, создай вы ее раньше,

1 В следующий раз, когда вам понадобится задокументировать определенные тре-

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

ние. Сделайте набросок модели на бумаге или доске один или два раза, чтобы

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

ментами автоматизированного проектирования ПО, которые поддерживают ус-

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

Глава 11. Любое изображение стоит

1024

слов 231

Обратная сторона

функциональности:

атрибуты

качества ПО

«Привет, Фил, это снова Мария. У меня вопрос о новой слу-

жебной

системе,

которой вы сейчас занимаетесь. Как вы

знаете, эта система работает на нашем мэйнфрейме и каж-

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

ковое пространство и загрузку процессора. Похоже, что в но-

вой системе файлы занимают в два раза больше места на

диске, чем в старой. Что еще хуже, загрузка процессора за

сессию в три раза выше, чем обычно. Вы можете

объяснить

мне, что происходит?"

«Конечно, Мария. Вспомните, вы хотели, чтобы в этой системе

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

дущей, поэтому, естественно, база данных стала значительно

больше. Следовательно, ваша ежемесячная плата за

исполь-

зование дискового пространства выросла. Кроме того, вы и

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

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

этот замечательный графический интерфейс. Однако при

этом процессору требуется намного больше компьютерной

мощности, чем в предыдущей системе с текстовым режимом

отображения. Вот почему так возросла загрузка процессора.

Но ведь с новой системой намного удобнее работать, не так

ли?»

«Так-то оно так,

но

и представить себе не могла, что ее рабо-

та будет обходиться так дорого. У меня из-за этого могут быть

неприятности. Мой менеджер нервничает. При таких условиях

он уже в апреле израсходует годовой

бюджет,

выделенный от-

делу на компьютерные нужды. Не могли бы вы исправить сис-

тему, чтобы снизить стоимость ее работы?»

232 Часть II. Разработка требований к ПО

Фил расстроился. «Ничего исправлять не нужно. Новая

систе-

ма учета сотрудников — это именно то, что вы заказывали. Я

предполагал, вы отдаете себе отчет

том, что если вы

храните

больше данных или больше работаете на компьютере, то ваши

затраты вырастут. Возможно, нам следовало обсудить это

раньше, поскольку сейчас уже практически ничего не удастся

сделать. Мне очень жаль».

Естественно, что пользователей, как правило, интересуют

функцио-

нальные, или

поведенческие,

требования — то есть возможности, пре-

доставляемые

ПО, однако для успеха ПО недостаточно правильно

pea

лизовать соответствующую функциональность. Кроме того,

пользова-

телей волнует, насколько хорошо новая система будет работать. К

характеристикам, описывающим это свойство системы,

относятся

легкость

использования,

быстрота запуска, количество сбоев и

обра

ботка неожиданных ситуаций. В целом они называются атрибутами

ка

чества ПО или факторами качества и считаются частью

нефункцио-

нальных

(или неповеденческих) требований к системе.

Довольно трудно дать определение атрибутам качества,

однако

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

ожидалось, от продукта, который вызывает у клиентов восхищение.

По

мнению Роберта Шаррета

{Robert

Charette, 1990), «В реальных

систе-

мах успех или неудачу проекта часто определяют именно

нефункцио

нальные требования, а не функциональные». В отличном ПО выдержан

оптимальный баланс конкурирующих характеристик качества. Если в

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

выясните

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

ее

ли продукт их удовлетворит. Но, как правило, более частый исход —

разочарованные пользователи и расстроенные разработчики.

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

важные:

решения,

касающиеся архитектуры и дизайна; примером может

слу-

жить распределение системных функций по различным компьютерам

для достижения

целей,

связанных с производительностью или целост

ностью. Гораздо труднее и дороже перестраивать систему, чем

спла

нировать необходимые параметры с самого начала.

Клиенты, как правило, высказывают свои ожидания о качестве про

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

выяс

нить основное. Хитрость заключается в том, чтобы уловить, что же сто

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

об

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

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

Глава 12. Обратная сторона функциональности: атрибуты качества ПО

23JI

кто создает, тестирует и поддерживает ПО. Вопросы, с помощью кото-

рых выясняются невысказанные ожидания клиентов, позволяют уста-

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

ботчикам создать отличный продукт.

Атрибуты качества

К атрибутам качества можно отнести несколько дюжин характеристик

продукта

(Charette,

1990),

хотя для большинства проектов хватило бы

всего нескольких. Если разработчикам известно, какие характеристи-

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

вующие приемы, работая над архитектурой, дизайном и программным

наполнением ПО, которые позволят достичь определенного качества

(Glass,

1992;

DeGrace и

Stahl,

1993).

Для классификации атрибутов ка-

чества применяются различные схемы

(Boehm,

Brown и Lipow, 1976;

Cavano и

McCall,

1978; IEEE 1992; DeGrace и Stahi, 1993). Один из спо-

собов классификации основан на разделении характеристик, которые

проявляются в период выполнения, и тех, что не проявляются

(Bass,

Clements и Kazman,

1998).

Согласно другому способу разделяются

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

лей, от скрытых качеств, которые имеют значение

для

службы техниче-

ской поддержки. Последние косвенно влияют на мнение клиента, так

как упрощают возможные изменения

продукта,

его корректировку,

проверку и переход на другие платформы.

В табл. 12-1 перечислено несколько атрибутов качества обеих кате-

горий, которые необходимо принимать во внимание в любом проекте.

Некоторые много значат для встроенных систем (эффективность и на-

дежность), тогда как другие особенно важны для Интернет-приложе-

ний и приложений для мэйнфреймов (доступность, целостность и лег-

кость в эксплуатации) или для настольных систем (способность к взаи-

модействию и удобство и простота использования). Для встроенных

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

мер безопасность (о которой рассказывалось в главе 10), легкость и

простота установки и обслуживания. Для Интернет-приложений также

важен еще один атрибут — масштабируемость.

В идеальном мире каждая система имела бы максимально возмож-

ные значения всех этих атрибутов. Она была бы постоянно доступна и

интуитивно понятна, не испытывала бы никаких сбоев, моментально

предоставляла бы результаты, естественно, всегда корректные. По-

скольку все перечисленное —

утопия,

советую вам выяснить с помо-

234 Часть II. Разработка требований к ПО