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

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

1996). Если диаграмма «сущность —

связь»

представляет логические

группы информации предметной

области

и их взаимосвязи, вы ис-

пользуете диаграмму

«сущность

—

связь»

в качестве инструмента

ана-

лиза

требований.

Анализ диаграммы "сущность — связь»

помогает

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

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

наоборот, когда вы создаете эту диаграмму в ходе разработки

систе-

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

ных системы.

Объектами

(entities)

называются физические элементы (включая

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

анализ

которого

вы

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

планируете

создать

(Robertson

и Robertson, 1994). Объекты называются посредст-

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

прямо-

угольниках на диаграмме «сущность — связь». На Рис.

11-2

показана

часть диаграммы

«сущность

— связь» для Chemical Tracking System с

использованием одной из нескольких применяемых для диаграмм

та-

кого типа систем обозначений. Обратите

внимание,

что объекты За-

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

диаграмме потока данных на рис. 11-1

показаны

виде

хранилищ

дан-

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

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

зические элементы,

являющиеся

частью деловых операций (Контей-

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

уровни

диаграммы потока

данных,

но показаны на ее более низком

уровне

(История контейнера, Химикат),

Каждый объект

описывается

несколькими атрибутами; у отдельных

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

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

иден-

тификатор, строгое название химиката и графическое

представление

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

определения этих атрибутов — это гарантирует, что объекты на

диа-

грамме "Сущность — связь» и соответствующие им хранилища данных

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

Ромбы на диаграмме «сущность —

связь»

обозначают

взаимоотно-

шения (relationships), показывающие логические и числовую связь пар

объектов. Названия взаимоотношениям даются в соответствии с при-

родой соединений. Например, взаимоотношения между элементами

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

химиклта»

определяются как размещение. Вы можете прочитать это взаимоотно-

шения как «Сотрудник размещает Запрос на химикат» или как

«Запоос

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

1215

на химикат размещен Сотрудником». Согласно некоторым правилам,

фигуру в форме ромба следует назвать «размещен

тем-то»,

что имеет

смысл, только если читать диаграмму слева направо. Когда вы покаже-

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

все ли взаимоотношения показаны корректно и соответствующим об-

разом. Также попросите их определите все возможные взаимоотно-

шения с объектами, которые не показаны на модели.

Сотрудник,

разместив-

ший заказ

на

химиш

Рис.

-2. Часть диаграммы «сущность - связь» для Chemical Tracking System

Количество

элементов (cardinality) каждого взаимоотношения, или

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

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

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

элементов; условные обозначения на рис.

11-2

используются наиболее

часто. Поскольку каждый Сотрудник,

разместивший

заказ на химикат,

может разместить несколько запросов, то между элементами «Сотруд-

ник, разместивший заказ на химикат», и «Запрос химиката» существует

связь «один ко многим». Количество элементов показано цифрой 1 на

линии, соединяющей элемент «Сотрудник, разместивший заказ на хи-

микат», и взаимоотношение «размещение», и буквой

(много) на ли-

216

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

нии, соединяющей элемент «Запрос химиката» и взаимоотношение

«размещение».

Ниже перечислены другие возможные

случаи:

I один к одному

(каждый

контейнер с химикатом отслеживается в од-

ной Истории контейнера);

I многие ко многим (в каждом каталоге поставщика содержится мно-

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

ких Каталогах

поставщика}.

Если вам известно более точное количество элементов, чем просто

много, вы можете указать вместо общего

конкретное число или диа-

пазон.

Моделирование

проблем, а не ПО

Как-то я в качестве представителя специалистов по ИТ работал в команде, которая

занималась модернизацией бизнес-процессов. Наша задача заключалась в снижении

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

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

дующих подразделений

компании,

задействованных в коммерциализации химиката:

химиков-синтетиков, которые создали новое вещество;

химиков-технологов, разрабатывающих процесс промышленного производства

вещества;

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

I патентных поверенных, которые занимаются патентной защитой изобретения;

1 специалистов отдела охраны труда и здоровья, получающих разрешение прави-

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

После того как мы

разработали

новый

процесс,

который по нашему мнению должен

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

нов команды, ответственных за каждый этап процесса. Я задал каждому два вопро-

са:

«Какая

информация вам нужна для выполнения этого этапа?» и «Какую информа-

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

сохранить?».

Собрав и сравнив ответы, я выявил те этапы, информацию для которых не постав-

лял никто, а также этапы, выходная информация

которых

не была нужна никому. Мы

разрешили эти проблемы,

Затем я

нарисовал

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

про-

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

моделиро-

вания взаимоотношений данных. Все наши элементы данных были определены

Е:

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

взаимодей-

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

про

цесса.

Кроме

того,

модели

представляют

собой прекрасную точку отсчета для раз

работки требований для приложений и определения их границ.

Глава

11.

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

1024

слов 217

Диаграмма перехода состояний

Для любых систем ПО необходимо учитывать комбинацию функцио-

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

состояния. Состояний, в которых в каждый момент времени могут на-

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

процессами,

немного. Изменение состояния происходит, только когда

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

определенного сигнала на входе при определенных условиях. Приме-

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

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

сигналами для пешеходного перехода. Многие информационные сис-

темы имеют

дело

бизнес-обьектами

—заказы

на покупку, счета-фак-

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

которых возможно несколько различных состояний. Элементы систе-

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

ются механизмами с конечным числом состояний (finite-state machi-

nes) (Booch,

Rumbaugh,

Jacobson, 1999).

При описании сложного механизма с конечным числом состояний

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

решенное изменение состояния или появления запрещенного изме-

нения. В зависимости от структуры спецификации требований к ПО,

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

быть в ней разобщены. В этом случае весьма трудно понять поведение

системы.

Диаграмма перехода состояний

(state-transition

diagram) позволяет

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

ным числом состояний. Связанный с этой моделью прием

—диаграм-

ма состояния — включен в обладающий в некотором смысле более бо-

гатым набором условных обозначений унифицированный язык моде-

лирования (Unified Modeling Language,

UML),

который моделирует

состояния объекта в течение его жизненного цикла (Booch,

Rumbaugh,

Jacobson, 1999). Диаграмма перехода состояний содержит три типа

элементов:

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

разрешенные состояния, или транзакции (transitions), — показаны в

виде стрелок, соединяющих пары прямоугольников;

1 события или условия, вызывающие каждую транзакцию, — показа-

ны в виде текстовых пояснений для каждой стрелки перехода. Текст

может пояснять и событие, и соответствующую реакцию системы,

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

На рис.

11-3

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

машней системы безопасности. В диаграмме перехода состояний для

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

обыч-

но называемое Ожидание (эквивалентно состоянию Отключено на

ри-

сунке), в которое система возвращается, когда она не

занята

другими

процессами. В отличие от этого, диаграмма перехода состояний для

объекта, имеющего определенный жизненный цикл, например Запрос

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

означа-

ют финальные значения состояния объекта.

изменение параметров

войти в автомати-

ческий

режим

датчики отключены,

установить режим

Отключено

выйти

из

автомати-

ческого

режима

Включен

реиш

отсутствия

хозяев

отсутствия хозяев в доме

в течение 30 секунд

ввести правильный код

обнаружено

движение

введен неправильный код

правильный код

не введен в течение 30 секунд

звонок

в полицию

обнаружен

дым,

звонок

противопожарную

службу

Обнаружен дым, звонок

в противопожарную

службу

Рис.

-3. Часть диаграммы перехода состояний для домашней системы безопасности

На диаграмме перехода состояний не показаны детали

процессов,

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

возникающие в результате этих процессов. Диаграмма перехода со-

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

системы. Это хороший метод проверки того, все ли необходимые

состояния и переходы состояний корректно и полно описаны в функ-

циональных требованиях.

Тестировщики

могут вывести варианты тес-

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

Глава

11.

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

1024

слов

219

включены все допустимые пути переходов. Клиентам, как правило,

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

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

прочитать диаграмму перехода состояний.

Вспомните из главы 8, что основная функция Chemical Tracking

System — позволить действующим лицам, которые названы «Сотруд-

ники, разместившие заказ на химикат», разместить запрос химиката,

который может быть выполнен либо складскими работниками (если

химикат есть на

складе),

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

надо отправить запрос). Каждый запрос проходит через несколько со-

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

бо отмены (два конечных состояния). Таким образом, мы можем

обра-

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

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

-4.

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

прос может находиться в одном из следующих семи состояний:

I В подготовке. Сотрудник создает новый запрос, инициировав эту

функцию из другой части системы;

1 Отложен. Сотрудник сохраняет часть запроса для выполнения

его

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

проса;

1 Принят. Пользователь отправляет законченный запрос

химиката,

система принимает его к исполнению;

Размещен. Запрос должен быть удовлетворен сторонним постав-

щиком, покупатель размещает заказ у продавца;

1 Выполнен. Запрос удовлетворен: контейнер с химикатом постав-

лен либо со склада химикатов, либо от поставщика;

1 Заказ ожидает

выполнения.

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

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

поставки;

Отменен. Сотрудник отменил принятый системой заказ до того,

как тот был выполнен, или покупатель отменил заказ у продавца, до

того как тот был выполнен или пока он был отложен.

Когда представители пользователей Chemical Tracking System про-

смотрели диаграмму перехода состояний для запроса химиката, они

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

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

ответствующих функциональных требований эти ошибки никто из них

не заметил. В этом и заключается важность представления информа-

ции о требованиях на нескольких уровнях абстракции. Зачастую про-

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

блему

легче обнаружить, если идти назад от наиболее детализирован-

ного уровня и рассматривать большую картину, которую обеспечивают

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

вень деталей, достаточный разработчику для создания ПО.

Следова-

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

Chemical

Tracking Sys-

tem были включены функциональные требования, связанные с

обра-

боткой запроса химиката и возможными изменениями его состояния,

I t

пользователь создает

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

отменяет

новый

запрос

новый

запрос

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

сохраняет

незаконченный запрос

пользователь вызывает

незаконченный запрос

Отложен

система принимает

действительный

запрос

выполняется

на складе

химикат

получен

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

сотрудник,

разместивший

заказ

на химикат, отменяет запрос

покупатель размещает

заказ

поставщика

покупатель отменяет

заказ у

поставщика

поставщик помешает заказ

на

химикат

в невыполненные

заказы

Рис.

-4. Диаграмма перехода состояний для запроса химиката

a Chemical Tracking System

Глава

11,

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

1024

слов

Карта диалогов

Пользовательский интерфейс также можно рассматривать как меха-

низм с конечным числом состояний. Только один элемент диалога (та-

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

или дисплей сенсорного

экрана)

доступен в определенный момент

времени для ввода информации пользователем. Пользователь может

перейти к другим определенным элементам диалога,

связанным

действием, которые он

выполняет

в активной области ввода. Количе-

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

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

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

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

ния, которая называется карта диалогов (dialog

map)

(Wasserman,

1985;

Wiegers, 1996a).

Constantine

Lockwood

(1999)

описывают похо-

жий прием — карту перемещений (navigation map), которую отличает

более богатый набор условных обозначений для представления раз-

личных типов элементов взаимодействия и контекстных переходов.

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

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

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

рана. Карта диалогов позволяет рассмотреть возможные

концепции

пользовательского интерфейса с учетом вашего понимания требова-

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

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

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

гов также полезны при моделировании визуальной архитектуры Web-

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

Web-сайт, на

картах диалогов изображаются в виде переходов. Карты диалогов свя-

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

но краткое описание назначения каждого экрана

(Leffingwell

и Widrig,

2000).

Карты диалогов отражают сущность взаимодействий системы

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

работу команды деталей макета экрана. С помощью такой карты поль-

зователи могут отследить отсутствующие, неправильные или ненуж-

ные переходы и, следовательно, отсутствующие, неправильные или

ненужные требования. Абстрактная концептуальная карта диалогов,

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

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

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

Также,

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

гов показывает каждый элемент диалога как состояние

(прямоуголь-

ник) и каждую допустимую возможность перемещения как переход

(стрелка). Условие, инициирующее перемещение по пользовательско -

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

да. Существует несколько типов инициализирующих условий:

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

клави-

ши или щелчок гиперссылки или кнопки диалогового окна;

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

тате чего появляется сообщение об ошибке;

I системное условие, например отсутствие бумаги в принтере;

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

номе-

ра элемента меню и нажатие клавиши Enter,

Карты диалогов слегка напоминают диаграммы потоков, но у них

другое назначение. Диаграммы потока ясно показывают этапы

про-

цесса и точки принятия решений, но не пользовательский

интерфейс.

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

няющийся по линиям перехода, которые соединяют один элемент

дил-

лога с другим. Выполнение решения (обычно это выбор

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

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

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

другой экран, описаны над стрелками переходов. Вы можете

считать

карту диалогов как противоположность — или дополнение — диаграм-

мы потока.

Чтобы упростить карту диалогов, пропустите глобальные функции,

такие, как нажатие клавиши F1 для вызова справки для каждого диало-

гового элемента. В разделе спецификации требований к ПО, посвя-

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

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

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

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

Web-сайта не нужно включать стандартные для каждой страницы

ссы

п-

ки перемещения. Вы также можете опустить транзакции, реализую-

щие последовательность перемещений по Web-странице

обратном

направлении,

которые запускаются кнопкой Back Web-браузера.

Карта диалогов — это прекрасный способ представить взаимодей-

ствия действующего лица и системы, описываемые вариантом ис-

пользования. Карта диалогов позволяет отобразить

альтернативные

направления в виде ответвлений от нормального

направления.

Я обна-

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

особенно полезны на семинарах по сбору информации,

касающейся

Глава

11.

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

вариантов

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

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

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

дачи.

В главе 8 описан вариант использования Chemical Tracking System

под названием «Запрос химиката». Нормальное направление развития

этого

варианта

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

микатом со склада. Альтернативное направление — запрос химиката у

поставщика. Пользователь, размещающий запрос, хотел бы иметь воз-

можность просматривать историю доступных контейнеров с этим хи-

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

-5 показана карта

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

На первый взгляд эта диаграмма может показаться довольно запу-

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

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

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

меню

Chemical

Tracking System. В карте

диалогов

это действие пользо-

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

ленной к прямоугольнику с названием «Список текущих запросов».

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

такого варианта использования, те, список химикатов в текущем за-

просе пользователя. Стрелки, исходящие из этого прямоугольника на

карте диалогов показывают все возможные перемещения —

и,

следо-

вательно, функциональность — доступные пользователю:

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

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

один химикат;

I добавить новый химикат к запросу;

I удалить химикат из списка.

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

еще элемент диалога, при этом просто обновляется список текущих

запросов после

того,

как пользователь вносит

изменения.

По мере перемещения по этой карте диалогов вы увидите элемен-

ты, отражающие остальные элементы варианта использования «За-

прос химиката»:

I один

путь

для

запроса

химиката у поставщика;

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

еще один возможный путь — просмотр истории контейнера, храня-

щегося на складе химикатов;

I отображение сообщения об ошибке для обработки ввода непра-

вильного ID химиката или других возможных ошибочных условий.

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