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

• Введение
• Методики моделирования
• Схема Захмана
• Точки зрения
• Аспекты

Введение

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

В свете вышесказанного с каждым днем увеличивается интерес к задачам, связанным с проектированием и построением информационных систем. Существует множество подходов к решению этих задач. Большинство подходов опирается на инструментальные средства, позволяющие автоматизировать создание системы. Поэтому деятельность такого рода получила название CASE (Computer Aided Software Engineering). Задача по созданию информационной системы делится на несколько подзадач. Это разделение зависит от применяемого подхода, но в любом из них всегда присутствуют два действия. Первое - сбор информации и моделирование бизнеса, второе - построение архитектуры будущей системы, что является важным шагом на пути к ее созданию. При моделировании бизнеса рассматриваются три аспекта: объекты, с которыми оперирует бизнес; процессы, которые он выполняет; события, управляющие изменениями процессов и объектов. Соответственно, можно определить три типа моделирования: информационное, функциональное и событийное.

Целью настоящей статьи является формализация представления архитектуры проектируемой информационной системы. Рассматривается схема Захмана, описанная подробно в [1] и предназначенная для формирования взгляда на архитектуру информационной системы с точки зрения участников ее разработки. Предлагается аналогичная схема, в которой информационная система рассматривается в терминах различных подходов к моделированию бизнеса. Схема позволяет осознать место каждого из таких подходов в создании информационной системы, а также определить границы деятельности каждого из ее создателей.

В этом разделе описывается та часть подхода Р. Баркера к проектированию информационных систем, которая соответствует методикам моделирования бизнеса. Подробно подход Баркера описан в [2]. Подход носит название "CASE*Method". Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время, как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре. Эти модели должны как можно меньше зависеть от известных информационных технологий. Система должна быть открыта в сторону введения новых процедур, например, производства, продаж, управления или учета.

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

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

о - обязательное использование

н - не обязательное, но возможное использование

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

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

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

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

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

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

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

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

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

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

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

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

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

Колонка сетевой структуры соответствует вопросу "где". Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.

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

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