С частью 5 можно ознакомиться, перейдя по ссылке

IX Определение поведения системы.

В очень многих случаях поведение … только потому кажется смешным, что причины его, вполне разумные и основательные, скрыты от окружающих.
Франсуа де Ларошфуко

После того как мы определились с перечнем основных сценариев и сущностей предметной области, необходимо сопоставить их друг с другом.

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

Этот процесс удобно выполнять при помощи канонической диаграммы последовательности. На диаграммах этого типа можно моделировать цепочки событий, при которых один объект, используя процессы, передает сообщение другому объекту и вынуждает его в свою очередь реагировать на этот инцидент. В результате такого события, запрашиваемый объект может вернуть ответ, либо инициировать следующие процессы. Таким образом удобно формализовать низкоуровневые функции системы. Чем длиннее и сложнее цепочки реакций на событие, тем сложнее обойтись без использования диаграммы последовательности.

На рисунке 9.1 изображен процесс формализации требований к целевой системе, дополненный подпроцессом определения ее поведения.



Рисунок 9.1 — модель процесса определения поведения системы

1. Используем диаграммы последовательности для моделирования поведения системы

Продолжим проектирование контура «Учета заданий» и разберем в качестве примера — поведение системы при выставлении Заданий исполнителям см. на Рисунке 9.2
Напомню, что диаграммы последовательности читаются слева направо, сверху вниз.



Рис. 9.2 – Диаграмма Последовательности Формирование Заданий

Данная операция начинается с выбора заранее разработанного Шаблона Карты Заданий (далее ШКЗ), на основе которого и будет формироваться новая активность в проекте, в виде Карты заданий пользователям. Обратите внимание, что экземпляр Карты задания на диаграмме расположен не в верхнем ряду, а только на уровне стрелки события, фактически его порождающего в рассматриваем процессе. Но это мы забежали немного вперед. Давайте вернемся к нашей диаграмме и продолжим рассматривать ее последовательно (она же диаграмма последовательности).

На диаграмме классов (рассмотренной в прошлой части статьи) см. Рисунок 8.4, видно, что в ШКЗ используется ссылка на справочник Штатных позиций. Она необходима для определения лица, ответственного за выполнение Карты заданий. Поэтому, вторым шагом сценария, мы определяем конкретного Сотрудника, занимающего на данный момент должность, по штатной позиции. Кстати, упомянув про второй шаг заметил оплошность, на моей диаграмме нет номеров около стрелок, обычно они проставляются и это очень удобно. Так вот сотрудник, выявленный нами на втором шаге и будет куратор Карты задания. Фактически мы на данном этапе моделирования формализовали новую системную функцию (не путать с бизнес функциями рассмотренными нами в прошлых разделах), на вход которой подается Штатная позиция, а на выходе возвращается ссылка на сотрудника. Скорее всего подобная функция пригодится нам еще не раз.

Идем дальше, как было подчеркнуто ранее — сверху вниз, слева направо. ШКЗ связывает Шаблоны заданий, определяя состав и последовательность операций для исполнителей. Поэтому аналогично тому, как по ШКЗ мы создали Карту заданий, по Шаблонам заданий формируем — Задания (операции), объединенные в только что созданную Карту заданий. Но поскольку в одной Карте может быть множество Заданий, мы применяем на диаграмме — прием моделирования цикла (фрейм со стереотипом loop). Подобным образом на диаграммах данного вида можно показать: условные переходы, предусловия и прочие условные конструкции.

Для Шаблона заданий также, как и для ШКЗ, определена ссылка на справочник штатных позиций. Эта связь необходима для определения уже непосредственного исполнителя Задания, входящего в Карту. Для каждого Задания по этой ссылке определяем исполнителя (если это возможно). Не трудно заметить, что данная функция уже была нами выявлена и идентифицирована на втором шаге диаграммы.

Еще один немаловажный процесс, в рассматриваемом примере: заполнение параметров, определяющих характеристики выполнения Задания. Во время формирования Задания, параметры, которые определенны для его Шаблона как входящие, заполняются текущими значениями сущностей системы. Этот процесс показан абстрактно через абстрактный класс «Метаданные». Для более детального определения шагов этого процесса, строится отдельная диаграмма.

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

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

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

Для реализации требований событийно управляемых систем, особые требования предъявляются к определению и управлению состояниями (совокупностью свойств в конкретный момент времени) объектов, при возникновении различных событий. Например, разработка сценария автоматического изменения свойств объекта при наступлении определенных условий, в определенный момент времени. Такие задачи удобно моделировать при помощи канонических диаграмм состояний, позволяющих связать события с состояниями. Этот вид диаграмм можно эффективно использовать совместно с диаграммами последовательностей, которые явно выявляют события.

Напомню основные постулаты моделирования при помощи диаграмм состояний. Основной элемент диаграммы состояний, естественно «состояние» рассматриваемого объекта. На одной диаграмме можно моделировать переходы состояний только одного объекта. Одно состояние на диаграмме может встречаться только один раз.

Ниже на Рисунке 9.3 приведен пример моделирования переходов состояния объекта «Задание». На диаграммах данного типа всегда есть элемент, определяющий порождение объекта и указывающий начало его Жизненного цикла (далее ЖЦ). В нашем случае, при создании нового Задания критическим атрибутом, определяющим его следующее состояние, будет исполнитель. Если он задан, то задача может быть предложена для выполнения, если нет, то она и дальше будет оставаться в начальном состоянии. В данном примере не рассматриваются правила заполнения остальных атрибутов объекта (которые также могут иметь место), так как они в конкретном случае для нас не существенны.



Рис. 9.3 – Диаграмма Состояния Заданий

На диаграмме в квадратных скобках, рядом со стрелкой, отмечены условия перехода. Они указывают, что если выполнено данное условие, то будет осуществлен переход в следующее по стрелке состояние. А надписью около стрелки без скобок обозначают событие, по которому должно выполняться изменение состояния. В прямоугольнике, обозначающем состояние, перечислены все возможные события, которые и вызывают переход (они должны соответствовать событиям на стрелках). Каждое состояние на диаграмме должно обязательно получить стрелку(ки) переход в него и одну или несколько стрелок — переход из него. Таким образом, очень сложно упустить из вида какие либо события и условия перехода.

Например, в состояние «Выполнена» можно попасть из состояния «В работе», при условии, что проставлена отметка о выполнении задачи. А из него можно перейти в состояния:

• «Закрыта», если отчет принят и подтвержден,
• «Отложена», если принято решение о приостановке задачи
• ввернуться в состояние «В работе», если отчет о выполнении не принят и задание требует доработки.

На диаграмме, всегда должен быть определен конец ЖЦ объекта.

На практике, вместо диаграмм состояний, иногда бывает удобно использовать таблицы перехода состояний. Они понятнее для большинства заинтересованных лиц проекта и применяются в случаях, когда нет сложных, запутанных процессов. Например, ниже представлена упрощенная таблица перехода состояний Заданий в рассматриваемом нами проекте.



Но при составлении таблиц, следует понимать, что есть большая вероятность упустить что-то важное. Поэтому моделирование лучше проводить при помощи диаграмм, а потом на основании их уже заполнять таблицу. Например, я честно говоря, сначала составил таблицу и не планировал включать в эту главу рисунок с диаграммой, оставив ее составление на Ваше усмотрение. Но изменив свое решение, сразу нашел множество несоответствий, и Вы их можете увидеть сами, поскольку я специально не стал ничего исправлять.

3. Избегаем излишней «заадминистрированности» системы

Проектируя механизмы, которые позволяют, на основании зарегистрированных в системе данных, принимать решения о способе их обработки, следует обратить особое внимание на вероятность того, что сами правила формирования условий для выбора этих решений могут измениться. Поясню проще: если заказчик говорит, что некое правило действует всегда, то это совсем не означает, что после внедрения системы, не найдется объективная причина, добавить исключение в это «железобетонное» правило. Жестко спроектированный механизм принятия решения, в этом случае, станет большой головной болью для всех участников проекта.

В моей практике был проект, направленный на создание системы автоматизирующей взаимоотношения с клиентами, в том числе продажи. Разрабатываемая система должна была заменить устаревшую, в которой учет велся в ручном режиме (но естественно, по определенным правилам). Для проектирования были взяты утвержденные документы-регламенты, устанавливающие правила продаж на фирме. На основании документов разработан механизм, позволяющий гибко настраивать систему для обработки этих правил. Но при внедрении системы, которая могла автоматически формировать счета, используя сложную многоуровневую систему скидок, выяснилось, что есть случаи, когда продажи происходят без всяких правил по усмотрению менеджеров, а разработанное ПО — это делать уже не позволяло. Для того чтобы перепроектировать систему под возможность формирования счетов «от фонаря», пришлось вносить больше количество изменений. Этим примером я хотел подчеркнуть, что слишком сложная инкапсуляция приводит к снижению управляемости и сужает применяемость модуля. Об этом уже упоминалось в главе VIII.

Поэтому, в таких случаях, желательно использовать следующие рекомендации:

• при определении значений для выбора правила обработки, используйте константы, которые пользователь при необходимости сможет легко изменить;
• предусматривайте режим «отката» — отмены операций (транзакций), выполненных системой на основе механизма принятия решения;
• выполняйте грануляцию процессов, разделяя сложные, на простые, распределяя ответственность по объектам, связанным друг с другом простыми интерфейсами. В этом случае будет проще вносить изменения в поведение подсистем принятия решений, или заменять их на новые подсистемы и сервисы;

Например, в модуле выставления заданий исполнителям, по шаблону выполняются следующие процессы:

1. Формируется Карта заданий и Задания по шаблону;
2. Производится извещение исполнителей и ответственных о назначенном для них задании.

Можно было бы создать один объект, выполняющий последовательно эти два процесса. Но существует вероятность того, что со временем, потребуется извещать исполнителей о назначении им задания не сразу всех, а последовательно по мере выполнения предыдущих заданий. В этом случае, разделение ответственности между двумя объектами позволит: первому объекту отвечать только за формирование заданий, а второму с некоторой периодичностью извещать исполнителей о назначении задания, по мере их “созревания” для исполнения.

X Совершенствуем требования

Я, в своей практике, использую прием формирования требований в несколько проходов. То есть, сначала я набрасываю черновой вариант, не стараясь получить сразу качественные формулировки. В описаниях могут повторяться слова, выражения могут быть «корявыми» и т.п. Главное, изложить основные мысли, и сформировать связанную структуру – каркас спецификаций. Позже, я вычитываю спецификации еще раз и стараюсь «причесать» текст так, чтобы он хорошо воспринимался на слух. Иногда описания меняются до неузнаваемости. Так я прохожу по спецификациям 4-5 раз (а иногда и больше), пока они не превратятся в стройную и легко воспринимаемую структуру. Кстати, таким же образом писалась эта публикация.

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

1. Проверяем трассируемость требований

Как уже отмечалось выше, очень важно поддерживать связь между всеми артефактами проекта, начиная с самых ранних стадий. Мы, в нашем проекте, переходя к каждому последующему этапу, использовали артефакты из предыдущего, явно указывая ссылки. Таким образом, например, по Пользовательской истории можно легко отобрать спецификации требования, определить выполняемые задачи и степень их исполнения.

Для трассируемости артефактов используйте в них идентификаторы. Проставляйте в артефактах ссылки на идентификаторы других артефактов. На основании этих связей можно отследить требования, которые никак не связаны с другими требованиями, Пользовательскими историями, другими артефактами и еще раз проанализировать целесообразность их использования или определить пробелы в полноте требований.

2. Работаем над тестируемостью

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

С точки зрения тестируемости следует обратить внимание на то, что требование должно содержать в себе точный проверочный критерий. То есть, оно должно позволить однозначно ответить на вопрос: “удовлетворяет ли требование пожеланиям заказчика или нет”.

Формируя требования, старайтесь составлять их таким образом, чтобы на основании их было легко и удобно разрабатывать приемочные тесты. Критерии должны позволять проверить как полноту, так точность реализации. Подобные приемы очень эффективно используются в методологиях гибкого проектирования Scrum, XP [10]. Используйте, например, формирование разъяснений в тексте требований, отображающих правила заполнения данных с указанием вариантов, являющихся граничными для выбора алгоритма обработки. Например, можно сформировать таблицу, в одной из колонок которой, перечисляются значения, граничные для выбора алгоритма поведения, а в другой указания того как должна повести себя система в этом случае. Например:



Составляя приемочные тесты, тестировщик использует уже подготовленные значения.
Ну а в любой книжке, обучающей процессу разработке требований, можно прочитать, что с точки зрения тестируемости, необходимо обратить внимание на такие характеристики требования как:

• Ясность (недвусмысленность, определенность, однозначность);
• Осуществимость (реализуемость исполнителями);
• Полнота (текст требования не нуждается в дополнительной детализации для исполнителей);
• Единичность (требование должно описывать одну и только одну “вещь”);
• Непротиворечивость (требование не должно противоречить другим требованиям);

3. Согласуем требования

Основной эффект от моделирования, достигается за счет выявления на ранних стадиях проектирования, несоответствия между представлением о результирующем продукте между заказчиком и разработчиками. Порой, это позволяет достичь понимания и внутри команды разработки. Моделирование, также позволяет пользователям более наглядно, в деталях, представить некоторые свои предположения относительно функционирования продукта и внести уточнения или изменения в первоначальные пожелания. Чем качественней пройдет этот процесс, тем меньше придется вносить изменения в уже реализованный продукт. Поэтому согласование требований с заказчиками — очень важный момент, который нельзя упускать и, более того, согласования должны производиться с постоянной периодичностью после каждого значительного продвижения проекта.

Я сам неоднократно читал подобные рекомендации и большей частью пропускал их мимо ушей, пока это не коснулось меня лично. Как-то все проходило достаточно гладко, и иногда брали проекты с недостаточно проработанными требованиями, и дорабатывали их уже в ходе разработки, и все раз за разом сходило с рук. Но рано или поздно наступает момент, когда расслабишься, постепенно притупится осторожность, обязательно находится партнер или заказчик, который на основании плохоформализованных, но очень бюджетных договоренностей об одном, потребует от Вас совершенно другого и будет Вам выкручивать руки и вводить Вас в отчаяние. А не дай бог, он окажется государственной структурой — Вы «попали»… Лучше до этого не доводить.

Не бойтесь все схемы, диаграммы, спецификации, связанные с описанием бизнес процессов, показывать заказчику. И не просто показывать, а объяснять их содержание так, чтобы у него возникали вопросы, и появился интерес к обсуждению. Это сложный и кропотливый процесс, решить его сразу «с наскока» не получится.

Вы должны постепенно и неотступно приучать заказчика слушать ваши объяснения и вникать в суть презентуемых документов. Определитесь с составом диаграмм, которые лучше всего им воспринимаются.

Очень часто, увидев первые прототипы продукта, пользователь меняет свои первичные пожелания. А поскольку, в этом случае, требования уже были формально утверждены участниками проекта, внесение изменений в них должно проходить отдельной, более строгой процедурой согласования. Ведь эти изменения могут повлиять на смежные процессы или функционал других пользователей.

Более детально механизм изменения требований описан в главе «Решаем проблему изменений требований».

Согласование должно производиться не только по сути требований, но и по приоритету их реализации. Для этого команда, совместно с заказчиком, определяет такую характеристику, как «Важность» требования.

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

Опустим работу с рисками в проекте “вообще”, и коснемся только темы управления рисками при разработке требований. Как было отмечено выше, уже сам по себе метод моделирования снижает риски разработки ненужного или неправильного функционала в продукте. Это обусловлено тем, что на ранних стадиях проектирования проектировщики и разработчики могут обсуждать с заказчиком функционал на моделях-прототипах продукта. Соответственно, чем качественней разработаны модели, тем большее понимание предметной области может быть достигнуто в ходе таких дискуссий. И наоборот, если у Вас не хватает времени на разработку качественных глубоких требований, то Вы рискуете создать продукт, который не удовлетворит потребностей заказчика. Это выяснится уже после того как он будет разработан, потребует дополнительных затрат, что может сильно огорчить заказчика.

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

В общем случае, риски, связанные с требованиями, обусловлены в основном отклонением одной из его характеристик от нормы. Это:

• Непротиворечивость требований между собой;
• Однозначность толкования;
• Определение критериев Тестируемости;
• Согласование с заказчиком и заинтересованными сторонами;

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



Следующую часть мы посвятим специфицированию требований.

Original source: habrahabr.ru (comments, light).