Архитектурным проектированием называют первый этап процесса проектирования, на котором определяются подсистемы, а также структура управления и взаимодействия систем.
Подсистема — это система, операции которой не зависят от сервисов, предоставляемых другими подсистемами. Подсистемы состоят из модулей — системных компонентов, предоставляющих один или несколько сервисов для других модулей.
Модели архитектуры могут зависеть от нефункциональных требований к разрабатываемой системе:
- Производительность — за критические операции отвечает как можно меньше подсистем — т.е. используется крупномодульная архитектура
- Защищённость — многоуровневая архитектура системы, наиболее критические элементы защищены на нижнем уровне
- Надёжность — включаются явно излишние компоненты, которые можно изменять не прерывая работу системы
- Удобство сопровождения — архитектура из мелких компонентов, которые можно легко адаптировать под требования предметной области
- Безопасность — за все операции, влияющие на безопасность, должно отвечать как можно меньше подсистем
Contents
- 1 Структурные модели
- 1.1 Репозиторий
- 1.1.1 Плюсы
- 1.1.2 Минусы
- 1.2.1 Плюсы
- 1.2.2 Минусы
- 1.3.1 Плюсы
- 1.3.2 Минусы
- 2.1 Централизованное управление
- 2.2 Управление, основанное на событиях
- 3.1 Объектно-ориентированная модель
- 3.2 Модель потоков данных
- 4.1 Модели классов систем
- 4.2 Базовые модели
Структурные модели [ ]
В статических структурных моделях представлены подсистемы или компоненты, разрабатываемые в дальнейшем независимо.
Мастер-класс «Построение архитектуры бизнес процессов компания в Business Studio» от 20 мая 2021
Репозиторий [ ]
Модель репозитория основана на совместном использовании данных. Все совместно используемые данные хранятся в центральной базе данных, доступной всем подсистемам, каждая из которых имеет также собственную базу данных. Взаимообмен даными между подсистемами происходит с помощью передачи сообщений.
Плюсы [ ]
- Эффективность
- Централизация средств управления данными
- Прозрачность модели совместного использования
- Многозадачность
Минусы [ ]
- Все подсистемы должны быть согласованы с моделью репозитория данных
- Проблема распределённого хранения репозитория
- Сложность перевода уже существующих систем на эту модель
- Одинаковые требования безопасности ко всем подсистемам
Клиент—сервер [ ]
Модель клиент—сервер — это модель распределённой системы, в которой показано распределение данных и процессов между несколькими процессорами. Модель включает три основных компонента:
- Набор серверов, предоставляющих сервисы другим подсистемам
- Набор клиентов, которые вызывают эти сервисы
- Сеть, посредством которой клиенты получают доступ к сервисам
Плюсы [ ]
- Простота добавления новых серверов
- Простота обновления сервисов
Минусы [ ]
- Высокие требования к пропускной способности сети
Абстрактная машина [ ]
Модель абстрактной машины организует систему в виде набора уровней, каждый из которых предоставляет свои сервисы. Каждый уровень определяет абстрактную машину, машинный язык которой (сервисы) используется для реализации следующего уровня абстрактной машины (ср. с Java-моделью исполнения программ).
Модели ИТ-архитектуры для крупных холдингов · М.Кантарович, А.Чернов.
Плюсы [ ]
- Пошаговое развитие системы
- Кросс-платформенность
Минусы [ ]
- Сложная структура
Модели управления [ ]
Разработчик архитектуры должен организовать подсистемы согласно некоторой модели управления, которая дополняла бы имеющуюся модель структуры. В моделях управления проектируется поток управления между подсистемами.
Централизованное управление [ ]
Одна из подсистем полностью отвечает за управление, запускает и завершает работу остальных подсистем. Различают два класса централизованного управления:
- Модель вызова-возврата — применима только в последовательных системах и реализует передачу управления «сверху-вниз»
- Модель диспетчера — применяется в параллельных системах, в которых системный компонент (диспетчер) координирует другие процессы системы, протекая параллельно с ними
Управление, основанное на событиях [ ]
Вместо одной подсистемы, ответственной за управление, на внешние события может отвечать любая подсистема. События, на которые реагирует система, могут происходить либо в других подсистемах, либо во внешнем окружении системы. Здесь также разделяют два класса моделей:
- Передача сообщений — событие представляет собой передачу сообщения всем подсистемам; любая подсистема, которая обрабатывает данное событие, отвечает на него
- Прерывания — используются в системах реального времени
Модели модульной декомпозиции систем [ ]
После этапа разработки системной структуры следует этап декомпозиции подсистем на модули. На этом этапе распространены две модели проектирования.
Объектно-ориентированная модель [ ]
В этой модели система структурирована в виде совокупности слабо связанных объектов с чётко определёнными интерфейсами. Объекты вызывают сервисы, предоставляемые другими объектами.
Модель потоков данных [ ]
Модули в данной модели выполняют функциональные преобразования. Данные, поступающие на вход системы, проходят через все преобразования и достигают выхода системы.
Проблемно-зависимые архитектуры [ ]
Наряду с основными моделями, используются архитектурные модели, характерные для конкретной предметной области приложения. Эти модели называются проблемно-зависмыми архитектурами.
Модели классов систем [ ]
Модели классов систем отображают классы реальных систем, вобрав в себя основные характеристики этих классов. Как правило, модели классов встречаются в системах реального времени. Модель компилятора — наиболее известный пример этой модели.
Базовые модели [ ]
Базовые модели представляют собой идеализированную архитектуру, в которой отражены все особенности, присущие системам, работающим в данной предметной области. Примером такой архитектуры может служить модель OSI.
Базовые модели обычно не рассматриваются в качестве методов реализации; их основное назначение — служить эталоном для сравнения различных систем в какой-либо предметной области.
Ссылки [ ]
- А.М. Гудов, С.Ю. Завозкин, С.Н. Трофимов — Технология разработки программного обеспечения
Источник: gos-it.fandom.com
Моделирование бизнеса и архитектура информационной системы. Модель Захмана
В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Дж.
Захман определил архитектуру предприятия как «набор описательных представлений (моделей), которые применимы для описания предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)». Термин «архитектура» здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как, например, здание. Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). В исторически сложившемся переводе названия на русский язык используется именно термин «модель», отражающий, прежде всего, четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала » framework » как «методики».
Модель Захмана преследует две основные цели – с одной стороны, логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции «жизненного цикла». На каждом из этапов жизненного цикла рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив.
Исторически модель Захмана впервые была создана именно для ИТ‑систем [1]. Этот подход в дальнейшем был обобщен для рассмотрения не только ИТ‑систем, но и для описания предприятия в целом, так что предложенная модель может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рис. 3.1 (в русском переводе [2]). Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Рис. 3.1. Модель Захмана
Перспективы (строки в таблице) могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки («особняк» для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома.
Следующий уровень «логической модели» уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка » Контекст » соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень » Модель предприятия » соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень » Модель системы (Логический уровень)» – это уровень, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.
– используемые данные (что?)
– процессы и функции (как?)
– места выполнения этих процессов (где?)
– организации и персоналии–участники (кто?)
– управляющие события (когда?)
– цели и ограничения, определяющие работу системы (зачем?)
Основные правила заполнения таблицы следующие:
· каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»);
· порядок следования колонок несущественен;
· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
· базовые модели для каждой из колонок являются уникальными;
· соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
· заполнение клеток должно проводиться последовательно «сверху вниз», попытка пропуска одного из рядов является, скорее, «шаманством» (в том плане, что нельзя создать хорошо работающую систему, «перепрыгнув» определенные уровни ее описания на этапе проектирования).
Рассмотрим заполнение строк.
Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – «Мотивация»). Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Рассмотрим теперь, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Напомним, что порядок расположения колонок в таблице, вообще говоря, произволен.
Первая колонка отвечает на вопрос » ЧТО?» и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе.
На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы «сущности-связи» (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Пятый уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т. п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.
Колонка функций (ответ на вопрос » КАК?») предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос » ГДЕ?») определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов.
На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети.
Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое «middleware»), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос » КТО?», определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос » КОГДА?» и определяет временные характеристики бизнес-процессов и работы системы. Детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов, – например, требование ко времени оформления сделки (уровень 2).
На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы (триггеры) или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. Наконец, на 6-м уровне – фактическая история функционирования системы.
Последняя колонка (» ПОЧЕМУ?» или «ЗАЧЕМ?») служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.
Важным принципом модели Захмана является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов, например, прямой переход от описания модели бизнес-процесса к физической реализации системы требует «привлечения магии» и почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя.
Рассмотрим, как может использоваться модель Захмана на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления «белых пятен» и координации работ.
Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. В‑третьих, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих «унаследованных» компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.
У модели Захмана имеются недостатки. Один из них заключается в том, что при применении модели на практике возникают определенные трудности, связанные с отсутствием «встроенного механизма» распространения изменений между элементами таблицы. Действительно, предположим, что изменилась организация процесса поставок в компании (схема логистики). Это потребует отслеживания «вручную» всех взаимосвязей, проверки актуальности и внесения изменений в модели и другие артефакты во всех потенциально «затрагиваемых» ячейках.
Другим ограничением модели является отсутствие рассмотрения системы в динамике. Действительно, каждый элемент таблицы может содержать как описание существующего состояния («как есть»), так и целевого, а также всех промежуточных состояний. При этом сама модель не содержит средств для четкого разделения этих различных «временных срезов».
Кроме модели Захмана известны и другие модели архитектуры предприятия [2].
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Элементы Архитектуры предприятия. Бизнес-архитектура и архитектура информации
Модель содержит конкретные данные, определяющие характеристики системы. Эти данные используются как некоторое представление реальной системы в целях ее концептуального осмысления, описания процессов обмена информацией с этой системой, понимания того, как система работает с точки зрения конечных пользователей.
В общем, модели можно классифицировать по различным критериям, например:
- формальные (использующие общепринятые правила, нотации и средства) и неформальные ;
- количественные – позволяющие производить численные оценки и проверки, и качественные, предназначенные для понимания поведения и структуры системы;
- описательные – предназначенные только для восприятия человеком, или исполняемые, позволяющие исследовать их поведение и использовать полученные результаты для выводов об исходной системе.
Примерами качественных и описательных моделей являются:
- текстовые, использующие либо одну из формальных грамматик (пример – так называемые формы Бэкуса ), либо обычный текст;
- визуальные модели, представляемые в виде диаграмм с определенной нотацией. Наиболее популярным языком для описания таких моделей программных систем в последнее время стал UML. Заметим, что, вообще говоря, даже эскизное изображение структуры или хода процесса, не обязательно соответствующее какому-либо стандарту, также может рассматриваться как модель – лишь бы оно могло быть использовано в нужном контексте для анализа или обсуждения проблемы.
Примерами количественных моделей могут служить:
- математические модели, которые могут быть описаны системами уравнений. Решение уравнений может быть в простейшем случае найдено в аналитической форме, в более сложных случаях применяются различные численные методы. Достаточно часто применяются электронные таблицы, с помощью которых могут быть проведены исследования типа «что – если». В зависимости от используемых средств эти модели могут быть исполняемыми или чисто описательными;
- динамические исполняемые модели, которые строятся с использованием специализированных программных или программно-технических средств и позволяют исследовать поведение описываемых ими объектов в различных внешних условиях. Модели последнего типа относятся к числу наиболее сложных и часто применяются на этапе выбора архитектуры сложных систем со многими элементами и связями, особенно когда поведение элементов описывается нелинейной или случайной функцией. Хотя разработка такой модели и проведение исследований требуют определенных затрат времени и ресурсов, во многих случаях применение таких моделей оказывается экономически обоснованным (см 6.7), а в отдельных областях, связанных с военными, космическими, ядерными и другими объектами такого рода – единственно возможным.
К сожалению, возможных моделей для описания деятельности предприятия как системы существует множество, и очень часто в организации происходит достаточно разрозненный процесс моделирования. Например, для описания бизнес-архитектуры используются модели, включающие представления о бизнес-объектах и логике (например, декомпозиция процессов, сценарии использования, взаимосвязи между объектами).
На уровне прикладных систем используются, например, диаграммы «сущность-отношения», карты иерархии управления, диаграммы потоков данных, на уровне инфраструктуры – топология сетей, инфраструктурные шаблоны и т.д. Консолидация таких различных представлений – то есть понимание того, как все эти многочисленные модели связаны между собой, – является весьма сложной задачей. Например, какова связь между одним артефактом на некотором высоком уровне абстракции (к примеру, модель бизнес-процесса) с другим артефактом на более детальном уровне (к примеру, стандарт на сервера приложений). Эта проблема может свести на нет пользу от моделирования. Поэтому одной из важных задач любой методики описания архитектуры становится логическая организация моделей, описывающих единую архитектуру предприятия.
Предметом нашего анализа является архитектура предприятия в целом, которая представляет собой сложную систему взаимодействующих ИТ-ресурсов – их структурных компонент и взаимодействий между ними. Архитектура включает в себя стандарты, которые задают границы и направление работы разработчиков при создании и модификации систем. Как и во всех сложных системах, изменения в одной области могут приводить к изменениям во многих других областях.
По большому счету, разработка архитектуры помогает достичь две взаимосвязанные цели: обеспечивает понимание структур, объектов и связей между ними в достаточно неоднородном и обширном наборе информационных систем предприятия, а также поставляет сведения, необходимые для обеспечения интеграции процессов, систем и информации. Поэтому и процесс создания моделей и моделирования можно рассматривать с двух точек зрения: моделирование с целью обеспечить понимание и моделирование для интеграции.
Первым шагом в плане создания высокоуровневых моделей предприятия является создание моделей бизнес-процессов. Мы более подробно рассмотрим этот аспект в разделе, посвященном бизнес-архитектуре.
Разработка моделей для различных доменов (предметных областей) архитектуры является итерационным процессом, который связан с рассмотрением различных перспектив (уровней абстракции), а также связей между моделями отдельных доменов архитектуры. Например, на самом верхнем уровне описания контекста архитектуры для описания архитектуры информации могут использоваться списки бизнес-сущностей, таких как «счет», «клиент» и т.д., для архитектуры прикладных систем будет достаточно иметь список основных бизнес-процессов, а для технологической архитектуры – информации о местах расположения бизнеса.
По мере того, как создаются более детальные описания доменов архитектуры, будут разрабатываться более детальные модели бизнес-процессов, вместо списка бизнес-сущностей будут создаваться семантические, логические и физические модели данных .
Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют «взглядам» на предприятие различных категорий людей. Процесс условно отображен в виде следующей таблицы, в которой в качестве иллюстрации приведены примеры возможных моделей для каждого домена архитектуры и каждого уровня абстракции [4.7]. Во-первых, заметим, что, по сути, это соответствует модели архитектуры Захмана, которая описана в 5.2. А во-вторых, с одной стороны, это список не является исчерпывающим, а с другой, на уровне описания архитектуры предприятия в целом, могут отсутствовать модели «нижних» уровней абстракции.
Вообще говоря, создание информационных систем состоит в постепенном уточнении моделей, т.е. в «заполнении» элементов этой матрицы, начиная с левой верхней области (в этой части, по сути, формулируются и бизнес-требования), в направлении правой нижней области (где, в конце концов, код программ размещается на серверах центров обработки данных). Но тонкость заключается в том, что на самом деле это двунаправленный процесс, связанный с обратным движением в направлении более высоких уровней абстракции, и требуется синхронизация этих двух процессов.
Для описания предприятия, его бизнес-процессов, информационных систем и информации на каждом уровне абстракции могут использоваться как динамические, так и статические модели . Динамические модели описывают процессы информационного обмена, пересылку сообщений между объектами, в то время как статические модели рассматривают структуры и взаимосвязи между объектами.
- Классы бизнес-процессов (группа процессов, имеющих много общих активностей)
- Список бизнес-процессов
- Список бизнес-сущностей – объектов, важных для бизнеса («клиент», счет»)
- Связи между сущностями ( бизнес-объектами )
Источник: intuit.ru