Диаграммы потоков данных для общения с заказчиком

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

Предположим, например, что заказчик пытается объяснить тип банковского приложения, который ему нужен, начиная с депозитов на счет. Функциями депозита могут быть «Получить депозит от пользователя», «Проверить операцию по депозиту», чтобы убедиться в ее законности и т.д.

Пользователь, как участник, должен быть отмечен на диаграмме. Хранилище данных («Банк») представляет собой список банков, предоставляющих депозит через этот банкомат. Здесь также показан поток данных в ответ на запрос с более подробными данными счета.

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

 

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

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

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

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

Модель переходов состояний - хороший способ объяснить концепцию работы приложения, а также используется как инструмент проектирования. Стоит ли использовать модели переходов состояний для формулирования требований (С - либо D- требований), зависит от конкретного приложения и от того, насколько это может помочь заказчику. Обычно для этого требуется наличие у заказчика некоторых навыков.

 

 

Рис. 5.8. Диаграмма потоковых данных для программы управления банкоматом

Этнографический подход

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

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

Как замечено, рутинная деятельность пользователя затрудняет четкое описание всех аспектов выполняемой им работы. Они понимают свою работу, но не могут объяснить ее взаимосвязь с другими видами работ, выполняемых в организации. Социальные и организационные факторы, которые оказывают влияние на работу, но не являются очевидными, могут стать явными, если описаны беспристрастными наблюдателями.

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

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

 

5.3.3. Аттестация и управление требованиями

 

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

Во время процесса аттестации должны быть выполнены следующие типы проверок документации требований:

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

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

3. Проверка на полноту. Спецификация требований должна содержать требования, которые определяют все системные функции и ограничения, налагаемые на систему.

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

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

1. Обзор требований. Это процесс просмотра системной спецификации для нахождения неточных описаний и ошибок, а также проверки непротиворечивости требований и их полноты.

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

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

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

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

Поэтому управление требованиями – это процесс управления изменениями системных требований, который выполняется совместно с другими процессами разработки требований.

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

С точки зрения разработки, требования можно разделить на два класса:

1. Постоянные требования. Это относительно стабильные требования, которые исходят из основной деятельности организации и касаются непосредственно предметной области, где будет эксплуатироваться система.

2. Изменяемые требования. Эти требования отображают изменения, сделанные во время разработки системы или после ввода ее в эксплуатацию.

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

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

Приведем ключевые понятия, введенные в данном разделе:

· Процесс разработки требований включает анализ осуществимости создания системы, формирование и анализ требований, специфицирование требований, аттестацию требований и управление требованиями.

· Анализ требований является итерационным процессом, который включает анализ предметной области, сбор требований, их классификацию, разрешение противоречий, назначение приоритетов и проверку требований.

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

· Социальные и организационные факторы оказывают большое влияние на системные требования.

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

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

 

5.4. Моделирование вариантов использования

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

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

Вариант использования представляет собой некий целостный набор функций, имеющих определенную ценность для пользователя [16].

Варианты использования – это технология определения функциональных требований к системе [21].

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

Айвар Якобсон (Jacobson, Ivar, [22]) дал начало идее о вариантах использования. Он предложил начинать проектирование приложения с написания вариантов использования с последующим их применением для выбора классов, для разработки прототипа системы и, как основы для тестовых планов системного уровня.

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

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

Сценарий (scenario) – это последовательность шагов, описывающих взаимодействие пользователя и системы.

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

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

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

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

На самом деле актор – не совсем верный термин, как утверждает Мартин Фаулер [21], возможно роль (role) подошел бы лучше. Очевидно, имел место неправильный перевод со шведского языка, и в результате сообщество пользователей вариантов использования теперь употребляет термин актор.

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

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

 

5.4.1. Концепции моделирования вариантов использования

 

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

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

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

Когда варианты использования документируют бизнес – процессы, рассматриваемая система и является этой организацией, а полученная диаграмма называется диаграммой Бизнес – вариантов Использования [2]. Участники – это акционеры компании, заказчики, поставщики, органы государственного управления. Основные действующие лица – это заказчики компании и, возможно, их поставщики.

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

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

Применение вариантов использования немного отличается от традиционных способов разработки. Разделение проекта по вариантам использования (архитектурное представление) ориентировано на процессы в системе, но не на их реализацию. В этом проявляется отличие данного метода от часто используемого декомпозиционного подхода, так как варианты использования акцентируют то, что ожидает от системы клиент.

В начале работы над проектом возникает вопрос: «Как объявить варианты использования? ». Варианты использования можно вывести в результате идентификации задач для клиента. Для этого следует задаться вопросами:

· Как клиент будет пользоваться системой?

· Будет ли он работать с информацией (создавать, читать, обновлять либо удалять)?

· Будет ли он информировать систему о внешних событиях?

· Должна ли система уведомлять его о каких – либо произошедших изменениях или событиях?

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

Варианты использования именуются по терминологии пользователей, а не техническими названиями, не понятными работающим с системой людям. Не должно быть варианта использования «Взаимодействие с кредитной системой банка для проверки номера кредитной карточки». Клиент пытается купить билет, поэтому разумно ввести вариант использования «Покупка билета». Обычно название варианта использования приводится в формате < глагол> < существительное> и определяет то, что в результате получает клиент. Пользователю безразлично количество систем, с которыми взаимодействует его система, какие специфические операции выполняются внутри системы и сколько строк кода будет написано для проверки кредитной карточки Visa. Пользователю только важен покупаемый им билет, но не операции, приводящие к такому результату.

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

· Существует ли для любого функционального требования хотя бы один вариант использования? Если для требования нет варианта использования, то такое требование не будет реализовано в системе.

· Анализировалось ли использование системы каждым участником?

· Какую информацию предоставляет системе каждый из участников?

· Какую информацию получит от системы каждый из участников?

· Обсуждались ли вопросы обслуживания системы? Должны ли быть люди, которые запускают и останавливают систему.

· Учтены ли все внешние системы, с которыми взаимодействует разрабатываемая система?

· Какую информацию от внешних систем будет получать или отправлять разрабатываемая система?

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

Такое соответствие не является однозначным, так как бизнес – варианты использования дают высокоуровневое описание. Например, для авиакомпании существует вариант – использование «Отремонтировать самолет». Для построения системы, реализующей его, потребуются такие системные варианты использования, как: «Найти неисправность», «Проверить на складе нужные запасные части», «Получить запасные части со склада», «Заказать запасные части», «Спланировать обслуживание» и т.д. Каждый из этих вариантов использования должен будет прослеживаться до бизнес – варианта использования «Отремонтировать самолет». Хотя это правило не всегда выполняется по причине того, что некоторый бизнес – вариант использования не может быть автоматизированным процессом.

Реальная цель отслеживания состоит в том, чтобы в окончательном варианте системы были учтены все требования к ней, а любой фрагмент код можно было бы отследить до определенного требования к системе.

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

Процесс отслеживания показан на рис. 5.9.

 

 

Рис. 5.9. Отслеживаемость в цикле жизни процесса разработки ПО

 

Поток событий

Для реального проектирования системы, в вариантах использования, кроме описания того что будет делать система, используются специфические данные, которые отражены в потоке событий (flow of events).

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

· Назначение и краткое описание варианта использования, объясняющее действия в нем

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

· Предусловия

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

⇐ Предыдущая9101112131415161718Следующая ⇒

Поделиться: