Дизайн программного обеспечения и архитектура программного обеспечения
Может ли кто-нибудь объяснить разницу между дизайном программного обеспечения и архитектурой программного обеспечения?
Более конкретно; если вы скажете кому-то представить вам "дизайн" - что бы вы ожидали от него? То же самое касается "архитектуры".
Мое текущее понимание:
- Дизайн: UML-диаграмма / блок-схема / простые каркасы (для пользовательского интерфейса) для конкретного модуля / части системы
- Архитектура: диаграмма компонентов (показывающая, как различные модули системы взаимодействуют друг с другом и другими системами), какой язык будет использоваться, шаблоны...?
Поправьте меня если я ошибаюсь. Я упоминал, что в Википедии есть статьи на http://en.wikipedia.org/wiki/Software_design и http://en.wikipedia.org/wiki/Software_architecture, но я не уверен, правильно ли я их понял.
41 ответ
Ты прав, да. Архитектура системы - это ее "скелет". Это высший уровень абстракции системы. Какое хранилище данных присутствует, как модули взаимодействуют друг с другом, какие системы восстановления существуют. Точно так же, как шаблоны проектирования, существуют архитектурные шаблоны: MVC, трехуровневый многоуровневый дизайн и т. Д.
Разработка программного обеспечения - это проектирование отдельных модулей / компонентов. Каковы обязанности, функции модуля x? Класса Y? Что он может сделать, а что нет? Какие шаблоны дизайна можно использовать?
Короче говоря, архитектура программного обеспечения больше относится к дизайну всей системы, в то время как дизайн программного обеспечения делает упор на уровне модуля / компонента / класса.
В некоторых описаниях SDLC (жизненный цикл разработки программного обеспечения) они взаимозаменяемы, но, по сути, они различны. Они одновременно: разные (1) стадии, (2) зоны ответственности и (3) уровни принятия решений.
- Архитектура представляет собой более широкую картину: выбор структур, языков, области применения, целей и методологий высокого уровня ( Rational, Waterfall, Agile и т. Д.).
- Дизайн - это меньшая картина: план того, как будет организован код; как будут выглядеть контракты между различными частями системы; постоянная реализация методологий и целей проекта. Спецификация написана на этом этапе.
Эти две стадии будут казаться смешанными по разным причинам.
- Небольшие проекты часто не имеют достаточного объема, чтобы разделить планирование на эти этапы.
- Проект может быть частью более крупного проекта, и, следовательно, части обоих этапов уже определены. (Уже существуют базы данных, соглашения, стандарты, протоколы, платформы, повторно используемый код и т. Д.)
- Новые способы мышления о SDLC (см. Agile методологии) несколько перестраивают этот традиционный подход. Проектирование (архитектура в меньшей степени) происходит в рамках SDLC специально. Часто бывает больше итераций, когда весь процесс повторяется снова и снова.
- В любом случае разработка программного обеспечения является сложной и трудной для планирования, но клиенты / менеджеры / продавцы обычно усложняют ее, меняя цели и требования в середине потока. Проектные и даже архитектурные решения должны быть приняты позже в проекте, независимо от того, является ли это планом или нет.
Даже если стадии или области ответственности сливаются воедино и происходят повсеместно, всегда полезно знать, на каком уровне происходит принятие решений. (Мы могли бы продолжать это навсегда. Я пытаюсь сделать это кратким изложением.) Я закончу: Даже если кажется, что у вашего проекта нет формальной архитектурной или проектной стадии /AOR/documentmentaiton, это происходит независимо от того, сознательно делает это или нет. Если никто не решит заняться архитектурой, то по умолчанию произойдет, что, вероятно, плохо. То же самое для дизайна. Эти понятия почти более важны, если нет формальных этапов, представляющих их.
Архитектура стратегическая, а дизайн тактический.
Архитектура включает в себя фреймворки, инструменты, парадигмы программирования, стандарты разработки программного обеспечения на основе компонентов, принципы высокого уровня.
Дизайн - это деятельность, связанная с локальными ограничениями, такими как шаблоны проектирования, идиомы программирования и рефакторинг.
Я нашел это, когда искал простое различие между архитектурой и дизайном сам;
Что вы думаете об этом взгляде на них:
- архитектура - это то, что мы строим;
- дизайн "как" мы строим;
Архитектура означает концептуальную структуру и логическую организацию компьютера или компьютерной системы.
Дизайн - это план или чертеж, созданный для демонстрации внешнего вида и функций или работы системы или объекта до его создания.
Если вы "проектируете" компонент, вы определяете, как он ведет себя в большей системе.
Если вы "проектируете" один и тот же компонент, вы определяете его внутреннее поведение.
Вся архитектура - это дизайн, но НЕ весь дизайн - это архитектура.
What часть дизайна, How это конкретная реализация и пересечение What а также How это архитектура.
Изображение для разграничения архитектуры и дизайна:
Существуют также проектные решения, которые не имеют архитектурного значения, то есть не относятся к архитектурной ветви дизайна. Например, некоторые внутренние проектные решения компонента, такие как выбор алгоритма, выбор структуры данных и т. Д.
Любое проектное решение, которое не видно за границей его компонента, является внутренним проектом компонента и не является архитектурным. Это проектные решения, которые системный архитектор оставил бы на усмотрение разработчика модуля или команды разработчиков, если их проект не нарушает архитектурные ограничения, налагаемые архитектурой системного уровня.
Ссылка, которая дает хорошую аналогию
Я бы сказал, что вы правы, по моим собственным словам;
Архитектура - это распределение системных требований к системным элементам. Четыре утверждения об архитектуре:
- Он может вводить нефункциональные требования, такие как язык или шаблоны.
- Он определяет взаимодействие между компонентами, интерфейсами, временем и т. Д.
- Он не должен вводить новую функциональность,
- Он распределяет (разработанные) функции, которые система должна выполнять для элементов.
Архитектура является важным инженерным шагом, когда сложность системы подразделяется.
Пример: подумайте о своем доме, вам не нужен архитектор для вашей кухни (задействован только один элемент), но для всего здания нужны некоторые определения взаимодействия, такие как двери и крыша.
Дизайн является информативным представлением (предлагаемой) реализации функции. Он предназначен для получения обратной связи и обсуждения с заинтересованными сторонами. Это может быть хорошей практикой, но не является важным инженерным шагом.
Было бы неплохо увидеть дизайн кухни до ее установки, но это не является обязательным условием для приготовления пищи:
Если я подумаю об этом, вы можете заявить:
- архитектура для общественности / инженеров на более детальном уровне абстракции
- дизайн предназначен для публики на менее детальном уровне абстракции
Мое напоминание:
- Мы можем изменить дизайн, не спрашивая кого-то
- Если мы меняем архитектуру, нам нужно сообщить об этом кому-то (команде, клиенту, заинтересованному лицу, ...)
Я думаю, что мы должны использовать следующее правило, чтобы определить, когда мы говорим о дизайне и архитектуре: если элементы созданной вами картинки программного обеспечения могут быть сопоставлены один к одному с синтаксической конструкцией языка программирования, то это "Проект", если не архитектура.
Так, например, если вы видите диаграмму классов или диаграмму последовательности, вы можете отобразить класс и его отношения на язык объектно-ориентированного программирования, используя синтаксическую конструкцию класса. Это явно дизайн. Кроме того, это может привести к выводу, что это обсуждение связано с языком программирования, который вы будете использовать для реализации программной системы. Если вы используете Java, применяется предыдущий пример, поскольку Java является объектно-ориентированным языком программирования. Если вы придумали диаграмму, которая показывает пакеты и их зависимости, то это тоже Design. Вы можете сопоставить элемент (в данном случае пакет) с синтаксической конструкцией Java.
Теперь предположим, что ваше Java-приложение разделено на модули, и каждый модуль представляет собой набор пакетов (представленных как модуль развертывания jar-файла), и вам представлена диаграмма, содержащая модули и их зависимости, то есть Архитектура. В Java нет способа (по крайней мере, до Java 7) отобразить модуль (набор пакетов) в синтаксическую конструкцию. Вы также можете заметить, что эта диаграмма представляет собой шаг выше в уровне абстракции вашей программной модели. Любая приведенная выше диаграмма (грубо говоря, чем) диаграмма пакета представляет архитектурное представление при разработке на языке программирования Java. С другой стороны, если вы разрабатываете в Modula-2, тогда диаграмма модуля представляет собой проект.
(Фрагмент из http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)
Архитектура - это дизайн, но не весь дизайн является архитектурным. Поэтому, строго говоря, было бы более разумно попытаться провести различие между архитектурным дизайном и неархитектурным дизайном. А какая разница? Это зависит! У каждого архитектора программного обеспечения может быть свой ответ (ymmv!). Мы развиваем нашу эвристику, чтобы придумать ответ, такой как "диаграммы классов - это архитектура, а диаграммы последовательностей - это дизайн". Смотрите DSA книгу для более.
Обычно говорят, что архитектура находится на более высоком уровне абстракции, чем дизайн, или архитектура логична, а дизайн физичен. Но это понятие, хотя и общепринятое, на практике бесполезно. Где вы проводите грань между высокой или низкой абстракцией, между логическим и физическим? Это зависит!
Итак, мое предложение:
- создать единый проектный документ.
- Назовите этот проектный документ так, как вы хотите, или, лучше, так, как читатели привыкли. Примеры: "Архитектура программного обеспечения", "Спецификация дизайна программного обеспечения".
- разбейте этот документ на представления и имейте в виду, что вы можете создать представление как уточнение другого представления.
- сделать представления в документе доступными, добавив перекрестные ссылки или гиперссылки
- тогда у вас будут представления более высокого уровня, показывающие широкий, но неглубокий обзор дизайна, и представления ближе к реализации, показывающие узкие, но более глубокие детали дизайна.
- Вы можете взглянуть на пример документа с несколькими представлениями архитектуры ( здесь).
Сказав все это... более актуальный вопрос, который мы должны задать: сколько дизайна достаточно? То есть, когда я должен перестать описывать дизайн (в схемах или прозе) и должен перейти к кодированию?
Я согласен со многими объяснениями; По сути, мы признаем различие между архитектурным дизайном и детальным дизайном программных систем.
В то время как цель дизайнера - быть настолько точным и конкретным в спецификациях, насколько это будет необходимо для разработки; по сути, архитектор нацелен на то, чтобы указать структуру и глобальное поведение системы в той мере, в какой это требуется для начала детального проектирования.
Хороший архитектор предотвратит гипер-спецификации - архитектура должна быть не слишком точной, а достаточной, чтобы (архитектурные) решения устанавливались только для аспектов, представляющих наиболее дорогостоящие риски, и эффективно обеспечивали структуру ("общность"), в рамках которой можно разработать детальный дизайн, то есть изменчивость для локальной функциональности.
Действительно, процесс архитектуры или жизненный цикл просто следует этой теме - адекватный уровень абстракции, чтобы наметить структуру для (архитектурно) значимых бизнес-требований и оставить больше деталей на этапе проектирования для получения более конкретных результатов.
Лично мне нравится этот:
"Дизайнер интересуется тем, что происходит, когда пользователь нажимает кнопку, а архитектор заботится о том, что происходит, когда десять тысяч пользователей нажимают кнопку".
Учебное пособие по SCEA для Java™ EE Марка Кейда и Хамфри Шейла
Довольно субъективно, но мое мнение:
Архитектура Общий дизайн системы, включая взаимодействие с другими системами, требования к оборудованию, общий дизайн компонентов и поток данных.
Проектирование Организация и поток компонента в общей системе. Это также будет включать API компонента для взаимодействия с другими компонентами.
Мне действительно понравилась эта статья для практического руководства по отделению архитектуры от дизайна:
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
Это называется гипотеза Интенсивность / Местность. Заявления о природе программного обеспечения, которые являются нелокальными и интенсифицированными, являются архитектурными. Утверждения, которые являются местными и интенсивными, являются дизайном.
Архитектура программного обеспечения "связана с проблемами... помимо алгоритмов и структур данных вычислений.
Архитектура, в частности, не связана с… деталями реализаций (например, алгоритмы и структуры данных). Архитектурное проектирование включает в себя более богатую коллекцию абстракций, чем обычно предоставляется OOD "(объектно-ориентированное проектирование).
Проектирование касается модульности и детальных интерфейсов элементов дизайна, их алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
"Архитектура" часто используется в качестве простого синонима "дизайна" (иногда ему предшествует прилагательное "высокий уровень"). И многие люди используют термин "архитектурные образцы" как синоним "дизайнерских образцов".
Проверьте эту ссылку.
Архитектура программного обеспечения программы или вычислительной системы - это структура или структуры системы, которые включают программные компоненты, видимые снаружи свойства этих компонентов и взаимосвязи между ними.
(из Википедии, http://en.wikipedia.org/wiki/Software_architecture)
Разработка программного обеспечения - это процесс решения проблем и планирования программного решения. После того как цель и спецификации программного обеспечения определены, разработчики программного обеспечения будут разрабатывать или нанимать дизайнеров для разработки плана решения. Он включает в себя вопросы реализации низкоуровневых компонентов и алгоритмов, а также архитектурное представление.
(из Википедии, http://en.wikipedia.org/wiki/Software_design)
Не мог бы сказать это лучше сам:)
Да, это звучит правильно для меня. Дизайн - это то, что вы собираетесь делать, а архитектура - это способ, которым кусочки дизайна соединяются вместе. Он может не зависеть от языка, но обычно определяет используемые технологии, например, LAMP v Windows, Web Service v RPC.
Хороший вопрос... Хотя грань между ними вряд ли является яркой, четкой линией, имхо, если вы используете оба термина, тогда архитектура включает в себя больше технических или структурных решений о том, как строить или конструировать что-то, особенно те решения, которые будут трудными (или сложнее) изменить после реализации, тогда как Design включает в себя те решения, которые впоследствии легко изменить (например, имена методов, организационная структура файла <-> класса, шаблоны проектирования, будь то использование одиночного или статического класса для решения какой-то конкретной проблемы). и т. д.) и / или те, которые влияют на внешний вид или эстетические аспекты системы или приложения (человеческий интерфейс, простота использования, внешний вид и т. д.)
Я рассматриваю архитектуру так же, как Патрик Керхер - общую картину. Например, вы можете предоставить архитектуру здания, просмотреть его структурную опору, окна, входы и выходы, канализацию и т. Д. Но вы не "спроектировали" планировку пола, расположение кабины и т. Д.
Таким образом, пока вы проектировали здание, вы не спроектировали планировку каждого офиса. Я думаю, что то же самое относится и к программному обеспечению.
Вы можете рассматривать проектирование макета, как "создание макета", хотя...
Архитектура:
Структурные проектные работы на более высоких уровнях абстракции, которые реализуют технически значимые требования в системе. Архитектура закладывает основу для дальнейшего дизайна.
Дизайн:
Искусство наполнения того, что архитектура делает не через итеративный процесс на каждом уровне абстракции.
... давным-давно в далеком месте философы беспокоились о разнице между одним и многими. Архитектура - это отношения, которые требуют многих. Архитектура имеет компоненты. Дизайн о контенте, который требует одного. Дизайн имеет свойства, качества, характеристики. Обычно мы думаем, что дизайн в архитектуре. Дуалистическое мышление дает многим первозданное. Но архитектура тоже в дизайне. Это все, как мы выбираем, чтобы посмотреть, что перед нами - один или много.
Если кто-то строит корабль, то его "архитектурными элементами" будут двигатель, корпус, электрические цепи и т. д. Для него двигателестроение станет "проектной работой".
Если он затем делегирует конструкцию движка другой команде, они создадут "архитектуру движка"...
Так что - это зависит от уровня абстракции или детализации. Архитектура одного человека может быть дизайном другого!
Архитектура - это "дизайнерские решения, которые трудно изменить".
После работы с TDD, что практически означает, что ваш дизайн постоянно меняется, я часто сталкиваюсь с этим вопросом. Вышеприведенное определение извлечено из " Шаблонов архитектуры корпоративных приложений" Мартина Фаулера
Это означает, что архитектура зависит от языка, структуры и домена вашей системы. Если вы можете просто извлечь интерфейс из вашего Java-класса за 5 минут, это уже не решение архитектуры.
Архитектура программного обеспечения лучше всего используется на системном уровне, когда вам необходимо проецировать бизнес и функции, идентифицированные на более высоких уровнях архитектуры, в приложения.
Например, ваш бизнес связан с "Прибыль и убыток" для трейдеров, а ваши основные функции включают "оценку портфеля" и "расчет риска".
Но когда архитектор программного обеспечения детализирует свое решение, он поймет, что:
"Оценка портфеля" не может быть только одним приложением. Это должно быть улучшено в управляемых проектах, таких как:
- графический интерфейс пользователя
- гранатомет
- диспетчер
- ...
(поскольку выполняемые операции настолько огромны, что их необходимо распределить между несколькими компьютерами, при этом все равно следя за ними через общий графический интерфейс)
При разработке программного обеспечения будут рассмотрены различные приложения, их технические взаимосвязи и их внутренние подкомпоненты.
Он создаст спецификации, необходимые для работы на последнем архитектурном уровне ("Техническая архитектура") (с точки зрения технической основы или сквозных компонентов), а также для начала работы проектных групп (более ориентированных на реализацию бизнес- функций). их соответствующие проекты.
Архитектура и дизайн тесно связаны; главное различие между ними заключается в том, каким образом мы сталкиваемся. Архитектура обращена к стратегии, структуре и цели, к абстрактному. Дизайн обращен к реализации и практике, к бетону.
Дизайн: чтобы узнать о модулях, какие отношения между модулями, функциональность каждого модуля, классы и его функции-члены, интерфейсы каждого модуля, которые общаются друг с другом.
Архитектура. Архитектура - это целая структура программной системы. Все модули, классы и компоненты выполняют разные задачи и дают уникальный результат.
Например: есть дом, который имеет 5 комнат. Также есть ванные комнаты. Кухня тоже есть в доме. Так что в доме есть разные вещи, и все эти вещи имеют разные отношения друг с другом. Так что это все о "дизайне" дома.
В то время как, когда вы смотрите снаружи дома, вся структура, на которую вы смотрите, полностью связана с архитектурой.
Кроме того, обратитесь к: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
Мне нравится определение и объяснение Роя Томаса Филдинга о том, что такое архитектура программного обеспечения в его статье: " Архитектурные стили и проектирование сетевых программных архитектур".
Архитектура программного обеспечения - это абстракция элементов времени выполнения системы программного обеспечения на некотором этапе ее работы. Система может состоять из множества уровней абстракции и многих этапов работы, каждый из которых имеет свою собственную программную архитектуру.
Он подчеркивает "элементы времени выполнения" и "уровни абстракции".
Архитектура - это итоговая коллекция шаблонов проектирования для построения системы.
Я предполагаю, что дизайн - это креативность, используемая, чтобы соединить все это?
Версия Cliff Notes:
Дизайн: Реализация решения на основе спецификаций желаемого продукта.
Архитектура: основа / инструменты / инфраструктура / компоненты, которые поддерживают ваш дизайн.
Это довольно широкий вопрос, который вызовет множество ответов.
Архитектура - это высокий уровень, абстрактный и логичный дизайн, в то время как программный дизайн - низкий уровень, детальный и физический дизайн.