Разработка архитектуры по

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

Анализ области решений

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

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

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

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

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

Под архитектурой ПО понимают набор внутренних структур ПО , которые видны с различных точек зрения и состоят из компонентов , их связей и возможных взаимодействий между компонентами , а также доступных извне свойств этих компонентов [1].

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

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

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

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

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

  При этом вся совокупность условий должна быть непротиворечивой, выглядеть и развиваться подобно реальным событиям. Некоторые условия, например, погода, должны изменяться достаточно медленно, другие события — происходить внезапно и приводить к связанным с ними последствиям (нарушение герметичности корпуса может сопровождаться поломками каких-то элементов системы мониторинга или «смертью» одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны, через некоторое время летчики должны увидеть грозу за бортом и она может начать оказывать влияние на условия полета.

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

  m_i_kuznetsov

  Размышления о разработке программного обеспечения и информационных систем

  То, что действительно важно, но чему нигде не учат

  Определение архитектуры ПО приведено мной ранее: «Что такое архитектура программного обеспечения?»
  Нужна ли архитектура ПО? Можно ли реализовать программную систему без проектирования архитектуры? Какова цель проектирования архитектуры ПО?

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

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

  Тут я вижу, как минимум, четыре проблемы:

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

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

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

  Техническое решение требуется готовить задолго до начала реализации продукта

  Получение готового кода в конце процесса разработки влечёт за собой серию рисков:

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

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

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

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

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

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

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

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

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

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

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

  Код не может описать причины принятых технических решений и их альтернативы

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

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

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

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

  Проблемы незаконченного продукта

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

  Устранить такой риск можно только путём создания технического описания основных аспектов системы помимо реализуемого кода.

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

  Именно таким описанием и является архитектура программного обеспечения.

  Теперь можно сформулировать цель разработки архитектуры:
  Целью разработки и сопровождения архитектуры программной системы является создание на самых ранних стадиях разработки и сопровождение в течение всего жизненного цикла системы описания такого технического решения, которое бы охватывало весь набор требований к разрабатываемой системе и к процессам её разработки, внедрения, эксплуатации и сопровождения, учитывало баланс интересов всех заинтересованных сторон проекта, было обосновано с точки зрения технологической реализуемости, было понятно и доступно всем заинтересованным лицам.
  Другие посты по теме:
  «Что такое архитектура программного обеспечения?»
  «Задачи архитектора программного обеспечения»