Принципы и типы проектирования

Записаться

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

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

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

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

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

S – Single Responsibility, принцип единственной ответственности. Компонент должен отвечать только за одну операцию. Если компонент отвечает за несколько операций сразу, вероятность возникновения проблем возрастает. Этот принцип служит для разделения типов поведения, благодаря которому ошибки, вызванные модификациями в одном поведении, не распространяются на прочие, не связанные с ним типы.

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

L – Liskov Substitution, принцип подстановки Барбары Лисков. Если конкретный тип является подтипом более общего типа, то любые объекты общего типа, присутствующие в программе, могут заменяться объектами конкретного типа без негативных последствий для функциональности. В случаях, когда конкретный тип не способен выполнять те же действия, что и общий тип, возникают риски. Необходимо, чтобы конкретный тип был способен обрабатывать те же запросы, что и родитель, и выдавать тот же результат. Или же результат может отличаться, но при этом относится к тому же типу. Этот принцип служит для того, чтобы обеспечить постоянство: родитель и потомок могут использоваться одинаковым образом без нарушения работы программы.

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

D – Dependency Inversion, принцип инверсии зависимостей. Модули верхнего уровня не должны зависеть от модулей нижнего уровня – и те и другие должны зависеть от абстракций. Абстракции не должны зависеть от деталей, а детали должны зависеть от абстракций.

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

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

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

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

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

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

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

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

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

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

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

Так, в качестве основных стадий в ГОСТ 34 выделяют формирование требований к автоматизированной системе, разработка концепции автоматизированной системы, техническое задание, эскизный проект, технический проект, рабочая документация, ввод в действие и сопровождение автоматизированной системы.

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

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