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

Может ли кто-нибудь объяснить разницу между Software Design и Software Architecture?

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

Мое настоящее понимание:

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

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

+342
источник поделиться
41 ответ
  • 1
  • 2

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

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

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

+329
источник

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

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

Эти два этапа, похоже, будут сочетаться по разным причинам.

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

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

+80
источник
другие ответы

Связанные вопросы


Похожие вопросы

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

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

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

+55
источник

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

  • Архитектура
  • - "что" мы строим;
  • дизайн "как" мы строим;
+38
источник
  • Архитектура означает концептуальную структуру и логическую организацию компьютерной или компьютерной системы.

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

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

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

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

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

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

Design vs Architecture

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

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

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

+21
источник

Я бы сказал, что ты прав, по-моему,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+6
источник

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

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

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

+5
источник

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

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

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

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

+5
источник

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

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

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

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

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

+5
источник

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

+3
источник

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

+3
источник

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

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

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

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

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

+3
источник

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

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

Вы могли бы спроектировать макет, как "архитектуру макета", хотя...

+3
источник

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

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

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

+3
источник

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

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

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

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

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

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

+3
источник

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

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

+3
источник

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

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

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

+3
источник

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

+3
источник

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

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

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

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

  • GUI
  • Launcher
  • Диспетчерская
  • ...

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

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

+2
источник

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

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

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

+2
источник

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

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

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

+2
источник

Версия отзыва Cliff:

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

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

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

+1
источник

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

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

+1
источник

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

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

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

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

+1
источник

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

+1
источник

Кроме того, обратитесь к: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

+1
источник

Мне нравится определение и объяснение Roy Thomas Fielding о том, что такое архитектура программного обеспечения в его статье: Архитектурные стили и дизайн сетевых архитектурных приложений

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

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

+1
источник

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

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

Например: есть дом, в котором есть 5 комнат. Есть также ванные комнаты. Кухня также есть в доме. Таким образом, в доме есть разные вещи, и все они имеют разные отношения между собой. Так что это все о "ДИЗАЙНЕ" дома.

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

+1
источник
  • 1
  • 2

Посмотрите другие вопросы по меткам или Задайте вопрос