Архитектурные шаблоны проектирования

Записаться

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

Лекция 6 посвящена аспектам проектирования. В ней мы рассмотрим архитектурные шаблоны проектирования и аспекты, необходимые для того, чтобы создание и использование шаблонов проектирования приносило выгоду всем ролям, заинтересованным в них. Архитектурные шаблоны проектирования – это вишенка на торте анализа и проектирования. Они помогают создавать приложения, которые будут эффективно решать конкретные бизнес-задачи и за счет этого приносить выгоды и ценность. Архитектурные шаблоны проектирования являются переходной ступенью между best practice и стандартами в области создания востребованных информационных продуктов.

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

Итак, что же такое архитектура? Это сложный, важный и многогранный вопрос. Существует много взглядов и определений. Самое простое из определений: архитектура – это о самом важном; другое: архитектура – это последовательность решений, принятых о развитии продукта в момент создания системы; ну и самое интересное: архитектура – это то, за что увольняют архитектора и руководителя проекта внедрения продукта. С одной стороны, смешно, но с другой стороны – это повод задуматься о том, что это за понятие и для кого оно нужно, кто является основным заинтересованным лицом в архитектуре. Архитектура – это детище архитектора. Под архитектором мы понимаем роль ответственного за проектирование. Эту роль может выполнять отдельный сотрудник или несколько сотрудников, проводящих проектирование. В основе архитектуры находятся требования, которые собираются в результате проведения анализа и сбора требований, после чего требования уточняются, дополняются и становятся полноценным макетом или чертежом, на который нанизывается код. Затем, этот каркас превращается в полноценный продукт – систему, которая выполняет определенные задачи и помогает в достижении ценности для заказчиков. По ходу разработки продукта мы можем перемещаться между требованиями, каркасом и продуктом для уточнения тех аспектов, которые важны для создаваемого продукта.

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

Но такие подходы и архитектурные решения нужны не всегда и не всем. Если мы говорим о создании именно таких систем, то компании берут на себя ответственность построить определенную среду, цифровую культуру, в которой будет возможным создавать эффективные цифровые продукты. Наиболее популярный, формализованный и хорошо себя зарекомендовавший подход, описывающий, как достигнуть обозначенных целей, – Scaled Agile Framework (SAFe). Это подход масштабирования Agile для больших организаций. В нем есть четыре основных уровня: уровень работы команд, уровень программ, уровень больших решений, а также уровень набора проектов, которые необходимы для развития цифровых продуктов компаний. На первом уровне – уровне разработки продуктов – находится непосредственная тактическая деятельность, которая необходима для того, чтобы реализовывать конкретные требования. На втором уровне – уровне программ – работают уже с требованиями, которые находятся на более высоком уровне абстракции. Это уровень заказчиков и архитекторов, работающих над формулированием комплексных, взаимосвязанных бизнес-решений. На этом уровне важно обеспечить беспрепятственное движение развивающейся, технически оправданной идеи. Третий уровень – уровень больших решений. Каждое такое решение реализует цели развития организации. Это уровень декомпозиции стратегии на конкретные информационные продукты и цифровые решения. На этом уровне мы показываем то, как будет реализовываться стратегия развития компании. Ну и четвертый уровень – уровень набора проектов. Это самый высокий уровень, где разрабатывается дизайн и вид организации, которая будет реализовывать все поставленные задачи. Все уровни связаны между собой. Информация транслируется, преобразовывается и циркулирует между ними. На каждом уровне информация должна быть представлена и преобразована в том виде, который будет необходим для данного конкретного уровня. Если мы проведем параллели, то на каждом уровне необходимы требования определенного уровня абстракции, для того чтобы связать их в единую архитектуру.

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

Процесс, которые на практике подтвердил, что он может играть роль такого комплексного производственного процесса, – RUP (Rational Unified Process, универсальный рационализированный процесс). В нем есть три основных уровня, на каждом из которых выполняются действия, необходимые для создания качественных информационных продуктов. Высший уровень – уровень проекта. Это уровень разработки и согласования всех организационных и административных моментов, необходимых для достижения целей. Следующий уровень – уровень производства, на котором используются подходы и активности для сбора правильных требований и представления их в нужном для реализации виде. Следующий и последний уровень – уровень общего языка моделирования, где можно будет представить необходимую информацию в виде, который поможет упростить и ускорить процесс создания конкретного цифрового решения. Этот уровень – уровень унифицированного языка моделирования UML (Unified Modeling Language).

Язык UML стал вехой в развитии процессов производства информационных продуктов, на нем основаны многие современные методы и методологии их создания. В основе этого языка лежат диаграммы, каждая из которых представляет разрабатываемую систему в определенном виде, с определенной перспективы, точки зрения. В совокупности эти точки зрения формируют целостную картину контекста бизнес-информационной среды. Высокроуровнево все диаграммы можно разделить на две категории – диаграммы структуры и диаграммы поведения. Диаграммы структуры описывают объекты, которые важны для моделирования системы. Это ее составные части, основы ее структурного представления. Диаграммы поведения описывают жизненный цикл представленных объектов и то, как они взаимодействуют друг с другом для обеспечения требуемой функциональности. В совокупности мы получаем описание, которое представляет системы, как структурно, так и в динамике.

Диаграммы UML представляют собой строительные блоки. Это сущности, которые формируют создаваемую систему. Кроме этого, диаграммы ложатся в основу спецификаций, которые документируют систему и предлагают определенный путь ее создания и развития. Вместе эти элементы легли в основу создания большинства современных методологий, описывающих программную архитектуру, самая известная, проработанная, формализованная из которых – 4+1, взгляд на создаваемую систему с точки зрения основных стейкхолдеров процесса разработки и внедрения информационных продуктов.

В основе архитектуры 4+1 лежит представление прецедентов, то есть описание основных лиц и систем, задействованных в формировании результатов. Следующее выделяемое представление – логическое. Основными заинтересованными лицами в нем являются аналитики и тестировщики. Это представление описывает общую логику процессов. Как результат мы получаем сформированный словарь терминов и законченное функциональное представление о том, из чего состоит система. Для этого используется диаграмма классов. Следом идет представление процессов. В нем заинтересованы те, кто отвечает за внедрение разрабатываемой системы в определенной бизнес-среде. Это представление помогает с формулированием и обоснованием эффективности, расширяемости и производительности создаваемой и внедряемой системы. Для этих целей используется диаграмма деятельности и последовательности. Далее следует представление реализации, основные заинтересованные лица в котором – программисты и разработчики. Представление реализации помогает управлять процессом производства. Основная диаграмма, используемая для этого представления, – диаграмма реализации. Ну и последнее, четвертое представление – представление развертывания. В нем наиболее всего заинтересованы архитекторы создаваемой системы. Представление развертывания реализуется посредством диаграммы компонентов. Оно определяет топологию системы, принципы ее развертывания, инсталляции и коммуникации элементов между собой. Давайте более подробно поговорим о каждом представлении.

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

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

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

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

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

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

Сегодняшний модуль подошел к концу. Давайте сделаем выводы и подведем локальные итоги. Анализ и проектирование – это неразрывные процессы. Очень сложно сказать, когда заканчивается один из них и начинается другой. Сочетание этих процессов приводит к созданию эффективных цифровых продуктов. Главный артефакт, который получается в процессе результата анализа, – требования, а в процессе проектирования – архитектура. Здание архитектуры выстраивается на фундаменте корректно собранных и представленных требований. Если не работать с требованиями и архитектурой, то создать систему точно получится, но вряд ли она будет надежной и основательной.

Проектирование как отрасль, а архитектура как результат деятельности – развивающиеся направления. Основа современных архитектур заложена RUP и дополнена UML. Рассмотрением отдельных аспектов современных архитектур мы и займемся далее.