Опубликован: 12.10.2017 | Доступ: свободный | Студентов: 843 / 130 | Длительность: 07:43:00
Лекция 8:

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

< Лекция 7 || Лекция 8: 123
Аннотация: После того как мы приобрели необходимые теоретические знания и навыки в отношении шаблонов проектирования, настало время перейти к исследованию их прикладного значения, которое способствует разработке востребованных и совершенствуемых информационных систем. Именное прикладная ценность от использования паттернов проектирования при создании программных продуктов формирует ценность этой области деятельности. Сами по себе шаблоны проектирования –не более чем объект исследования цифрового мира высококачественных, конкурентных программных продуктов. В комплексе с экономическим эффектом от применения приложений в деятельности современных и успешных компаний обосновывается значимость шаблонов проектирования в отдельности и в архитектурной совокупности.

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 7 || Лекция 8: 123