О. Полукеев, Д. Коваль
Введение
Ни одна современная организация не работает без системы или систем какого-либо рода, при помощи которых достигаются цели функционирования этой организации. Информационная система - это комбинация ручных и компьютерных процессов, которые решают поставленные задачи, четко и логично взаимодействуя между собой. В условиях современной конкурентной экономики, использование развитых информационных систем помогает организациям занимать лидирующие позиции в их бизнесе.
В свете вышесказанного с каждым днем увеличивается интерес к задачам, связанным с проектированием и построением информационных систем. Существует множество подходов к решению этих задач. Большинство подходов опирается на инструментальные средства, позволяющие автоматизировать создание системы. Поэтому деятельность такого рода получила название CASE (Computer Aided Software Engineering). Задача по созданию информационной системы делится на несколько подзадач. Это разделение зависит от применяемого подхода, но в любом из них всегда присутствуют два действия. Первое - сбор информации и моделирование бизнеса, второе - построение архитектуры будущей системы, что является важным шагом на пути к ее созданию. При моделировании бизнеса рассматриваются три аспекта: объекты, с которыми оперирует бизнес; процессы, которые он выполняет; события, управляющие изменениями процессов и объектов. Соответственно, можно определить три типа моделирования: информационное, функциональное и событийное.
Целью настоящей статьи является формализация представления архитектуры проектируемой информационной системы. Рассматривается схема Захмана, предназначенная для формирования взгляда на архитектуру информационной системы с точки зрения участников ее разработки. Предлагается аналогичная схема, в которой информационная система рассматривается в терминах различных подходов к моделированию бизнеса. Схема позволяет осознать место каждого из таких подходов в создании информационной системы, а также определить границы деятельности каждого из ее создателей.
Методики моделирования
В этом разделе описывается та часть подхода Р. Баркера к проектированию информационных систем, которая соответствует методикам моделирования бизнеса. Подход носит название "CASE*Method". Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время, как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре. Эти модели должны как можно меньше зависеть от известных информационных технологий. Система должна быть открыта в сторону введения новых процедур, например, производства, продаж, управления или учета.
Требования должны моделироваться и определяться настолько общим способом, насколько это возможно; функциональные потребности должны определять что делается, а не как или кем. Структура данных должна быть рассчитана на изменения в организационной структуре и на текущие и ожидаемые исключения и ограничения. Приведенная на Рис. 1 диаграмма иллюстрирует несколько главных технологий моделирования, а также места их пересечения. Каждая из этих моделей реального мира должна соответствовать контексту общего направления бизнеса, которое определяется его задачами, приоритетами и критическими для успеха факторами.
Рисунок 1.Типы моделирования.
Приведем таблицу, иллюстрирующую использование упоминающихся на рисунке методов на разных стадиях развития системы (Рис. 2). Стоит упомянуть, что как корпоративная, так и государственная политика меняется время от времени, так что определение потребностей бизнеса не должно учитывать политические аспекты. Их поддержка должна быть обеспечена на уровне разработки. Очевидно, существует предел гибкости системы. Если организация, с которой вы имеете дело, примет решение о переориентации с банковской деятельности на страхование и недвижимость, маловероятно, что можно будет использовать тот же набор требований.
Методы
|
Уровень бизнеса
|
Системный уровень
|
Программно/ процедурный уровень
|
Функциональная иерархия
|
О
|
о
|
о
|
Анализ состояний
|
Н
|
о
|
н
|
Диаграммы потоков данных
|
Н
|
о
|
н
|
Событийное моделирование
|
Н
|
о
|
о
|
Функциональная логика
|
О
|
о
|
н
|
о - обязательное использование
н - не обязательное, но возможное использование
Рисунок 2. Таблица использования методов моделирования.
Схема Захмана
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Захмановская схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов. Эти три аспекта: данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками.
Архитектурное представление - это ячейка таблицы, соответствующая пересечению выбранного столбца и выбранной строки. Например, с точки зрения разработчика (технологическая модель) информационное архитектурное представление (данные) - это проект структуры данных. Взгляд какого-либо лица - это совокупность ячеек в пределах одной строки (точки зрения), то есть совокупность архитектурных представлений с выбранной точки зрения, соответствующая выбранным аспектам системы.
Захман определяет архитектуру как представление конечного продукта (в данном случае информационной системы) с точки зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусируете внимание, вы видите архитектуру системы по-разному. В следующих пяти разделах приводится более развернутое описание подхода Захмана.
Рисунок 3. Схема Захмана.
Точки зрения
Точки зрения отражают значение и области ответственности заинтересованных лиц в процессе создания системы. Заказчик видит систему с точки зрения общих стратегических и тактических аспектов. Эти аспекты могут лежать в очень широкой области (бизнес в целом или, напротив, его часть) и не всегда могут быть определены точно. Архитектурные представления, соответствующие точке зрения заказчика, находятся в двух верхних строках таблицы. Начальное планирование бизнеса и анализ обычно определяют первые уровни детализации для этих архитектурных представлений. Определенно установленные цели бизнеса и его требования к системе полностью детализируют каждое из представлений.
Представления проектировщика, несмотря на то, что рассматривается одна и та же система, существенно отличаются от представлений заказчика, причем не только дополнительными деталями. Представления проектировщика - это проект системы, обеспечивающей удовлетворение требований, которые, в свою очередь, описываются представлениями заказчика. Во многом представление проектировщика добавляет точность, необходимую для тех, кто будет реализовывать систему, но представления проектировщика и заказчика остаются независимыми от технологий, которые будут использоваться при реализации. Структурный анализ, информационное моделирование и некоторые виды прототипирования являются методами, которые могут быть использованы для формирования архитектурного представления проектировщика. Точке зрения проектировщика соответствует третья строка в схеме Захмана.
Проекты, связанные с созданием систем, наиболее успешны, когда компоненты каждого из технологически независимых взглядов, соответствующие данным, функциям и сетевой структуре (три верхних строки) разрабатываются одновременно командой, хорошо понимающей бизнес и имеющей опыт в разработке приложений и сетей, а также в администрировании данных. Хотя каждый участник может представлять свою точку зрения (заказчик или проектировщик) или фокусироваться на своих аспектах (данные, функции или сети), каждый вносит свой набор знаний. Эти наборы знаний в совокупности дают хорошую общую картину требуемой системы. В достаточной степени проектировщики должны понимать точку зрения заказчика и наоборот. Заказчик и проектировщик не могут развивать свои взгляды независимо. Физическое воплощение логических требований зависит от характеристик аппаратно-програмной базы, выбранной для реализации системы. В отличие от желаемых логических связей, реальные связи зависят от физических ограничений. Таким образом, необходимо знать, что мы хотим, перед тем, как делать вывод о невозможности чего-либо. Технология ограничивает решения задач, а не их условия.
Технологические соображения начинают играть роль при формировании точки зрения разработчика. Взгляды заказчика и проектировщика отражают потребности бизнеса. Взгляд разработчика отражает множество решений, ограниченных технологией, временем и стоимостью. Точки зрения разработчика соответствуют четвертой и пятой строкам в схеме. Как и ранее, это не просто следующий уровень детализации взглядов проектировщика. Они представляют сдвиг точки зрения с логического уровня (требования) на физический уровень (решения).
Существует еще одна отдельная точка зрения оператора системы. Деятельность оператора - это, с одной стороны, ежедневная поддержка работоспособности системы и ее мониторинг, с другой - повседневное использование системы в бизнесе. Точка зрения оператора представлена последней строкой схемы.
Важно помнить, что строки схемы представляют разные точки зрения, а не разные уровни детальности представления. Для каждой ячейки таблицы может быть сделано многоуровневое описание. Необходимо понимать, что могут быть ситуации, в которых важно понятие взгляда, то есть совокупности архитектурных представлений, находящихся в пределах одной строки. Разным строкам соответствует разное понимание предмета. Чтобы сформировать взгляд, отражающий другую точку зрения, необходим некий переход.
Аспекты
Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам "что", "как" и "где", относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.
Колонка данных соответствует вопросу "что". В строительной промышленности, например, она соответствует списку материалов и частей, используемых при строительстве здания, и взаимосвязям между этими частями. Внимание концентрируется на том, из чего строится здание, а не как и где оно строится. Для информационных систем вопрос "что" относится к сущностям данных и их связям.
Колонка функций соответствует вопросу "как". Она описывает, как работают отдельные части системы. В информационных системах функции обычно определяются входами (элементы данных), процессами (преобразования) и выходами (элементы данных). Внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи.
Колонка сетевой структуры соответствует вопросу "где". Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.
Названия строк и столбцов
Схема Захмана является простым, но достаточно мощным средством. Эта мощность особенно хорошо видна при попытке ее расширения. В этом разделе приведены краткие дополнительные соображения о схеме, а также некоторые моменты, о которых следует помнить при ее использовании.
Важно понимать, что схема Захмана не является каким-либо алгоритмом действий, она лишь направляет наши соображения по нужному пути. Благодаря своей простоте, схема позволяет понять, как должна быть спроектирована и разработана информационная система, не только в терминах методов проектирования и разработки, но и в терминах набора элементов системы.
При использовании схемы Захмана требуется четко представлять, что означают строки и столбцы в таблице. В каждой ячейке представлен вид конечного продукта (архитектурное представление) с точки зрения некоторой группы лиц, участвующих в разработке системы. Строки представляют их точки зрения, и хотя процесс разработки системы является последовательным выполнением действий, характерных для каждой из этих групп (от заказчика к проектировщику, от проектировщика к разработчику), Захман выступает против рассмотрения строк как уровней детальности представления.
Важное замечание по поводу архитектурных представлений состоит в том, что все они имеют различную природу. Это не просто набор представлений, уровень детальности которых увеличивается с прохождением каждого нового этапа. Уровень детальности - это независимая переменная, меняющаяся внутри каждого архитектурного представления.
Здесь используются следующие термины описания строк. Строка является точкой зрения. Точка зрения отражает область интереса или ответственности группы заинтересованных лиц. Все точки зрения относятся к одному и тому же продукту. Они согласуются с понятием взгляда заказчика, проектировщика и разработчика. Таким образом, точки зрения разных участников проектной группы различаются. Взгляд охватывает часть ячейки, всю ячейку или несколько ячеек в пределах одной строки. Взгляд может быть порожден любой точкой зрения (хотя он может быть шире или уже по размеру предметной области) и может быть представлен на любом подходящем уровне детальности. Взгляд отражает интересы конкретного участника проекта, ограниченные рамками выбранных аспектов.
Характеристика взгляда состоит из двух частей:
Описание взгляда, включающее:
-
Точку зрения (статус человека, имеющего данный взгляд);
-
Что показывает взгляд (аспект);
-
Техника или язык, описывающий данный взгляд (например, IDEF1X для аспекта данных, IDEF0 или диаграмма потока данных для функционального аспекта);
-
Уровень детальности (высокий или низкий);
-
Предметную область (узкая или широкая);
-
Предполагаемое использование (как будет использоваться взгляд);
-
Пользователя (кто будет использовать взгляд);
-
Граничные предположения (предположения по поводу интеграции этого взгляда с другими).
Управляющая информация о взгляде:
-
Как был разработан взгляд;
-
С кем контактировать для управления изменениями;
-
Статус (насколько взгляд полон и насколько определен);
-
Составные части (например, диаграммы, глоссарии, тенденции, критические для успеха факторы).
Представление предметной области подразумевает представление аспекта. В качестве аналогии рассмотрим процесс фотографирования (получения взгляда) с определенной точки зрения. Когда мы фотографируем автомобиль, пытаемся ли мы сфокусироваться на его составных частях (множестве материалов), на том, как он ездит (процесс), на его форме (связи), или мы пытаемся отразить все эти аспекты на одном о том же снимке? В фотографии, так же, как и в архитектуре, трудно дать детальное представление многих аспектов одновременно с помощью одного взгляда.
Аспект представляется колонкой таблицы. Мы связываем аспект данных с моделями данных, аспект функций с функциональными моделями и аспект сетей - с сетевыми моделями. Иными словами, мы связываем аспекты разных объектов с соответствующими объектными моделями.
Взгляд не может содержать архитектурные представления, находящиеся в разных строках, хотя он может быть шире или уже по количеству аспектов. Тем не менее, может быть произведена трансформация одного взгляда в другой. Под этим понимается преобразование взгляда с одной точки зрения во взгляд с другой точки зрения. Преобразование - это переход от одной строки к другой.
Наконец, схема Захмана является контекстом для изучения различных взглядов на одну и ту же систему. Схема поддерживает множество взглядов, отражающих разные аспекты конечного продукта. Эти взгляды важны для разных людей и созданы с их точек зрения. Схема представляет всем участникам CASE-проекта контекст для описания информационной системы на понятном и приемлемом для каждого участника языке.
Дополнение схемы
И наконец, введем еще несколько аспектов в дополнение к трем, лежащим в основе схемы Захмана. Начальный вид схемы был разработан для представления архитектуры информационной системы с учетом трех ее аспектов, так что естественно рассуждать о том, что произойдет с названиями и описаниями столбцов и строк, когда количество аспектов будет увеличено.
До сих пор мы рассматривали информационную систему, ориентированную на полную автоматизацию, в то время как на самом деле в систему поддержки бизнеса могут входить ручные процедуры, описание и смысл которых должны отражаться в архитектурных представлениях. Поэтому естественно попытаться дополнить схему Захмана аспектами, соответствующими вопросам "кто", "когда" и "почему".
Наилучшим решением было бы использование для столбцов названий "что", "как", "где", "кто", "когда" и "почему", но даже такая схема не будет универсальной. Потеря универсальности может быть большей или меньшей в зависимости от того, насколько конкретный смысл мы вкладываем в каждый из аспектов.
Расширение схемы требует некоторого пересмотра названий строк. Предметная область и моделирование бизнеса остаются в первых двух строках. Если мы определим систему как частично автоматизированную, частично ручную, модель информационной системы трансформируется в модель системы вообще. Поскольку учитываются человеческие и другие ресурсы, технологическая модель становится моделью распределения ресурсов. Детальное представление сохраняет название.
Название нижней строки таблицы может варьироваться. Если можно определить одну или несколько точек зрения (например, точку зрения оператора системы), которые будут сильно отличаться от точек зрения проектировщика, разработчика или владельца, то название "функционирование системы" является вполне уместным.
Выбор хороших названий для столбцов и строк является более важной проблемой, чем может показаться с первого взгляда. Одна из сильнейших сторон захмановской схемы это то, что в ней используются аналогии, а также термины, знакомые различным категориям пользователей (заказчики, проектировщики, разработчики).
Замечания о полноте
При использовании схемы в качестве вспомогательного инструмента необходимо понимать, полностью ли покрывает рассматриваемая схема все архитектурные представления системы. Другими словами, требуется четкое понимание того, все ли аспекты системы покрываются множеством аспектов схемы. Если схема полна, добавление столбца должно выразиться в удалении из всех остальных столбцов аспектов системы, затрагиваемых новым столбцом. Например, если мы добавляем столбец "правила", то все, что касается правил, должно быть исключено из других столбцов; другие столбцы должны быть переопределены, чтобы избежать дублирования информации.
С другой стороны, представляется разумным дополнять схему всякий раз, когда без особых затруднений можно сопоставить некоторому аспекту системы в точности одну колонку схемы.
Интеграция схемы Захмана с методами моделирования бизнеса
Выше мы рассмотрели два подхода к моделированию потребностей бизнеса, необходимому для разработки поддерживающей бизнес информационной системы. В каждом из подходов предполагается использование упомянутых выше технологий моделирования. Рассмотрим различия этих подходов.
В подходе Баркера ИС развивается со временем, в процессе последовательного прохождения различных этапов жизненного цикла системы. Каждому этапу приписан набор методик, обязательных или необязательных для использования.
В подходе Захмана не делается акцент на динамике развития ИС. При переходе от одной строки таблицы к другой меняется лишь точка зрения, с которой рассматривается система, причем эта точка зрения не обязана быть связана с уровнем детальности рассмотрения. В схеме Захмана отражены три аспекта системы, приблизительно соответствующие некоторым методикам моделирования (информационное моделирование, диаграмма потоков данных и т.д.).
Представляет интерес составить схему, аналогичную схеме Захмана, в которой в качестве аспектов при формировании архитектурных представлений используется хотя бы часть методик, представленных на диаграмме Баркера. Три основные части диаграммы: функциональное моделирование, информационное моделирование и событийное моделирование. Их пересечения - диаграммы потоков данных, анализ состояний, информационная динамика и функциональная логика.
На Рис. 4 перечислены известные нам инструментальные средства (программные продукты или технологические схемы), поддерживающие эти методики.
Методики
|
Инструментальные средства
|
Комментарии
|
ФМ
|
FH Diagram
IDEF0
|
Иерархические функциональные модели
|
ИМ
|
ER Diagram
IDEF1X
|
Диаграммы сущность-связь
|
СМ
|
-
|
Четкого стандарта нет
|
ФМ&ИМ
|
DataFlow Diagram
IDEF0
|
Диаграммы потоков данных
|
ФМ&СМ
|
Process Modeller
|
Моделирование процессов
|
ИМ&СМ
|
SSADM. Entity Life History
|
|
ФМ&ИМ&СМ
|
Function Logic
CPN
|
Описана в Oracle CASE*Method
Раскрашенные сети Петри
|
Рисунок 4. Инструментальные средства.
Каждая из перечисленных на Рис. 4 методик, кроме последней, имеет программную поддержку. Семейство методологий IDEF является альтернативой использования некоторых средств Oracle CASE*Method. Прочерк в строке, соответствующей методике CM, указывает на отсутствие методологических стандартов. Эта методика используется в различных проектах в зависимости от ситуации. Схема применения методики создается в организации, выполняющей заказ по созданию системы, на основе накопленного опыта работы. Построим теперь схему Захмана, основанную на семи перечисленных аспектах и различных точках зрения (рис. 5).
|
ИМ
|
ФМ
|
СМ
|
ФМ&ИМ
|
ФМ&СМ
|
ИМ&СМ
|
ИМ&ФМ
&СМ
|
Цели/ Предметная
область
|
Список важнейших объектов бизнеса
|
Список процессов, выполняемых бизнесом
|
Список возможных событий
|
Описание процессов и их входов и выходов
|
Описание функций обработки событий
|
Описание динамики изменений в понятиях
|
Детальное описание функциони- рования бизнес процессов в терминах функций, данных, событий
|
Бизнес модель
|
Диаграмма сущность- связь (ERD)
Сущность= Объект бизнеса;
Связь= Взаимоот- ношение элементов бизнеса
|
Функциональ- ная иерархия (FH) в терминах бизнеса.
Процесс= Процесс бизнеса
|
Временная схема наступления событий.
Событие= Событие бизнеса
|
Матрица Функция бизнеса/ сущность бизнеса (объект)
|
Матрица Функция бизнеса/ Событие бизнеса
|
История изменения Сущностей бизнеса
|
Блок-схема на уровне объектов бизнеса
Блок= Функция Триггер= Событие Переход= Сущность бизнеса
|
Модель ИС
|
Проект базы данных
Сущность= Сущность данных;
Связь= Отношение данных
|
FH в терминах ИС
Процесс= Прикладная функция
|
Схема событий в ИС
Событие= Событие в системе
|
Диаграмма потоков данных
Процесс= Функция; Поток= Сущность данных
|
Диаграмма процесса Процесс= Функция; Событие= Событие в системе
|
История изменения сещностей данных
|
Сеть Петри
Место= Функция; Переход= Событие в системе; Фишка= Сущность данных
|
Техноло- гическая модель
|
Структура базы данных
Сущность= Строка; Связь= Указатель/ Ключ
|
Структурная диаграмма
Процесс= Компьютерная функция (модуль)
|
Структура прерываний
Событие= Запуск модуля реакции
|
Функцио- нальная диаграмма
Функция= Транзакция;
Вход/ Выход= Строка
|
Диаграмма процесса
Процесс= Процедура реакции; Событие= Запуск процедуры
|
График изменения данных
Сущность= Строка; Событие= Реакция
|
Блок схема с учетом результатов модели- рования Петри. Блок= Процедура;
|
Детальное представ- ление
|
Описание структуры данных
Сущность= Поле
Связь=Адрес
|
Описание программы
Процесс= Текст программы
|
Описание программы обработки событий Событие= Запуск программы реакции
|
Программа
Функция= Модуль транзакции; Вход /Выход= Элемент данных
|
Программа Событие= Реакция Функция= Процедура обработки
|
Описание структуры изменения информации по событиям
|
Описание всех модулей ИС
|
Функциони- рование системы
|
Данные
|
Модули
|
Реакция на событие
|
Модуль транзакции (интерфейс)
|
Модуль обработки (интерфейс)
|
Изменение базы данных
|
Модуль ИС
|
Рисунок 5. Интегрированная схема архитектуры информационной системы
Дадим несколько комментариев. При применении модели CPN оптимальность функционирования системы определяется тем, насколько успешно модель применена на стадии разработки системы (собственно на стадии функционирования модель уже не используется). Модель может также применяться в проектах, ограничивающихся стратегическим обследованием. Кроме того, по нашему мнению, возможности модели могут быть расширены путем использования техники сетей Петри. Заметим, что, вообще говоря, применение смешанных методик не всегда обязательно. Это зависит от задач, решаемых в исследуемой организации, а также от технологических возможностей исполнителя.
Использование интегрированной схемы даст возможность применять ее на всех этапах жизненного цикла системы для формирования точек зрения всех участников CASE проекта, причем каждый участник или группа участников проекта получат четкое представление о том, что от них требуется. Предложенная схема, так же, как и схема Захмана не является немедленным руководством к действию. Ее назначение состоит в том, чтобы обеспечить понимание архитектуры информационной системы на разных стадиях разработки и с точки зрения разных участников проекта.
Заключение
Технологии CASE стремительно развиваются. Появляются новые методики моделирования бизнеса, новые инструментальные и программные средства. В реальных проектах по разработке ИС место этих средств далеко не всегда определено однозначно. Построенная схема помогает классифицировать эти средства и находить их место в реальных разработках. Мы не претендуем на полноту и универсальность схемы, но надеемся, что она вызовет как академический, так и практический интерес разработчиков информационных систем.
Достарыңызбен бөлісу: |
