Что такое архитектура по

• Добавить иллюстрации.
• Викифицировать статью.
• Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.

Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл

Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)

CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML

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

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое «Архитектура программного обеспечения» в других словарях:

• архитектура программного обеспечения — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN software architecture … Справочник технического переводчика
• Инженерия программного обеспечения — Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия
• Производитель программного обеспечения — Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
• Аспектно-ориентированная разработка программного обеспечения — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете … Википедия
• Разработка программного обеспечения — Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
• Тестирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
• Сопровождение программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
• Проектирование программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • … Википедия
• Качество программного обеспечения — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
• Внедрение программного обеспечения — Эта статья слишком короткая. Пожалуйста … Википедия

• Обратная связь: Техподдержка, Реклама на сайте

• �� Путешествия

Экспорт словарей на сайты, сделанные на PHP,
WordPress, MODx.

• Пометить текст и поделитьсяИскать в этом же словареИскать синонимы
• Искать во всех словарях
• Искать в переводах
• Искать в ИнтернетеИскать в этой же категории

Разработка архитектуры для чайников. Часть 1

Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.

И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же это собственно такое?

Ниже я привёл несколько картинок которые описывают ту или иную архитектуру

И как мы видим все эти картинки абсолютно разные. Так что же всё таки такое архитектура?

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

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

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

Ну хорошо, мы разобрались что такое архитектура и зачем она собственно нужна, но как же её собственно строить?

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

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

Ну и самое главное, мы должны собрать требования к нашей архитектуре, данные требования могут быть абсолютно разными, вот лишь некоторые из них:

• fault tolerance (reliability) / отказоустойчивость (надёжность)
• speed of development / скорость разработки
• ease deployed / простота деплоя
• scalability by the number of people in the project / масштабируемость по количеству человек в проекте
• scalability in terms of requests per second / масштабируемость по количеству запросов в секунду
• fast entry / exit to resolution / быстрый вход/выход в разработку
• application deployment speed / скорость развертывания приложения
• remove old code / избавиться от старого кода
• complexity of adding new integrations / сложность новых интеграций
• etc. / И т.д.

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

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

Такс, а теперь давайте ещё раз повторим вопросы на которые нам нужно ответить. Их всего 5:

1. Что мы делаем?
2. Почему мы имеем текущую архитектуру?
3. Почему нам нужна новая архитектура?
4. Какие проблемы мы имеем с текущей архитектурой?
5. Что хочет наш клиент от новой архитектуры?

Ну а теперь мы можем приступать к разработке нашей новой архитектуры.

Архитектура ПО: что это значит и как выстроить свою

Все разработчики, с которыми мне приходилось сотрудничать, так или иначе упоминали термин «архитектура». Хотя это очень размытое понятие, им оперируют почти все. Я долго пытался разобраться сам: что имею в виду, когда говорю, что это часть архитектуры, а это — нет. Статьи на Wikipedia и в некоторых других источниках крайне занудные. Похоже, что понятие довольно старое и не имеет четкого определения внутри современных Agile стилей разработки. Но мы по-прежнему оперируем им. Поэтому постараюсь дать определение этому понятию в рамках Agile Development Process.

Что считать архитектурой

Начнем с того, на чем сходятся все источники:

• Архитектура — это фундаментальные договоренности и решения.
• Архитектура — это нечто важное.
• Архитектуру сложно менять.
• Архитектура должна быть использована повторно (в силу своей клевости, естественно).

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

Важная мысль, которая, как мне кажется, является истоком понятия архитектура, — «Архитектурные решения сложно менять» или, другими словами, «Решения, которые сложно поменять, — архитектурные». И это действительно то, что имеет наибольшее значение.

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

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

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

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

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

Что важно заложить в начале проекта

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

С этой позиции не все начальные решения покажутся настолько прям архитектурными. Например, выбор языка программирования — явно архитектурное решение, потому что его изменение почти равносильно переписыванию проекта с нуля. А выбор key-value базы данных — не очень фундаментальное решение, поскольку подобных баз данных много и можно заменить одну на другую гораздо легче и незаметнее. Сделать это до выхода проекта в production вообще не составляет особого труда.

Очень часто в новых проектах доминирует философия: «Нам нужно с самого начала сделать все правильно, потому что потом у нас не будет времени что-то менять». Это правда, потому что все время потрачено на то, чтобы сделать все правильно, а не на то, чтобы делать корректировки по ходу, которые и представляют собой суть Agile процесса.

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

1. Структура хранения данных
2. Язык программирования
3. Development Framework

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

Своя или заимствованная архитектура

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

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

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

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

Как же построить свою архитектуру

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Архитектура ПО: разница между архитектурой и проктированием

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

Определение архитектуры программного обеспечения

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

Характеристики архитектуры ПО

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

Полный список параметров программного обеспечения или так называемых «качественных характеристик» вы найдете здесь.

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

Большинство из вас, наверно, уже знакомы с термином «микросервисы». Микросервисы — один из способов моделирования архитектуры ПО, наряду с многоуровневой архитектурой, архитектурой, управляемая событиями, бессерверной архитектурой и многими другими. Некоторые из вышеперечисленных шаблонов будут описаны ниже. Микросервисный стиль архитектуры стал известным после того, как его стали успешно применять в Amazon и Netflix. А теперь, давайте углубимся в детали и более подробно обсудим архитектурные стили.

** Внимание: пожалуйста, не путайте архитектурные стили с шаблонами проектирования, такими как фабричный шаблон проектирования или адаптерами. Я расскажу о них позже.

Бессерверный архитектурный стиль

Этот элемент применим к приложениям, которые в качестве решения используют сервисы третьих лиц для того, чтобы решить проблему загруженности серверов и бэкенда. Бессерверная архитектура делится на две основные категории. Первая это «бэкенд как услуга (BaaS)», вторая — «функция как услуга (FaaS)». Бессерверная архитектура поможет сэкономить время на проверке и исправлении ошибок переноса, а также на работе с регулярными задачами сервера.
Самым известным примером бессерверного API является сервис Amazon AWS «Lambda».

Более подробно прочитать о нем вы можете здесь.

Архитектура, управляемая событиями

Эта архитектура завязана на производителях и потребителях событий. Главная идея состоит в том, чтобы разделить части вашей системы так, чтобы каждая из частей активизировалась, когда интересное событие происходит в другой. Сложно? Давайте упростим. Представьте, что вы создаете систему для онлайн-магазина и она состоит из двух частей: модуль покупок и модуль продаж. Когда клиент совершает покупку, модуль покупок создает событие «orderPending». Так как модуль продаж заинтересован в этом событии, он будет следить за процессом на случай, если его вызовут. Как только модуль продаж получит это событие, он выполнит определенные задания или запустит ещё одно событие для продолжения покупки товаров у определенного вендора.

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

Если вы хотите узнать больше про архитектуры, управляемые событиями, перейдите по ссылке.

Архитектура микросервисов

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

Проектирование программного обеспечения

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

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

Принципы SOLID ( Single Responsibility, Open Closed, Liskov substitution, Interface Segregation and Dependency Inversion Principles) — это единственная ответственность, открытость/закрытость, принцип подстановки Барбары Лисков, принцип разделения интерфейсов и принцип инверсии зависимостей.

• Принцип единственной ответственности означает, что каждый класс работает только над одной целью, ответственен только за неё и изменяется только по одной причине.
• Принцип открытости/закрытости: класс должен быть открытым для расширения, но закрытым для изменений. Проще говоря, вы можете добавлять новую функциональность в класс, но не можете редактировать существующие функции таким образом, что они будут противоречить используемому коду
• Принцип подстановки Барбары Лисков: согласно этому принципу, разработчик должен соблюдать наследственность таким образом, чтобы нигде не нарушалась логика приложения. Так, если новый класс «XyClass» происходит от родительского класса «AbClass», новый класс должен повторять функции родительского класса таким образом, чтобы они не изменяли поведение родительского класса. Тогда вы легко сможете использовать объект XyClass класса вместо объекта класса AbClass, не нарушая логики приложения.
• Принцип разделения интерфейсов: Всё просто: класс способен реализовывать множество интерфейсов, создавайте свой код таким образом, чтобы классу никогда не приходилось реализовывать функцию, которая не важна для его задач. Вывод — разделяйте свои интерфейсы на категории.
• Принцип инверсии зависимостей: Если вы когда-либо использовали TDD для создания своего приложения, вы знаете насколько важно расщеплять свой код перед тестированием и моделированием. Другими словами, если определенный класс «ex:Purchase» зависит от класса «Users», установка пользовательских объектов должна инициировать снаружи класса «Purchase».

Шаблоны проектирования

• Фабричная модель — самый часто используемый шаблон проектирования в мире OOП, так как он позволяет сэкономить много времени в будущем, когда потребуется изменить один из классов, который вы использовали. Рассмотрим на примере:

Представим, что вы хотите реализовать модель класса пользователей Users(), — вы можете использовать один из двух методов:

1 — $users = new Users();
2 — $users = DataFactory::get(‘Users’);

Я бы выбрал второй, по двум основным причинам, помимо всех остальных. Во-первых, изменение названия класса с «Users» на «UserData» — это всего лишь одно изменение в одном месте, внутри фабричной базы, в остальном ваш код остается тем же. Во-вторых, если в классе «Users» появятся такие параметры как Users($connection), то вам останется только внести изменения в одном месте, а не в каждой функции которая использует объекты класса Users. Поэтому, если вы думаете, что первый вариант лучше, подумайте ещё раз.

• Адаптер (шаблон проектирования) — один из шаблонов структурного проектирования. Посмотрев на название, можно понять, что эта модель делает из неожидаемого использования класса ожидаемое.

Представьте,что ваше приложение работает по API c YouTube и, чтобы получить токен доступа, вам необходимо вызвать функцию getYoutubeToken();

Итак, вы вызвали эту функцию в 20 разных местах в приложении.

А потом, Google публикует новую версию API, переименовав функцию на getAccessToken();

Теперь вам придется найти и переименовать эту функцию во всем приложении или создать адаптер-класс, как показано далее в примере:

В последнем случае, единственное, что вам придется сделать — изменить одну строку, все остальное приложение продолжит работать как раньше.

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