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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Версия Cliff Notes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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