Переход от концептуальных моделей к практике разработки востребованных и совершенствуемых программных продуктов

Введение

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

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

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

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

Безусловно, было бы правильно начать с полного и объемного отображения архитектуры по всем канонам современных фреймворков, таких как TOGAF, модель Захмана,view 4+1и пр., но –"усложнить просто, упростить сложно".

Упрощение в начале никому не помешает. Работая в конкретном инструментальном средстве, больше задумываешься о том, как нарисовать, а не о том, что именно надо нарисовать.

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

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

Формы представления архитектуры

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

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

Начать можно с четырехуровневого набора абстракций и соответствующих им видов диаграмм:

• Классы. Диаграмма классов представляет собой одноименную диаграмму семейства UML. Она необходима для разработчиков программного обеспечения. С ее помощью визуализируются требования и представляются структурные и поведенческие шаблоны проектирования.

Диаграммы классов создаются при логическом проектировании информационных систем. Они служат для:

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

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

• Контейнеры. На диаграмме этого типа изображают основные программные узлы и некоторые компоненты, но набор этих элементов должен быть ограничен. На этой диаграмме нет сетевых элементов, балансировщиков нагрузки и прочих инфраструктурных деталей. Изображают узлы, которые задействованы для развертывания компонент (web-серверы, серверы приложений, файловые ресурсы, СУБД). Эта схема показывает набор необходимых приложению технологий.

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

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

Эта диаграмма визуализирует поведенческие и порождающие шаблоны проектирования.

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

Цель построения диаграммы – показать окружение системы: пользователей (действующие лица, роли) и другие информационные системы, с которыми осуществляется взаимодействие.

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

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

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