ООО САТУРС- Архитектура информационных систем.
Технологии создания понятных систем
Архитектура информационных систем.

 Содержание и подходы к изучению.

Мадорская Ю.М., к.т.н.,доцент СПбГПУ
А.Н. Тимофеев,  к.т.н., ген. директор ООО "САТУРС

Проектирование информационных систем ведется на разных логических уровнях. При этом решения, принятые на одном уровне, часто ограничивают множество возможных альтернатив на остальных уровнях проектирования. Наиболее полной систематизацией, отражающей логические уровни (срезы) проектирования ИС, является фреймворк Захмана (подробнее http://edu.reqcenter.pro/?p=3644)

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

Чтобы пояснить это, рассмотрим несколько примеров.

Возьмем последний срез схемы Захмана - "Время" и клетку "Базовый план работ". Данный срез определяет требования к режиму функционирования ИС (см. ГОСТ 34.602 п. 2.6.1.1. 4) Требования к режимам функционирования). Какие бывают режимы функционирования? 8х5 - восемь часов, пять дней в неделю. 24х7х365 - непрерывный режим функционирования - 24 часа, семь дней в неделю, круглый год.  Делая выбор в пользу одного или другого режима функционирования мы принимаем важное архитектурное решение. Почему? Это определит структуру компонентов, необходимость системы самодиагностики и реализация функций таким образом, чтобы диагностика могла работать без останова системы, также понадобится и резервирование и самовосстановление в случае сбоев. Опытные проектировщики уже успели прикинуть объем работ, а опытные руководители уже умножили стоимость на 100. Вот так одно короткое, архитектурное проектное решение определяет структуру компонентов и функций будущей системы.

Следующий пример - клетка "Географическое расположение". От того, где географически будет расположена система, зависит какие требования необходимо предъявлять к физическим параметрам каналов связи,  их резервированию, аппаратному и программному обеспечению, организационным и техническим процессам перехода с канала на канал в случае обработки аварийных ситуаций. Кроме того,  география системы определит и требования по обеспечению безопасности доступа к её ресурсам. Для реализации системы  в стенах одного административного здания без выхода во внешние сети и/или Интернет или с выходом потребуется использовать разные наборы компонент. Так, например, для решения задачи обеспечения безопасности в сети Интранет вполне достаточно обеспечения идентификации пользователя по простому паролю и логину и можно  обойтись без шифрования базы данных и данных передаваемых по каналам связи. Тогда как, при реализации той же системы в «облаках» понадобятся и модули криптозащиты каналов связи и баз данных, да идентификация пользователя потребует более жесткой реализации, например на основе внешних криптоключей.

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

Разделение на логические срезы (представления)  позволяет накапливать опыт по каждому слою системной архитектуры и строить типовые модели для каждой клетки схемы Захмана, детализируя ее на следующем уровне.   Чаще всего такие типовые модели называются фреймворками (каркасами) или референсными моделями, при этом схема Захмана является для них общим мета-фреймворком.  Логично, что любой фреймворк более низкого уровня, чем схема Захмана, имеет смысл, если он с одной стороны учитывает особенности определенного класса систем, а с другой стороны обладает некоторой общностью, что позволяет применить его не только в рамках одной системы.

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

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

Какие же фреймворки в области разработки ИС существуют?

По срезу архитектурных каркасов предприятия (Enterprise Architecture Frameworks). Обзоры некоторых из них можно найти на reqcenter.pro:

Их соотношение и маппинг на схему Захмана мы рассказываем на занятиях.

По срезу программных фреймворков, например, фреймворк верхнего уровня - MVC (Model View Controller) или разработанные под какой-либо из языков программирования, например, для php:

На нижнем уровне, при изучении архитектуры ИС, традиционно рассматриваются такие типы архитектур (фреймворков) как трехзвенная/двухзвенная архитектура.

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

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

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

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

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

 

  

  

 

 

Скриншоты из учебного проекта Андрющенко А. (Заказчик - Тимофеев А.Н., консультант- Мадорская Ю.М.)

Архитектура целей с трассировкой целей заинтересованных лиц к целям проекта

Трассировка целей к заинтересованным лицам проекта

Архитектура автоматизируемых бизнес-процессов с трассировкой к функциям системы

Объектная архитектура 

 

Открытые для регистрации программы обучения. 

Любое копирование и публикация материала допускается только с письменного разрешения автора.
Для ссылки на статью правильно использовать:
Мадорская Ю.М., Тимофеев А.Н. Архитектура информационных систем. Содержание и подходы к изучению.  [электронный ресурс]/Ю.М. Мадорская, А.Н. Тимофеев, 2013. — Режим доступа: http://www.saturs.ru, свободный. — Загл. с экрана