ГЛАВА 8 Определение оабочих npoiieccoe

Элемент даны к j

Начало

Документ

Задача

Рис. 8-2. Связи чих процессах

Задача

Задача

Пользовательские сценарии

Создание пользовательских сценариев (user scenarios) - альтернатива формальному анализу ский сценарий состоит из двух элементов: множества профилей жвателя (user profiles), которые определяют множество пользователей системы, и сценариев использования (usage scenarios) i i.i каждого из профилей. Последние представляют собой описание того, как пользователь предполагает работать с

системой - то есть действий, которые он будет выполнять.

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

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

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

Папример, даже простой сценарий: Продавец будет использовать

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

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

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

ЧАСТЬ 2 Проектирование ионкых систем баз данных

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

Итоги

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

В главе 9 мы рассмотрим концептуальную модель - логическую организацию Данных, структур и утилит.

Концептуальная: модель данных

ГЛАВА

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

бочие процессы. Пора создавать модель данных.

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

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

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

Определение объектов базы данных

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

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

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