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

342

Может ли кто-нибудь объяснить разницу между дизайном программного обеспечения и архитектурой программного обеспечения?

Более конкретно; если вы скажете кому-то представить вам «дизайн» - что бы вы ожидали от него? То же самое касается «архитектуры».

Мое текущее понимание:

  • Дизайн: UML-диаграмма / блок-схема / простые каркасы (для пользовательского интерфейса) для конкретного модуля / части системы
  • Архитектура: диаграмма компонентов (показывающая, как различные модули системы взаимодействуют друг с другом и другими системами), какой язык будет использоваться, шаблоны ...?

Поправьте меня если я ошибаюсь. Я упоминал, что в Википедии есть статьи на http://en.wikipedia.org/wiki/Software_design и http://en.wikipedia.org/wiki/Software_architecture , но я не уверен, правильно ли я их понял.

Мадс Мобек
источник
Были ли полезны какие-либо из приведенных ниже вопросов? ;)
Патрик Керхер
Имейте в виду, что в определенной степени различие (которое, безусловно, является реальным) часто делается из претенциозности. Ни один архитектор не может быть хорошим без приличного понимания дизайна и конструкции, и ни один дизайнер не может быть хорошим без разумного понимания архитектуры.
Hot Licks
И однажды я увидел архитектуру, описанную как «дизайн, соответствующий цели». Это немного банально, но в нем есть доля правды, поскольку хорошая архитектура в конечном итоге должна быть ориентирована на цель, а не на реализацию.
Hot Licks

Ответы:

329

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

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

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

Razzie
источник
116
Кроме того, архитектура обычно имеет дело с тем, что (делается) и где (это делается), но никогда не с тем, как. В этом и заключается принципиальное различие - дизайн завершает то, о чем эта архитектура не говорит (и не должна) говорить.
Асаф Р
2
Привет, АсафР! это заставило меня думать об архитектуре как об анализе, потому что анализ имеет дело с тем, что (делается), а с дизайном как. Как вы думаете?
Крис
2
В настоящее время люди сами занимаются проектированием, внедрением, обслуживанием внутренних серверов (возможно, облачных) и интерфейсным проектированием (веб или мобильным). Я думаю, что их называют разработчиками полного стека. Правильно?
Мазияр
1
Архитектура - это схема системы, структура, план всего этого. Дизайн - это просто деятельность по составлению плана. Вы можете спроектировать архитектуру, вы можете спроектировать модуль, вы даже можете спроектировать метод.
Эван Ху,
2
Это потому, что MVC - это архитектурный проект. MVC не содержит никаких подробностей. «Вид» может быть веб-сайтом, winforms, консольным приложением. Модель может быть практически любой, в ней ничего не говорится о том, откуда она взялась (уровень базы данных или что-то еще).
Раззи
80

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

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

Эти две стадии будут казаться смешанными по разным причинам.

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

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

Патрик Керхер
источник
Хороший ответ. Мне нравится акцент на том, как один может казаться частью другого. Четвертый пункт поднимает интересный вопрос: является ли дизайн в конкретной проблемной области менее допустимым, когда у него еще нет архитектуры, которая существует внутри? Опыт подсказывает, что да, но в теории я хотел бы думать, что дизайн, который укладывается в соответствующую область (то есть для конкретного компонента), должен быть одинаково действительным независимо от того, как он в конечном итоге используется.
Том
55

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

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

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

Крис Каннон
источник
Я бы хотел меньше упоминаний о «дизайне» и «архитектуре» в определении «дизайн», чтобы проголосовать за это ...
Питер Хансен
1
Согласовано ... это возможно: архитектура включает в себя структуры, инструменты, парадигмы программирования, стандарты разработки программного обеспечения на основе компонентов, принципы высокого уровня. В то время как дизайн - это деятельность, связанная с локальными ограничениями, такими как шаблоны проектирования, идиомы программирования и рефакторинг.
Крис Каннон
38

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

  • архитектура - это то, что мы строим;
  • дизайн "как" мы строим;
Джордж С.
источник
4
То, что мы строим, это требования клиента. Как мы его строим, зависит как от архитектуры, так и от дизайна. Так что нет, это совершенно неправильно.
Марек
1
@ Марек Я не понимаю, что с этим не так. Архитектура - это то, что нужно строить, что хочет клиент, как он должен выглядеть в целом, из каких компонентов он должен быть сделан и т. Д. Проектирование - это то, как эти вещи фактически создаются: фактические реализации компонентов, алгоритмов и т. Д.
RecursiveExceptionException
21
  1. Архитектура означает концептуальную структуру и логическую организацию компьютера или компьютерной системы.

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

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

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

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

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

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

Дизайн против Архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

  • архитектура для общественности / инженеров на более детальном уровне абстракции
  • дизайн предназначен для публики на менее детальном уровне абстракции
user662182
источник
+1 для архитектуры - это распределение системных требований к системным элементам. Виртуальный -1 для использования слова «а» в окончательном списке. Моя точка зрения на это - ваше (правильное) первоначальное определение - антитеза абстракции.
Крис Уолтон
Не уверен насчет пунктов 1 и 3. Ничто не должно вводить больше функциональности, чем требуется для удовлетворения требований заинтересованных сторон. Ограничения - это вопрос методологии. Другие пункты полезны. Аналогия с кухней не велика; вам не нужен архитектор, но дизайн кухни - это довольно специализированная область, в которой что-то разрабатывается с использованием несколько модульных компонентов. Не могу согласиться с тем, что дизайн не является важным инженерным шагом. Не уверен, что означают последние два пункта.
Майк Дж
Куда вписывается реализация? Разве реализация не дизайн?
Jwilleke
14

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

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

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

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

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

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

Энрике Молинари
источник
Мне это очень нравится. Хороший вклад. Я не уверен, что это так ясно, но в таком вопросе, как этот, он так же важен, как и ты. Я бы проголосовал за тебя, но я не голосовал за день :(.
Майк Дж
5

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

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

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

Тави
источник
Даже когда я прочитал эту книгу более двух раз, после прочтения всех приведенных выше комментариев это определение не имеет смысла для меня. Вот почему: дизайнерская часть звучит хорошо, потому что вы позаботитесь о каждой детали, чтобы убедиться, что кнопка делает то, что должна. Но в архитектуре речь идет не о взаимодействии модулей или общей картине, а о производительности и подобных вещах. Как вы думаете, я что-то неправильно понял из этого определения?
Рене Энрикес
5

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

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

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

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

Аджай Шендье
источник
5

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

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

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

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

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

Пауло Мерсон
источник
1
Хотя я согласен с первоначальным определением, было бы неплохо добавить его источник: «Пол Клементс, Документирование архитектур программного обеспечения: представления и не только». На ваш последний вопрос: вы никогда не прекращаете проектировать. Это то, что Клементс пытается указать в упомянутой книге. Каждый разработчик, работающий над системой, будет проектировать какую-то ее часть, но большинство из этих проектов не будут иметь отношения к архитектуре. Поэтому, если вы хотите обсудить или задокументировать архитектуру программного обеспечения, вы останавливаетесь, как только обсуждаете части, которые больше не актуальны.
Томас
1
@ThomasEizinger. Я добавил ссылку на нашу книгу. Хорошее предложение. И ваш комментарий также помогает дать должный кредит. Что касается последнего вопроса, я имел в виду обратиться к проектной документации. Я отредактировал абзац. Спасибо!
Пауло Мерсон,
3

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

MrTelly
источник
3

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

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

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

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

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

Ларри Ватанабэ
источник
3

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

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

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

г-н-ск
источник
3

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

Чарльз Бретана
источник
3

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

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

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

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

Проверьте эту ссылку.

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

Tebo
источник
3

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

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

Джошуа Рамирес
источник
3

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

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

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

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

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

buzzcoda
источник
Мне нравится этот ответ только из-за этого предложения «Но архитектура также в дизайне». Я бы сказал, что «архитектура может быть в дизайне». - тебе решать. Они не разделены.
Мирослав Трнинич
3

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

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

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

Джесси Фогт
источник
2

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

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

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

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

  • графический интерфейс пользователя
  • гранатомет
  • диспетчер
  • ...

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

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

VonC
источник
2

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

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

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

Гернот Старке
источник
2

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

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

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

Ekeren
источник
1

Версия Cliff Notes:

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

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

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

TA01
источник
1

Архитектура - это итоговая коллекция шаблонов проектирования для построения системы.

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

Марк Редман
источник
Я должен не согласиться. кажется, что вы (как и я и большинство других ответов) ставите архитектуру на «общую картину», а дизайн - больше о методах и решении проблем. Но, если ваша архитектура - это то, что «вытекает» из шаблонов проектирования, они действительно не спроектированы, вы просто даете ей расти!
Хавьер
... если только вы не позволили ему расти, то есть :-) Требуются некоторые знания и опыт, чтобы иметь возможность использовать имеющиеся методы для создания элегантной архитектуры. ... очевидно, что это слишком субъективно, чтобы придумать что-то определенное ... но да, вы правы, учитывая, что существуют некоторые плохие системы без общих системных проектов (архитектур)
Марк Редман
1

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

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

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

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

LeWoody
источник
1

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

Имран
источник
1

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

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

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

Jacky
источник
Элементы времени выполнения также относятся к компонентам или модулям приложения, и каждый модуль или компонент содержит свой собственный уровень абстракции. Верный?
Анкит Рана
1

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

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

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

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

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

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

Йон
источник