Моделирование бизнеса и архитектура информационной системы

Предыдущая часть

• Названия строк и столбцов
• Дополнение схемы
• Замечания о полноте
• Интеграция схемы Захмана с методами моделирования бизнеса
• Заключение
• Литература

Названия строк и столбцов

Схема Захмана является простым, но достаточно мощным средством. Эта мощность особенно хорошо видна при попытке ее расширения. В этом разделе приведены краткие дополнительные соображения о схеме, а также некоторые моменты, о которых следует помнить при ее использовании.

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

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

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

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

Характеристика взгляда состоит из двух частей:

Описание взгляда, включающее:

• Точку зрения (статус человека, имеющего данный взгляд);
• Что показывает взгляд (аспект);
• Техника или язык, описывающий данный взгляд (например, IDEF1X для аспекта данных, IDEF0 или диаграмма потока данных для функционального аспекта);
• Уровень детальности (высокий или низкий);
• Предметную область (узкая или широкая);
• Предполагаемое использование (как будет использоваться взгляд);
• Пользователя (кто будет использовать взгляд);
• Граничные предположения (предположения по поводу интеграции этого взгляда с другими).

Управляющая информация о взгляде:

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

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

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

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

Наконец, схема Захмана является контекстом для изучения различных взглядов на одну и ту же систему. Схема поддерживает множество взглядов, отражающих разные аспекты конечного продукта. Эти взгляды важны для разных людей и созданы с их точек зрения. Схема представляет всем участникам CASE-проекта контекст для описания информационной системы на понятном и приемлемом для каждого участника языке.

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

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

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

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

Название нижней строки таблицы может варьироваться. Если можно определить одну или несколько точек зрения (например, точку зрения оператора системы), которые будут сильно отличаться от точек зрения проектировщика, разработчика или владельца, то название "функционирование системы" является вполне уместным.

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

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

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

Интеграция схемы Захмана с методами моделирования бизнеса

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

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

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

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

На Рис. 4 перечислены известные нам инструментальные средства (программные продукты или технологические схемы), поддерживающие эти методики.

Рисунок 4. Инструментальные средства.

Каждая из перечисленных на Рис. 4 методик, кроме последней, имеет программную поддержку. Семейство методологий IDEF является альтернативой использования некоторых средств Oracle CASE*Method. Прочерк в строке, соответствующей методике CM, указывает на отсутствие методологических стандартов. Эта методика используется в различных проектах в зависимости от ситуации. Схема применения методики создается в организации, выполняющей заказ по созданию системы, на основе накопленного опыта работы. Построим теперь схему Захмана, основанную на семи перечисленных аспектах и различных точках зрения (рис. 5 и 6).

Рисунок 5. Интегрированная схема архитектуры информационной системы, первые три столбца.

Рисунок 6. Интегрированная схема архитектуры информационной системы ( Окончание )

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

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

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

1. Thomas A. Bruce "Designing Quality Databases with IDEF1X Information Models".
2. R. Barker "CASE Method. Tasks &AMP Deliverables".
3. R. Barker, C. Longman "CASE*Method. Function &AMP Process Modelling"

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме Computer Associates