Недостатки моделирования данных

1. На общем уровне БД и модель данных рассматриваются как центральные понятия в планировании и проектировании приложений.

2. Фактические вычисления, работа пользователя и правила бизнеса рассматриваются как некоторое дополнение к БД исходя из ориентированных на задачи перспектив.

Но этот подход имел несколько недостатков:

1. Разработка полной корпоративной модели данных дорогая и сложная. Многие организации решились построить такие модели, но после заполнения 30 или 40 томов документации за период в 2 - 3 года они пришли к заключению, что могут никогда не закончить эту работу.

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

3. Основательная модель данных является важной, но далеко не достаточной.

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

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

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

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

Стадии проектирования приложений

Рассмотрим более детально эти стадии.

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

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

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

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

Концептуальная модель отвечает на три вопроса: Как будет выглядеть новое приложение? Как изменится данный бизнес? Как будут отображены требования к новым процессам бизнеса?

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

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

Теперь рассмотрим три вида моделей, которые соответствуют трем слоям архитектуры приложений.

Статические структурные модели, соответствующая слою БД. Модель данных прекрасно описывается с помощью статических структурных моделей, охватывающих статическую структуру отдельных компонентов (сущности и их атрибуты) и связи между компонентами.

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

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

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