Дизайн программного обеспечения против архитектуры программного обеспечения

Вы правы, да. Архитектура системы - это ее «скелет». Это высший уровень абстракции системы. Какое хранилище данных присутствует, как модули взаимодействуют друг с другом, какие системы восстановления установлены. Как и шаблоны проектирования, существуют архитектурные шаблоны: MVC, трехуровневый дизайн и т. Д.

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

Короче говоря, архитектура программного обеспечения - это скорее проектирование всей системы, в то время как проектирование программного обеспечения делает упор на уровне модуля / компонента / класса.

В некоторых описаниях SDLC (жизненный цикл разработки программного обеспечения) они взаимозаменяемы, но консенсус заключается в том, что они разные. Это одновременно: разные (1) этапы, (2) зоны ответственности и (3) уровни принятия решений. .

• Архитектура - это более широкая картина: выбор фреймворков, языков, объема, целей и высокого уровня методологии (Rational, водопад, agile и т. Д.).
• Дизайн - это меньшая картина: план организации кода; как будут выглядеть контракты между разными частями системы; текущая реализация методологий и целей проекта. На этом этапе пишутся спецификации.

Эти два этапа будут казаться сливающимися по разным причинам.

1. Небольшие проекты часто не имеют достаточного объема, чтобы разделить планирование на эти этапы.
2. Проект может быть частью более крупного проекта, и, следовательно, части обоих этапов уже определены. (Существуют уже существующие базы данных, соглашения, стандарты, протоколы, фреймворки, повторно используемый код и т. Д.)
3. Новые подходы к SDLC (см. Agile-методологии) несколько изменяют этот традиционный подход. Проектирование (в меньшей степени, архитектура) осуществляется в SDLC специально. Часто бывает больше итераций, где весь процесс повторяется снова и снова.
4. Разработка программного обеспечения в любом случае сложна и трудна для планирования, но клиенты / менеджеры / продавцы обычно усложняют ее, изменяя цели и требования на полпути. Дизайнерские и даже архитектурные решения должны приниматься позже в проекте, вне зависимости от того, планируется это или нет.

Даже если этапы или области ответственности сливаются воедино и происходят повсюду, всегда полезно знать, на каком уровне принятия решений происходит процесс принятия решений. (Мы могли бы продолжать это бесконечно. Я пытаюсь сохранить это резюме.) Я закончу следующим: даже если кажется, что ваш проект не имеет формальной стадии архитектуры или дизайна / AOR / документации, это происходит независимо от того, сознательно это делаете или нет. Если никто не решает заниматься архитектурой, то случается дефолтная, вероятно плохая. То же самое и с дизайном. Эти концепции становятся почти более важными, если их не представляют формальные этапы.

Архитектура - стратегическая, а Дизайн - тактическая.

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

В то время как дизайн - это деятельность, связанная с локальными ограничениями, такими как шаблоны проектирования, идиомы программирования и рефакторинги.

Я обнаружил это, когда сам искал простое различие между архитектурой и дизайном;
Что вы думаете о таком взгляде на них:

• архитектура - это то, «что» мы строим;
• дизайн - это то, «как» мы строим;

1. Архитектура означает концептуальную структуру и логическую организацию компьютера или компьютерной системы.

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

2. Если вы «проектируете» компонент, вы определяете, как он ведет себя в более крупной системе.

   Если вы «проектируете» один и тот же компонент, вы определяете его внутреннее поведение.

Вся архитектура - это дизайн, но НЕ весь дизайн - это архитектура.

What часть - это Дизайн, How - конкретная реализация, а пересечение What и How - это Архитектура.

Изображение для различения архитектуры и дизайна:

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

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

Ссылка, которая дает хорошую аналогию

Я бы сказал, что вы правы, своими словами;

Архитектура - это распределение системных требований по элементам системы. Четыре утверждения об архитектуре:

1. Он может вводить нефункциональные требования, такие как язык или шаблоны.
2. Он определяет взаимодействие между компонентами, интерфейсами, временем и т. Д.
3. Он не должен вводить новые функции,
4. Он распределяет (разработанные) функции, которые система должна выполнять, по элементам.

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

Пример: подумайте о своем доме, вам не нужен архитектор для вашей кухни (задействован только один элемент), но всему зданию нужны некоторые определения взаимодействия, такие как двери и крыша.

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

Было бы неплохо увидеть дизайн кухни до того, как она будет установлена, но это не обязательно для требований приготовления пищи:

Если я подумаю об этом, вы можете заявить:

• архитектура предназначена для публики / инженеров на более детальном уровне абстракции
• дизайн предназначен для публики на менее детализированном уровне абстракции

Мое напоминание:

• Мы можем изменить Дизайн, никого не спрашивая
• Если мы меняем архитектуру, нам нужно сообщить об этом кому-то (команде, клиенту, заинтересованной стороне, ...)

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

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

Теперь предположим, что ваше приложение Java разделено на модули, и каждый модуль представляет собой набор пакетов (представленный как модуль развертывания файла jar), и вам представлена ​​диаграмма, содержащая модули и их зависимости, то есть Архитектура. В Java (по крайней мере, до Java 7) нет способа сопоставить модуль (набор пакетов) с синтаксической конструкцией. Вы также можете заметить, что эта диаграмма представляет собой шаг выше в уровне абстракции вашей модели программного обеспечения. Любая диаграмма выше (более крупная, чем) диаграмма пакета представляет архитектурное представление при разработке на языке программирования Java. С другой стороны, если вы разрабатываете в Modula-2, то диаграмма модуля представляет собой Дизайн.

(Фрагмент из http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)

Лично мне нравится вот этот:

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

Учебное пособие по SCEA для Java ™ EE от Марка Кейда и Хамфри Шейла

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

Хотя цель дизайнера - быть настолько точными и конкретными в спецификациях, насколько это необходимо для разработки; По сути, архитектор стремится указать структуру и общее поведение системы в той степени, в которой это требуется для начала детального проектирования.

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

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

Архитектура - это дизайн, но не весь дизайн является архитектурным. Поэтому, строго говоря, было бы разумнее попытаться провести различие между архитектурным дизайном и неархитектурным дизайном. . А в чем разница? По-разному! У каждого архитектора программного обеспечения может быть свой ответ (ymmv!). Мы разрабатываем нашу эвристику, чтобы найти ответ, например: «Диаграммы классов - это архитектура, а диаграммы последовательностей - это дизайн». Дополнительную информацию см. В книге DSA.

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

Итак, мое предложение:

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

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

Да, это звучит правильно для меня. Дизайн - это то, что вы собираетесь делать, а архитектура - это способ, которым части и части дизайна будут соединены вместе. Он может быть независимым от языка, но обычно указывает используемые технологии, например, LAMP v Windows, Web Service v RPC.

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

(из Википедии, http://en.wikipedia.org/wiki/Software_architecture)

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

(из Википедии, http://en.wikipedia.org/wiki/Software_design)

Сам не мог бы сказать лучше :)

Я смотрю на архитектуру так же, как Патрик Керхер - на общую картину. Например, вы можете представить архитектуру здания, просмотреть его несущую конструкцию, окна, входы и выходы, водоотвод и т. Д. Но вы не «спроектировали» планировку этажа, расположение отсеков и т.

Итак, пока вы проектировали здание, вы не разработали планировку каждого офиса. Я думаю, что то же самое можно сказать и о программном обеспечении.

Вы можете рассматривать разработку макета как «создание архитектуры макета» ...

Хороший вопрос ... Хотя грань между ними вряд ли является яркой резкой линией, imho, если вы используете оба термина, тогда архитектура включает в себя более технические или структурные решения о том, как построить или построить что-то, особенно те решения, которые будут трудными ( или сложнее) изменить после реализации, тогда как дизайн включает в себя те решения, которые легко изменить позже (например, имена методов, организационная структура файла класса ‹->, шаблоны проектирования, использовать ли одноэлементный или статический класс для решения какой-либо конкретной проблемы и т. д.) и / или те, которые влияют на внешний вид или эстетические аспекты системы или приложения (человеческий интерфейс, простота использования, внешний вид и т. д.)

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

Архитектура конкретно не касается… деталей реализаций (например, алгоритмов и структур данных). Архитектурный дизайн включает в себя более богатый набор абстракций, чем обычно предоставляется OOD »(объектно-ориентированный дизайн).

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

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

Ознакомьтесь с этой ссылкой.

Определение терминов «Архитектура, дизайн и реализация»

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

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

Мне очень понравился этот документ как практическое правило отделения архитектуры от дизайна:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

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

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

Довольно субъективно, но мое мнение:

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

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

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

Например, ваш бизнес связан с «прибылями и убытками» для трейдеров, и ваши основные функции включают «оценку портфеля» и «расчет рисков».

Но когда Software Architect подробно расскажет о своем решении, он поймет, что:

«Оценка портфолио» не может быть одним приложением. Его нужно дорабатывать в управляемых проектах, таких как:

• Графический интерфейс
• Пусковая установка
• Диспетчер
• ...

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

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

если кто-то построит корабль, то его «архитектурными элементами» будут двигатель, корпус, электрические схемы и т. д. Для него двигателестроение будет «проектной работой».

Если он затем делегирует создание двигателя другой команде, они создадут «архитектуру двигателя» ...

Итак - это зависит от уровня абстракции или детализации. Архитектура одного человека может быть дизайном другого!

Архитектура - это «дизайнерские решения, которые трудно изменить».

После работы с TDD, что практически означает, что ваш дизайн все время меняется, я часто сталкивался с этим вопросом. Приведенное выше определение взято из Шаблоны архитектуры корпоративных приложений, Мартин Фаулер.

Это означает, что архитектура зависит от языка, структуры и домена вашей системы. Если вы можете просто извлечь интерфейс из своего класса Java за 5 минут, это уже не архитектурное решение.

Версия Cliff Notes:

Дизайн: Реализация решения на основе спецификаций желаемого продукта.

Архитектура: фундамент / инструменты / инфраструктура / компоненты, поддерживающие ваш дизайн.

Это довольно широкий вопрос, который вызовет множество ответов.

Архитектура - это результирующий набор шаблонов проектирования для построения системы.

Думаю, дизайн - это творчество, которое использовалось, чтобы собрать все это воедино?

Дизайн программного обеспечения имеет более давнюю историю, в то время как термину «архитектура программного обеспечения» едва исполнилось 20 лет. Следовательно, сейчас он переживает болезни роста.

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

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

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

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

См. Также: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Мне нравится определение и объяснение Роя Томаса Филдинга о том, что такое архитектура программного обеспечения в его статье: Архитектурные стили и проектирование сетевых архитектур программного обеспечения

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

Он подчеркивает «элементы времени выполнения» и «уровни абстракции».

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

Хороший способ думать об этом - заявление Лена Басса, Пола Клементса и Рика Казмана о том, что «вся архитектура - это дизайн, но не весь дизайн - это архитектура» [Архитектура программного обеспечения на практике]. Я не уверен, что полностью согласен с этим (потому что архитектура может включать в себя другие действия), но это отражает суть того, что архитектура - это проектная деятельность, которая имеет дело с критическим подмножеством дизайна.

Мое слегка легкомысленное определение (найдено на определений SEI page) заключается в том, что это набор решений, которые в случае неправильного принятия приводят к отмене вашего проекта.

Полезная попытка разделения архитектуры, дизайна и реализации как концепций была сделана Амноном Иденом и Риком Казманом несколько лет назад в исследовательской статье под названием «Архитектура, дизайн, реализация», которую можно найти здесь: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf. Их язык довольно абстрактный, но они упрощенно говорят, что архитектура - это дизайн, который может использоваться во многих контекстах и ​​предназначен для применения во всей системе, дизайн - это (ошибочно) дизайн. который может использоваться во многих контекстах, но применяется в определенной части системы, а реализация - это дизайн, специфичный для контекста и применяемый в этом контексте.

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

Надеюсь, это поможет!

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

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

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

Например: в доме 5 комнат. Есть и прилегающие ванные комнаты. Кухня тоже есть в доме. Итак, в доме есть разные вещи, и все они по-разному связаны друг с другом. Итак, это все о «ДИЗАЙНЕ» дома.

Когда вы смотрите снаружи дома, вся структура, на которую вы смотрите, связана с архитектурой.

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

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

http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns

Архитектура сообщает вам, как устроена ваша система. Одним из примеров традиционного архитектурного шаблона является трехуровневая система, в которой ваша система разбита на уровни представления, бизнеса и данных.

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

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

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

ИЛИ по-другому

Архитектура - это мета-дизайн, то есть проектирование дизайна. У вас есть несколько шаблонов, которые подходят для определенного пространства решений, что бы вы выбрали и почему? Архитектура - это когда вы отвечаете на вопросы «что» и «почему» («как» уже дано дизайном). Это, конечно, не зависит от уровня абстракции, например, реализация распределенных сеансов не является задачей уровня класса, но есть несколько проектов, из которых можно выбрать для данной архитектуры.

Точно так же архитектура отражается даже в дизайне уровня класса. В масштабируемой архитектуре дизайн классов часто отличается, если вы делаете это без учета фактора масштабируемости. Почему у вас должен быть метод BeginAsyncUpload вместо метода Upload - архитектурное решение.

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

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

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

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

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

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

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

АРХИТЕКТУРА: - Архитектура создает расположение планов на различных этапах строительства в соответствии со спецификациями.

ДИЗАЙНЕР: - Проектировщик - это деятельность, которая удовлетворяет все существенные требования архитектурных планов с функциональными, астетектическими и подходящими макетами.

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

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

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

Ниже приведены ссылки, которые могут более подробно объяснить архитектуру, и список диаграмм UML для архитектуры программного обеспечения. (Мне не удалось найти список диаграмм UML для разработки программного обеспечения)

Гради Буч

Использование диаграмм UML 2 для архитектурных моделей

Классификация диаграмм UML

Классификация диаграмм UML

Даже после публикации этого ответа я сам не понимаю, какая диаграмма предназначена для архитектуры, а какая для дизайна :). Грэди Буч в своем слайде № 58 утверждает, что классы, интерфейсы и взаимодействия являются частью представления дизайна, а это представление дизайна - одним из представлений архитектуры !!!