Тщательно слушая, как клиенты представляют свои требования, аналитик может выделить ключевые слова, которые преобразуются в определенные элементы модели. В табл. 11-1 перечислены возможное отображение значимых существительных и глаголов, употребляемых пользователями, в компонентах модели, о которых рассказано далее в этой главе. По мере того как вы будете записывать пожелания пользователей в виде требований и моделей, вам придется связать каждый компонент модели с определенным пользовательским требованием
Таблица 11-1. Привязка пожеланий клиента к компонентам модели анализа
| Тип слова | Примеры | Компоненты модели анализа |
| Существительные | Люди, организации, системы ПО, элементы данных или существующие объекты | · Оконечные объекты или хранилища данных (диаграммы потоков данных) · Действующие лица (диаграммы вариантов использования) · Объекты или их атрибуты (диаграммы «сущность - связь») · Классы или их атрибуты (диаграммы классов) |
| Глаголы | Действия, задачи, которые пользователь может выполнить, или события, которые могут произойти | · Процессы (диаграммы потоков данных) · Варианты использования (диаграммы вариантов использования) · Взаимосвязи (диаграммы, «сущность - связь») · Преобразования (диаграммы перехода состояний) · Процессы (диаграммы процессов) |
В этой книге я использовал в качестве учебного примера Chemical Tracking System. В следующем абзаце для этой системы описаны потребности пользователей, который представил сторонник продукта от класса Химики. Значимые существительные выделены полужирным начертанием, а глаголы или отглагольные существительные — курсивом; отыщите эти ключевые слова в моделях анализа, показанных далее в этой главе. На схемах некоторых моделей с целью иллюстрации показана информация, выходящая за рамки содержания следующего абзаца, тогда как на других моделях отображена только часть информации, представленной здесь:
Химик или кто-то из работающих на складе химикатов может разместить запрос на один или несколько химикатов. Запрос может быть выполнен или посредством доставки контейнера с химикатом, который числится инвентарной описи товаров на складе химикатов, или посредством размещения заказа на химикат у постороннего поставщика. Сотрудник, размещающий запрос, при подготовке запроса должен иметь возможность искать в режиме реального времени нужный химикат в каталогах поставщиков. Системе необходимо отслеживать состояние каждого запроса с момента его подготовки и до момента его выполнения или отмены. Ей также необходимо отслеживать историю каждого контейнера с химикатом с момента его получения компанией до его полного расходования или уничтожения ».
Диаграмма потока данных
Диаграмма потока данных (data flow diagram, DFD) — основной инструмент структурного анализа (DeMarco, 1979; Robertson и Robertson,. 1994). Она позволяет определять трансформационные процессы системы, совокупность (хранение) данных или материалов, которыми система управляет, и потоки данных или материалов между процессами, хранилищами и внешним миром. При моделировании потоков данных для системного анализа используется прием разложения функций, при котором сложные проблемы раскладываются на составляющие, размещаемые по нарастающей по уровням детализации. Этот метод отлично подходит для систем обработки транзакций и других приложений с большим набором функций. Посредством добавления элементов управления потоком диаграмму потока данных удалось применить для моделирования систем, работающих в режиме реального времени (Hatley, Hruschka и Pirbhai, 2000).
Диаграмма потока данных позволяет представить этапы бизнес-процесса или операции предложенной системы ПО. Я часто пользовался этим средством, опрашивая клиентов — я набрасывал на доске диаграмму, пока длилось обсуждение бизнес-операций. Диаграммы потока данных могут представлять системы на самых разных уровнях абстракции: диаграммы высокого уровня предоставляют целостный, панорамный вид данных и выполняемых компонентов в многоэтапном процессе, дополняющем точное, детальное представление, реализуемое в спецификации требований. Диаграмма потока данных иллюстрирует то, как совмещаются функциональные требования в спецификации, чтобы пользователь смог выполнять определенные задачи, например запрос химиката.
| Ловушка Не обольщайтесь, что клиентам заранее известно, как читать модели анализа, однако не думайте, что они не смогут разобраться в них. Объясните цели и условные обозначения для каждой модели сторонникам продукта и попросите их просмотреть диаграммы. |
Контекстная диаграмма на рис. 5-3 — это наивысший уровень абстракции диаграммы потока данных. Контекстная диаграмма представляет всю систему как единый процесс, изображенный в виде круга (пузырька). На ней также показаны оконечные объекты (terminators), или внешние объекты, подсоединенные к системе и данным или материальным потокам между системами и оконечными объектами. Потоки на контекстной диаграмме часто представляют сложные структуры данных, определенные в словаре данных.
Вы можете конкретизировать контекстную диаграмму до уровня 0, выделив важнейшие процессы системы. На рис. 11-1 показан уровень 0 диаграммы потока данных для Chemical Tracking System (несколько упрощенный). Единый процесс Chemical Tracking System, обозначаемый на контекстной диаграмме одним кружком, был разделен на семь основных процессов (кружков). Как и на контекстной диаграмме, оконечные объекты показаны прямоугольниками. Все потоки данных (стрелки), присутствовавшие на контекстной диаграмме, отражены на уровне 0 диаграммы потока данных. Кроме того, парами параллельных линий здесь обозначены хранилища данных, которые относятся ко внутренней части системы и, следовательно, не показаны на контекстной диаграмме. Стрелка от кружка к хранилищу, указывает, что данные были помещены в хранилище, стрелка, выходящая из хранилища, обозначает операцию считывания, а двунаправленная стрелка между хранилищем и кружком — операцию обновления.
Каждый процесс, изображенный в виде отдельного кружка на уровне 0 диаграммы, можно расписать более подробно с помощью отдельной диаграммы, изобразив на ней всю функциональность этого процесса. Аналитик продолжает последовательные уточнения до тех пор, пока диаграммы нижних уровней не будут содержать только простейшие операции, которые можно ясно представить в виде комментариев, псевдокода, графика или диаграммы процесса. Функциональные требования в спецификации требований к ПО точно определят, что происходит в ходе каждого простейшего процесса. Диаграммы потока данных каждого уровня должны быть сбалансированы и согласованы с расположенным выше уровнем так, чтобы вся входящие и исходящие потоки на дочерней диаграмме соответствовали аналогичным на родительской диаграмме. Сложные потоки данных в диаграммах высоких уровней могут быть разделены на составные элементы, как определено в словаре данных, на диаграммах потока данных нижних уровней.
На первый взгляд схема на рис.11-1 выглядит сложной. Однако если вы изучите ближайшее окружение любого процесса, то увидите элементы данных, которые он принимает и отдает, а также их исходные точки и точки назначения. Чтобы увидеть, как именно в процессе используются элементы данных, вам понадобится либо нарисовать более подробную дочернюю диаграмму потока данных или сослаться на функциональные требования для этой части системы.
Рис. 11-1. Уровень 0 диаграммы потока данных для Chemical Tracking System
Ниже приведены некоторые правила для рисования диаграмм потока данных. Не все придерживаются одних и тех же правил (например, некоторые аналитики показывают оконечные объекты только на контекстных диаграммах), однако я считаю их полезными. Использование моделей для улучшения взаимодействия участников проекта важнее догматического соблюдения этих правил.
· размещайте хранилища данных только на уровне 0 и более низких уровнях диаграммы потока данных, а не на контекстной диаграмме;
· процессы взаимодействуют через хранилища данных, а не посредством прямых потоков от одного процесса к другому. Точно так же данные не могут передаваться напрямую из одного хранилища в другое, они должны пройти через процесс (кружок);
· не пытайтесь вообразить последовательность этапов процесса с помощью диаграммы потока данных; называйте каждый процесс как короткое действие: глагол + объект (например, создать инвентарный отчет). Используйте названия, понятные клиентам и употребляемые в деловой или предметной области;
· присваивайте процессам уникальные номера согласно иерархии. На уровне 0 диаграммы, пронумеруйте каждый процесс, используя целые числа. Если вы создадите дочернюю диаграмму потока данных для процесса 3, пронумеруйте процессы на ней как 3.1, 3.2 и т.д.;
· не показывайте на одной диаграмме более 8-10 процессов, в противном случае ее будет трудно рисовать, изменять и понимать. Если у вас больше десяти процессов, создайте еще один уровень абстракции, сгруппировав связанные процессы в процесс более высокого уровня;
· кружки с только входящими или только исходящими потоками вызывают подозрение. Корректный процесс, изображаемый кружком на диаграмме потока данных, как правило, отличает наличие и входящих, и исходящих потоков.
Когда представители клиентов просматривают диаграмму потока данных, они должны убедиться, что на ней отображены все известные процессы и что у них нет отсутствующих или ненужных входящих или исходящих потоков. При изучении диаграммы потока данных часто выявляются не распознанные ранее классы пользователей, бизнес-процессы и соединения с другими системами.