Документы в архитектуре — Мир ПК

Документы в архитектуре

Архитектурное документирование. Что и Как? Начало

Доброго настроения духа, Уважаемые коллеги!

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

Введение

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

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

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

Архитектура и программный продукт требуют целенаправленного тренда развития и не приемлют «костыльного» к ним отношения. Оптимально организованное документирование методик, архитектуры в целом и её составных уровней, функциональности, организационных требований к бизнес процессам программного продукта позволят создать и в дальнейшем совершенствовать и развивать конкретный программный продукт. Соблюдение описанного пути будет претворяться с условием поддержки надлежащего уровня качества, в соответствии с актуальным состоянием конкретного бизнеса и видением руководства своей позиции на рынке определенного бизнес домена.

• Что документировать?
• Каким именно образом?
• Что включать в документы?
• Что учитывать в качестве факторов, которые не соприкасаются непосредственно с программным продуктом и его архитектурой, но при этом оказываю на неё сильно влияние?

будет посвящена наша сегодняшняя и несколько следующих статей.

Уровни архитектуры программного обеспечения

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

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

Для цельного понимания понятия архитектура программного продукта следует выделить следующие уровни:

• Уровень приложения;
• Уровень данных;
• Уровень информации;
• Интеграционный уровень;
• Уровень безопасности;
• Сетевой уровень;
• Уровень платформы;
• Уровень системы;

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

• Управление доступными ресурсами/активами;
• Управление изменениями;
• Управление событиями;
• Управление событиями;
• Обеспечение уровня предоставления сервиса для бизнес процессов;

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

К примеру, уровень управления данными состоит из следующих дисциплин:

• СУБД;
• Файловые системы;
• Конкретные реализации модели данных;
• И т.д.;

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

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

Они включают в себя необходимые сетевые протоколы, продукты, конфигурации, которые специфичны для каждой отдельной ситуации создания архитектуры. Примерами продуктовых компонентов для дисциплины СУБД являются:

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

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

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

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

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

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

Традиционно выделяют 4 взаимосвязанные субархитектуры, которые составляют целостную информационную архитектуру не только отдельных программных продуктов, но и информационной системы определенной компании:

Бизнес-архитектура:

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

Архитектуру информации:

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

Технологическая архитектура:

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

Архитектура приложений/составных компонентов:

Если мы говорим о архитектуре организации, то в этой главе рассматривается архитектура отдельного программного продукта, который является составной частью этой организационной системы и то, как он влияет на смежные с ней системы и на «систему систем». Если же мы обсуждаем отдельный программный продукт, то тут выделяют составляющие его компоненты;

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

• Функциональный признак:
  • Страхование /бухгалтерский учет/интеграционное взаимодействие и т.д.;
• Тематический признак:
  • услуги гражданам/внутренние процессы и т.д.;

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

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

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

Итоги

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

Процесс разработки архитектур: цели и задачи, общая схема

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

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

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

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

Ниже описаны этапы каждой итерации процесса разработки и обновления архитектуры, которые следуют, в основном, рекомендациям META Group. Характерными для этого подхода элементами описания архитектуры являются такие документы, как Общее видение и Концептуальная архитектура. Заметим, что, даже в случае выбора какой-то другой методики, вам скорее всего придется создавать аналоги этих документов. Каждая итерация включает:

• Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре).
• Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр.
• Этап 3: Разработка или уточнение Плана реализации.

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

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

Этап 1: Разработка Общего видения архитектуры

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

Основными элементами Общего видения являются:

• описание технологических тенденций, важных для предприятия;
• идентификация бизнес-требований и стратегий;
• идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий;
• идентификация требований к архитектуре предприятия в целом.

Этап 2: Параллельная разработка Концептуальной архитектуры и частных Архитектур предметных областей

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

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

Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура.

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

Этап 3: Разработка Плана реализации

Этап 3 включает в себя следующие два шага:

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

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

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

При организации архитектурного процесса может оказаться полезным использование упоминавшегося ранее стандарта IEEE 1471 . Этот стандарт определяет рамочную модель, ориентированную на разработку комплексов с гарантированной надежностью, требуемой, например, в военных, космических и авиационных системах. Такая модель включает в рассмотрение понятия «участника» ( stakeholder ) и его представлений о целевой системе. На первый взгляд это может показаться тривиальным – ведь создание любой системы, в том числе и с использованием классических подходов, начинается со сбора, описания и анализа требований. Принципиальным в данном случае является признание того факта, что в подавляющем числе случаев на практике совокупность требований является, с одной стороны, неполной, а с другой – противоречивой.

Документы в архитектуре

Архитектура «документ/вид» (иногда она еще называется «документ/представление» ) позволяет связать данные их представление на экране. Она реализована в виде классов, котопы создаются мастером AppWizard . Дадим общую характеристику этой архитектуры.

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

Такое логическое разделение данных и их визуального представления позволяет отображать документ разными способами, связав eго с несколькими представлениями. Например, в Microsoft Word доступны три вида отображения одного и того же документа: обычный, разметка страницы, структура документа. Кроме того, изменения, внесенные в одном представлении, отражаются во всех других.

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

Архитектура «документ/вид» упрощает печать и предварительный просмотр данных; при этом применяется та же функция ображения, что и для вывода информации на экран. В этой архитектуре предусмотрены вспомогательные средства для хранения и открытия документов. Данный процесс, называемый сериализацией , позволяет сохранять данные в формате объекта, используемого Вашим приложением, а также в формате любого другого бъекта, унаследованного от класса CObject .

Архитектура «документ/представление» имеет большое значение, так как обеспечивает каркас множеством возможностей для работы с документами приложения. Однако можно работать с MFC , не применяя ее, так как ее использование ведет к определенному падению производительности и увеличению размера приложения.

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

AppWizard способен генерировать каркас приложения на основе архитектуры «документ/вид», который в дальнейшем можно изменить.

Этот каркас реализует документы и представления средствами классов, производных от CDocument и CView . Для работы приложения кроме них еще необходимы классы CWinApp , CFrameWnd и CDocTemplate .

В таблице 1 описаны все объекты и связанные с ними классы приложения на базе архитектуры «документ/вид».

Объекты и связанные с ними классы приложения на базе архитектуры «документ/вид»

Документ	Производный от CDocument . Определяет данные приложения
Вид (Представление)	Производный от CView . Служит для отображения данных и взаимодействия с пользователем
Окно-рамка	Производный от CFrameWnd . Представления отображаются внутри таких окон. В SDI -приложениях (однодокументных приложениях) являются главным окном
Шаблон документа	Производный от CDocTemplate . Управляет созданием документов, представлений и окон. Один класс шаблона документа отвечает за все открытые документы одного типа
Приложение	Производный от CWinApp . Управляет всеми объектами приложения и определяет его действия, в частности, инициализацию и очистку памяти

Таблица 1. Объект Класс и его назначение

Все объекты приложения на базе архитектуры «документ/вид» реагируют на действия пользователя совместно, будучи связаны между собой командами и сообщениями.

Дадим краткую характеристику некоторых из перечисленных объектов.

Шаблон документа

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

При создании шаблон документа связывает класс документа с ресурсами (меню, значками и т. д.), окном-рамкой и представлением. Шаблон добавляется к приложению средствами функции CWinApp::AddDocTemplate() .

В SDI -приложении пользователь просматривает документ и работает с ним с помощью представления, находящегося в главном окне, производном от CFrameWnd . На рисунке 1 показаны взаимосвязи объектов SDI -приложения.

MDI -приложение использует объект CMult > В следующем примере показано создание объекта CMult > Документ представлен в приложении классом, производным от CDocument . Он сохраняет и загружает данные, а также управляет ими. В нем есть функции для доступа к этим данным и работы с ними. Для взаимодействия между документами и представлениями каждый объект документа содержит список связанных с ним представлений, доступ к которым можно получить через функции CDocument::GetFirstViewPosition() и CDocument::GetNextView() .

Класс CDocument содержит функцию UpdateAllViews() , которая передает всем связанным с документом представлениям уведомление о необходимости перерисовки окна (для этого она вызывает функцию CView::OnUpdate() ).

Приложение должно обновлять представления при любом изменении данных, способном повлиять на их отображение.

Вид (Представление)

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

Фукнция GetDocument() из класса CView позволяет получить указатель, связанный с представлением объекта документа.

В заключение приведем перечень файлов, которые создаются AppWizard при создании SDI -приложения с именем Hello .