9.6. Основные этапы подхода Мартина

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

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

• первоначальной направленности на моделирование данных, а затем на функциональное моделирование

Основные этапы подхода Мартина приведены на рис. 9.7.

Рис. 9.7. Основные этапы подхода Мартина

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

2. На этапе анализа основные бизнес-процессы, разработанные на этапе 1), используются для разбиения общей задачи на частные, при этом основное внимание уделяется определению информационной и функциональной моделей для частных задач. При этом диаграммы "сущность-связь" трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD, диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы "сущность/процесс".

3. На этапе логического проектирования IE становится аналогична SE для разработки ПО. Базой для проектирования являются процессы, разработанные на этапе анализа. Используя методики нисходящей функциональной декомпозиции, проектируются спецификации обработки в процессах и их логические структуры данных. При этом используются диаграммы структуры данных (диалект ERD), определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности (вид миниспецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов.

4. На этапе физического проектирования и реализации производится преобразование логической модели ИС в физическую и ее реализация.

Глава 10 архитектура современных систем и методологии

В центре любой методологии находится некоторая системная архитектура, и лишь затем совокупность стратегий и методов анализа и проектирования. Архитектура современных систем является трехслойной (рис.10.1) и имеет следующие характеристики:

• четко определенные слои

• формальные и явные интерфейсы между слоями

• скрытые и защищенные детали внутри каждого слоя.

ПОЛЬЗОВАТЕЛЬ

ДОКУМЕНТЫ

ПРАВИЛА БИЗНЕСА

ДАЗА БАННЫХ

ОПЕРАЦИОННАЯ СИСТЕМА

Рис. 10.1. Архитектура современной системы

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

• выполнение требуемых задач

• принятие решений в соответствующей компетенции

• запуск других задач в слое правил бизнеса и других слоях.

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

• улучшение базы данных - отделение базы данных от изменений в технологиях, а следовательно, поддержка согласованности и осмысленности данных в течении длительного периода времени;

• гибкость интерфейсов пользователя - изменение интерфейсов без влияния на бизнес-процессы и наоборот;

• разделение усилий коллектива разработчиков.

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

• информационная модель (и база данных) рассматриваются как центральные понятия при анализе и проектировании;

• функциональная модель (а следовательно, и правила бизнеса) является некоторым дополнением к информационной модели.

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

• построенная на ее основе функциональная модель либо является слабо связанной с информационной моделью, либо неадекватно отражает существующие бизнес-процессы и правила;

• сама по себе информационная модель является недостаточной (хотя и важной) для решения задач консалтинга;

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

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

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

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

Таблица 10.1

Слои	Анализ	Проектирование	Реализация
Документы	Поток работ	Поток форм	Формы
Правила бизнеса	Поток процессов	Модель компонентов	Программы
База данных	Модель данных	Схема базы данных	Таблицы и т.п.

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

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

Реализация. На данном этапе проект преобразуется в систему.

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