Для любых систем ПО необходимо учитывать комбинацию функционального поведения, особенности управления данными и изменения состояния. Состояний, в которых в каждый момент времени могут находиться системы реального времени и приложения, управляющие процессами, немного. Изменение состояния происходит, только когда удовлетворяются четко определенные критерии, такие, как получение определенного сигнала на входе при определенных условиях. Примером может служить перекресток магистрали с установленными датчиками движения, защищенной полосой поворота, а также разметкой и сигналами для пешеходного перехода. Многие информационные системы имеют дело с бизнес-объектами такими как заказ на покупку, счета-фактуры, товарно-материальные ценности и т.п., для жизненных циклов которых возможно несколько различных состояний. Элементы системы, для которых возможен набор состояний и их изменение, называются механизмами с конечным числом состояний (finite-state machines) (Booch, Rumbaugh, Jacobson, 1999).
При описании сложного механизма с конечным числом состояний на естественном языке высока вероятность упустить из внимания разрешенное изменение состояния или появления запрещенного изменения. В зависимости от структуры спецификации требований к ПО, требования, относящиеся к поведению состояния механизма, могут быть в ней разобщены. В этом случае весьма трудно понять поведение системы.
Диаграмма перехода состояний (state-transition diagram) позволяет получить точное, полное и ясное представление о механизме с конечным числом состояний. Связанный с этой моделью прием — диаграмма состояния — включен в обладающий в некотором смысле более богатым набором условных обозначений унифицированный язык моделирования (Unified Modeling Language, UML), который моделирует состояния объекта в течение его жизненного цикла (Booch, Rumbaugh, Jacobson, 1999). Диаграмма перехода состояний содержит три типа элементов:
· возможные состояния системы — показаны в виде прямоугольников;
· разрешенные состоянием переходы (transitions), — показаны в виде стрелок, соединяющих пары прямоугольников;
· события или условия, вызывающие каждый переход, — показаны в виде текстовых пояснений для каждой стрелки перехода. Текст может пояснять и событие, и соответствующую реакцию системы.
На рис. 11-3 показана часть диаграммы перехода состояний для домашней системы безопасности. В диаграмме перехода состояний для системы реального времени предусмотрено особое состояние, обычно называемое Ожидание (эквивалентно состоянию Отключено на рисунке), в которое система возвращается, когда она не занята другими процессами. В отличие от этого, диаграмма перехода состояний для объекта, имеющего определенный жизненный цикл, например Запрос химиката, имеет одно или более конечных состояний, которые означают финальные значения состояния объекта.
Рис. 11-3. Часть диаграммы перехода состояний для домашней системы безопасности
На диаграмме перехода состояний не показаны детали процессов, выполняемых системой, а только возможные изменения состояний, возникающие в результате этих процессов. Диаграмма перехода состояний помогает разработчику понять предполагаемое поведение системы. Это хороший метод проверки того, все ли необходимые состояния и переходы состояний корректно и полно описаны в функциональных требованиях. Тестировщики могут вывести варианты тестирования на основании диаграммы перехода состояний, в которую включены все допустимые пути переходов. Клиентам, как правило, хватает незначительных пояснений, касающихся принятой системы обозначений, — что означают прямоугольники и стрелки, — чтобы прочитать диаграмму перехода состояний.
Вспомните из главы 8, что основная функция Chemical Tracking System — позволить действующим лицам, которые названы «Сотрудники, разместившие заказ на химикат», разместить запрос химиката, который может быть выполнен либо складскими работниками (если химикат есть на складе), либо сторонним поставщиком (для этого ему надо отправить запрос). Каждый запрос проходит через несколько состояний с момента его создания до момента либо его выполнения, либо отмены (два конечных состояния). Таким образом, мы можем обрабатывать жизненный цикл запроса химиката как механизм с конечным числом состояний и моделировать его так, как показано на рис. 11-4.
Эта диаграмма перехода состояний показывает, что отдельный запрос может находиться в одном из следующих семи состояний:
· В подготовке. Сотрудник создает новый запрос, инициировав эту функцию из другой части системы;
· Отложен. Сотрудник сохраняет часть запроса для выполнения его в будущем, не передавая его в систему и не отменяя операцию запроса;
· Принят. Пользователь отправляет законченный запрос химиката, и система принимает его к исполнению;
· Размещен. Запрос должен быть удовлетворен сторонним поставщиком, покупатель размещает заказ у продавца;
· Выполнен. Запрос удовлетворен: контейнер с химикатом поставлен либо со склада химикатов, либо от поставщика;
· Заказ ожидает выполнения. У продавца не оказалось химиката в наличии, и он уведомил покупателя, что заказ отложен для будущей поставки;
· Отменен. Сотрудник отменил принятый системой заказ до того, как тот был выполнен, или покупатель отменил заказ у продавца, до того как тот был выполнен или пока он был отложен.
Когда представители пользователей Chemical Tracking System просмотрели диаграмму перехода состояний для запроса химиката, они определили, что одно состояние не нужно, другое важное состояние отсутствует, и указали два неправильных перехода. При изучении соответствующих функциональных требований эти ошибки никто из них не заметил. В этом и заключается важность представления информации о требованиях на нескольких уровнях абстракции. Зачастую проблему легче обнаружить, если идти назад от наиболее детализированного уровня и рассматривать большую картину, которую обеспечивают модели анализа. Однако диаграмма перехода состояний не дает уровень деталей, достаточный разработчику для создания ПО. Следовательно, в спецификацию требований к ПО для Chemical Tracking System были включены функциональные требования, связанные с обработкой запроса химиката и возможными изменениями его состояния.
Рис. 11 -4. Диаграмма перехода состояний для запроса химиката для Chemical Tracking System
Карта диалогов
Пользовательский интерфейс также можно рассматривать как механизм с конечным числом состояний. Только один элемент диалога (такой, как меню, рабочая область, диалоговое окно, командная строка или дисплей сенсорного экрана) доступен в определенный момент времени для ввода информации пользователем. Пользователь может перейти к другим определенным элементам диалога, связанным с действием, которые он выполняет в активной области ввода. Количество возможных путей навигации в сложном графическом интерфейсе велико, однако оно конечно и, как правило, все возможности известны. Следовательно, множество пользовательских интерфейсов можно моделировать, применяя одну из форм диаграммы перехода состояния, которая называется карта диалогов (dialog map); (Wasserman, 1985; Wiegers, 1996a). Constantine и Lockwood (1999) описывают похожий прием — карту перемещений (navigation map), которую отличает более богатый набор условных обозначений для представления различных типов элементов взаимодействия и контекстных переходов.
Карта диалогов представляет дизайн пользовательского интерфейса на высоком уровне абстракции. На ней показаны элементы диалога в системе и навигация между ними, но не показан подробный вид экрана. Карта диалогов позволяет рассмотреть возможные концепции пользовательского интерфейса с учетом вашего понимания требований. Пользователям и разработчикам стоит изучить карту диалогов, чтобы выработать общее представление того, как пользователь может взаимодействовать с системой для выполнения задачи. Карты диалогов также полезны при моделировании визуальной архитектуры Web-сайта. Ссылки для перемещений, которые вы включаете Web-сайт, на картах диалогов изображаются в виде переходов. Карты диалогов связаны с архивными системными документами, в которые также включено краткое описание назначения каждого экрана (Leffingwell и Widrig, 2000).
Карты диалогов отражают сущность взаимодействий системы и пользователя и основные моменты решения задачи, без тормозящих работу команды деталей макета экрана. С помощью такой карты пользователи могут отследить отсутствующие, неправильные или ненужные переходы и, следовательно, отсутствующие, неправильные или ненужные требования. Абстрактная концептуальная карта диалогов, разработанная в ходе анализа требований, становится руководством для подробной разработки пользовательского интерфейса.
Также как и обычные диаграммы перехода состояния, карта диалогов показывает каждый элемент диалога как состояние (прямоугольник) и каждую допустимую возможность перемещения как переход (стрелка). Условие, инициирующее перемещение по пользовательскому интерфейсу, показано в виде текстового ярлыка на стрелке перехода. Существует несколько типов инициализирующих условий:
· действие пользователя, например нажатие функциональной клавиши или щелчок гиперссылки или кнопки диалогового окна;
· значение данных, такое, как недостоверная информация, в результате чего появляется сообщение об ошибке;
· системное условие, например отсутствие бумаги в принтере;
· некоторые комбинации вышеперечисленных, например ввод номера элемента меню и нажатие клавиши Enter,
Карты диалогов слегка напоминают диаграммы потоков, но у них другое назначение. Диаграммы потока ясно показывают этапы процесса и точки принятия решений, но не пользовательский интерфейс. В отличие от них, на карте диалогов не отображается процесс, выполняющийся по линиям перехода, которые соединяют один элемент диалога с другим. Выполнение решения (обычно это выбор пользователи) скрыто за экранами, которые показаны на карте диалогов в виде прямоугольников, а условия, в результате которых отображается тот или другой экран, описаны над стрелками переходов. Вы можете считать карту диалогов как противоположность — или дополнение — диаграммы потока.
Чтобы упростить карту диалогов, пропустите глобальные функции, такие, как нажатие клавиши F1 для вызова справки для каждого диалогового элемента. В разделе спецификации требований к ПО, посвященному пользовательскому интерфейсу, должно быть указано, что эта функциональность будет доступна, но демонстрация множества экранов справки на карте диалогов вносит в модель беспорядок при незначительных преимуществах. Точно так же при моделировании Web-сайта не нужно включать стандартные для каждой страницы ссыпки перемещения. Вы также можете опустить транзакции, реализующие последовательность перемещений по Web-странице в обратном направлении, которые запускаются кнопкой Back Web-браузера.
Карта диалогов — это прекрасный способ представить взаимодействия действующего лица и системы, описываемые вариантом использования. Карта диалогов позволяет отобразить альтернативные направления в виде ответвлений от нормального направления. Я обнаружил, что наброски фрагментов карты диалогов на доске оказались особенно полезны на семинарах по сбору информации, касающейся вариантов использования, когда участники изучали последовательность действий пользователя и реакций системы при выполнении задачи.
В главе 8 описан вариант использования Chemical Tracking System под названием «Запрос химиката». Нормальное направление развития этого варианта использования подразумевает запрос контейнера с химикатом со склада. Альтернативное направление — запрос химиката у поставщика. Пользователь, размещающий запрос, хотел бы иметь возможность просматривать историю доступных контейнеров с этим химикатом, прежде чем выбрать один из них. На рис. 11-5 показана карта диалогов для этого несколько сложного варианта использования,
На первый взгляд эта диаграмма может показаться довольно запутанной, но в ней довольно легко разобраться, если попробовать за один раз отследить один прямоугольник и одну линию. Пользователь инициирует этот вариант использования, размещая заказ химиката из меню Chemical Tracking System. В карте диалогов это действие пользователя, обозначенное стрелкой в верхней левой части карты, направленной к прямоугольнику с названием «Список текущих запросов». Прямоугольник представляет основное рабочее пространство для этого варианта использования — список химикатов в текущем запросе пользователя. Стрелки, исходящие из этого прямоугольника на карте диалогов показывают все возможные перемещения — и, следовательно, функциональность — доступные пользователю:
· отменить весь запрос;
· передать к исполнению запрос, если в нем содержится хотя бы один химикат;
· добавить новый химикат к запросу;
· удалить химикат из списка.
В последней операции, удалении химиката, не участвует какой-либо еще элемент диалога, при этом просто обновляется список текущих запросов после того, как пользователь вносит изменения.
По мере перемещения по этой карте диалогов вы увидите элементы, отражающие остальные элементы варианта использования «Запрос химиката»:
· один путь для запроса химиката у поставщика;
· другой путь для выполнения запроса через склад химикатов;
· еще один возможный путь — просмотр истории контейнера, хранящегося на складе химикатов;
Рис. 11-5. Карта диалогов для варианта использования «Запрос химиката» в системе Chemical Tracking System
Некоторые переходы на карте диалогов позволяют пользователю откатить операцию. Пользователей раздражает, если они уже передумали, а им все-таки приходится завершать задачу. Карты диалогов позволяют облегчить и упростить работу, предлагая функции отката и отмены в стратегических точках.
Пользователь, изучающий карту диалогов, может обнаружить недостающее требование. Например, осторожный пользователь может захотеть подтвердить операцию, которая отменяет весь запрос, чтобы избежать непроизвольной потери данных. Дешевле добавить такую функцию на этапе анализа, чем встраивать ее в уже законченный продукт, Поскольку карта диалогов представляет концептуальные элементы, участвующие во взаимодействии пользователя и системы, не пытайтесь зафиксировать все детали пользовательского интерфейса на этапе работы над требованиями. Лучшее применение этих моделей — помочь всем, кто заинтересован в проекте, выработать общее понимание предполагаемой функциональности системы.
Диаграмма классов
Объектно-ориентированная разработка ПО вытеснила структурный анализ и разработку, породив объектно-ориентированные анализ и разработку. Как правило, в предметной или рабочей области объекты (objects) соотносятся с объектами реального мира. Они представляют отдельные экземпляры, выведенные из родового шаблона, который называется класс (class). В описания классов входят атрибуты (данные) и действия, которые можно выполнять с этими атрибутами. Диаграмма классов (class diagram) — это графический способ отобразить классы, идентифицированные в ходе объектно-ориентированного анализа, и взаимоотношений между ними.
Для продуктов, разработанных с помощью объектно-ориентированных методов, не требуются уникальные приемы разработки требований. Дело в том, что требования отражают то, что пользователям необходимо сделать с помощью системы, и особенности предполагаемой функциональности, а не то, как она будет создана. Пользователям не придется вникать в объекты и классы. Однако если вы собираетесь разрабатывать систему с помощью объектно-ориентированных приемов, то анализ требований стоит начать с определения классов доменов, их атрибутов и поведения. Это упростит переход от анализа к проектированию, так как проектировщик сопоставляет объекты предметной области с системными объектами и детализирует атрибуты и операции каждого класса.
Стандартным языком объектно-ориентированного моделирования является унифицированный язык моделирования (Unified Modeling Language, UML) (Booch, Rumbaugh и Jacobson, 1999). На уровне абстракции, который годится для анализа требований, вы можете использовать систему обозначений UML в диаграмме классов, как показано на рис. 11-6 для части — вы правильно угадали — Chemical Trackinq System. Дизайнер переработает эти концептуальные диаграммы классов, не зависящие от особенностей реализации, в более подробные диаграммы классов для объектно-ориентированного проектирования и реализации. Взаимодействия классов и сообщения, которыми они обмениваются, демонстрируют диаграммы последовательностей и диаграммы сотрудничества, подробно о которых рассказано в Booch, Rumbaugh; Jacobson(1999) и Lauesen (2002).
На рис. 11-6 показано 4 класса — каждый в большом прямоугольнике: «Сотрудник, разместивший заказ на химикат», «Каталог поставщика», «Запрос химиката» и «Элемент строки запроса». Вы видите, что информация на этой диаграмме классов и данные на другой модели анализа, из тех, что показаны в этой главе, похожи (неудивительно — везде обсуждается одна и та же проблема). Сотрудник, разместивший заказ на химикат, показан на диаграмме «сущность-связь» на рис.11-2, где он представляет действующее лицо — член класса пользователей «Химики» или «Сотрудники склада химикатов». На диаграмме потоков данных на рис. 11-1 также видно, что оба эти класса могут размещать запросы химикатов. Кстати, не путайте класс пользователей и класс объектов, невзирая на схожесть названий, они не связаны между собой.
Атрибуты (attributes), связанные с классом «Сотрудник, разместивший заказ на химикат», показаны в средней части прямоугольника, который обозначает их класс: имя, ID_сотрудника, Номер_отдела и Номер_офиса (правило применения заглавных букв довольно распространено в UML диаграммах). Это свойства или элементы данных, связанные с каждым объектом — членом класса «Сотрудник, разместивший заказ на химикат». Похожие атрибуты могут содержаться в определении хранилищ на диаграмме потоков данных или в словаре данных.
Операции (operations) — это службы, которые объект каждого класса может выполнять. Операции показаны в нижней части поля класса, как правило, за ними стоят пустые скобки. На диаграмме классов, представляющей проектирование, эти операции соответствуют функциям или методам класса, а аргумент функции часто заключен в скобки. В модели анализа класса просто должно быть показано, что Сотрудник, разместивший заказ на химикат, может запрашивать химикаты, выполнять поиск по каталогам продавцов и получать контейнеры с химикатами. Операции на диаграмме классов весьма приблизительно соответствуют процессам, показанным в кружках на диаграммах потоков данных нижних уровней.
Рис. 11-6. Диаграмма классов для части Chemical Tracking, System
Линии, соединяющие прямоугольники классов на рис. 11-6, символизируют связи между классами. Цифры на них указывают на множественность связи, точно так же, как линии на диаграммах «сущность-связь» — на множественность взаимоотношений между объектами. На рис. 11-6 знак звездочки обозначает связь «один ко многим» между классами «Сотрудник, разместивший заказ на химикат» и «Запрос химиката»: один сотрудник может разместить множество запросов, но каждый запрос принадлежит только одному сотруднику.