Дизайн программного обеспечения против.Архитектура программного обеспечения [закрыто]
https://stackoverflow.com/questions/704855
-
22-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Может ли кто-нибудь объяснить разницу между дизайном программного обеспечения и архитектурой программного обеспечения?
Более конкретно;если вы попросите кого-нибудь представить вам «дизайн» — чего вы ожидаете от него?То же самое касается и «архитектуры».
Мое нынешнее понимание:
- Дизайн:UML-диаграмма/блок-схема/простые каркасы (для пользовательского интерфейса) для конкретного модуля/части системы
- Архитектура:диаграмма компонентов (показывающая, как различные модули системы взаимодействуют друг с другом и другими системами), какой язык следует использовать, шаблоны...?
Поправьте меня если я ошибаюсь.Я упомянул, что в Википедии есть статьи на эту тему. http://en.wikipedia.org/wiki/Software_design и http://en.wikipedia.org/wiki/Software_architecture, но я не уверен, правильно ли я их понял.
Решение
Вы правы, да.Архитектура системы — это ее «скелет».Это высший уровень абстракции системы.Какое хранилище данных присутствует, как модули взаимодействуют между собой, какие системы восстановления установлены.Как и шаблоны проектирования, существуют архитектурные шаблоны:MVC, трехуровневый дизайн и т. д.
Проектирование программного обеспечения — это проектирование отдельных модулей/компонентов.Каковы обязанности и функции модуля x?Класса Y?Что оно может, а что нет?Какие шаблоны проектирования можно использовать?
Короче говоря, архитектура программного обеспечения больше связана с дизайном всей системы, тогда как дизайн программного обеспечения уделяет особое внимание уровню модуля/компонента/класса.
Другие советы
В некоторых описаниях SDLC (жизненный цикл разработки программного обеспечения) они взаимозаменяемы, но в конечном итоге они различны.Они одновременно:разные (1) этапы, (2) зоны ответственности, и (3) уровни принятия решений.
- Архитектура это более широкая картина:выбор фреймворков, языков, области применения, целей и методологий высокого уровня (Рациональный, водопад, гибкий, и т. д.).
- Дизайн это уменьшенная картинка:план организации кода;как будут выглядеть контракты между разными частями системы;продолжающийся выполнение методологий и целей проекта.На этом этапе пишутся спецификации.
Эти два этапа будут кажется смешиваться по разным причинам.
- Небольшие проекты часто не имеют достаточно возможностей для разделения планирования на этапы.
- Проект может быть частью более крупного проекта, и, следовательно, части обоих этапов уже определены.(Уже существуют базы данных, конвенции, стандарты, протоколы, фреймворки, многоразовый код и т. д.)
- Новые взгляды на SDLC (см. Гибкие методологии) несколько переформулировать этот традиционный подход.Проектирование (в меньшей степени архитектура) осуществляется на протяжении всего SDLC. нарочно.Часто их больше итерации где весь процесс происходит снова и снова.
- Разработка программного обеспечения в любом случае сложна, и ее трудно планировать, но клиенты/менеджеры/продавцы обычно усложняют задачу, меняя цели и требования на полпути.Дизайнерские и даже архитектурные решения должен будет сделано позже в проекте независимо от того, запланировано это или нет.
Даже если этапы или области ответственности сливаются воедино и происходят повсюду, всегда полезно знать, на каком уровне принятия решений происходит.(Мы могли бы продолжать это вечно.Я пытаюсь изложить это вкратце.) Закончу так:Даже если кажется, что ваш проект не имеет формальной архитектурной или проектной стадии/AOR/документации, это происходит независимо от того, делает ли кто-то это сознательно или нет.Если никто не решается заниматься архитектурой, то получается дефолтная, вероятно, плохая.То же самое и с дизайном.Эти понятия почти более важный если нет формальных стадий, представляющих их.
Архитектура стратегична, а дизайн тактичен.
Архитектура включает в себя структуры, инструменты, парадигмы программирования, стандарты разработки программного обеспечения на основе компонентов, принципы высокого уровня.
В то время как проектирование — это деятельность, связанная с локальными ограничениями, такими как шаблоны проектирования, идиомы программирования и рефакторинг.
Я нашел это, когда сам искал простое различие между архитектурой и дизайном;
Что вы думаете о таком взгляде на них:
- архитектура – это «то, что» мы строим;
- дизайн — это «как» мы строим;
Архитектура означает концептуальную структуру и логическую организацию компьютера или компьютерной системы.
Дизайн означает план или рисунок, созданный для того, чтобы показать внешний вид и функцию или работу системы или объекта до его создания.
Если вы «проектируете» компонент, вы определяете, как он будет вести себя в более крупной системе.
Если вы «проектируете» один и тот же компонент, вы определяете, как он будет вести себя внутри.
Вся архитектура — это дизайн, но НЕ весь дизайн — это архитектура.
What часть — это дизайн, How это конкретная реализация и пересечение What и How является Архитектура.
Изображение для различения архитектуры и дизайна:
Существуют также проектные решения, не являющиеся архитектурно значимыми, т.е.не принадлежит к архитектурной отрасли дизайна.Например, внутренние проектные решения некоторых компонентов, такие как выбор алгоритма, выбор структуры данных и т. д.
Любое проектное решение, которое не видно за пределами границ компонента, является внутренним проектом компонента и не является архитектурным.Это проектные решения, которые системный архитектор оставляет на усмотрение разработчика модуля или группы реализации, если их проект не нарушает архитектурные ограничения, налагаемые архитектурой уровня системы.
Ссылка, которая дает хорошая аналогия
Я бы сказал, что вы правы, своими словами;
Архитектура Это распределение системных требований по элементам системы.Четыре утверждения об архитектуре:
- Он может вводить нефункциональные требования, такие как язык или шаблоны.
- Он определяет взаимодействие между компонентами, интерфейсами, синхронизацией и т. д.
- Он не должен вводить новые функциональные возможности,
- Он распределяет (проектированные) функции, которые система должна выполнять, по элементам.
Архитектура – это важный инженерный шаг когда сложность системы подразделяется.
Пример:Подумайте о своем доме: вам не нужен архитектор для вашей кухни (используется только один элемент), но для всего здания нужны некоторые определения взаимодействия, такие как двери и крыша..
Дизайн является информативным представлением (предлагаемой) реализации функции.Он предназначен для получения обратной связи и обсуждения с заинтересованными сторонами.Возможно, это хорошая практика, но не является важным инженерным шагом.
Было бы неплохо увидеть дизайн кухни до ее установки, но это не обязательно для приготовления пищи.:
Если я подумаю об этом, вы можете сказать:
- архитектура предназначена для общественности/инженеров на более детальном уровне абстракции.
- дизайн предназначен для публики на менее детальном уровне абстракции
Моё напоминание:
- Мы можем изменить Дизайн, никого не спрашивая.
- Если мы изменим архитектуру, нам нужно будет сообщить об этом кому-то (команде, клиенту, заинтересованной стороне...).
Я думаю, нам следует использовать следующее правило, чтобы определить, когда мы говорим о дизайне и архитектуре:Если элементы созданного вами изображения программного обеспечения можно сопоставить один к одному с синтаксической конструкцией языка программирования, то это Дизайн, а если нет, то это Архитектура.
Так, например, если вы видите диаграмму классов или диаграмму последовательности, вы можете сопоставить класс и их отношения с языком объектно-ориентированного программирования, используя синтаксическую конструкцию класса.Это явно Дизайн.Кроме того, это может привести к тому, что это обсуждение имеет отношение к языку программирования, который вы будете использовать для реализации программной системы.Если вы используете Java, предыдущий пример применим, поскольку Java — это объектно-ориентированный язык программирования.Если вы придумали диаграмму, показывающую пакеты и их зависимости, это тоже дизайн.Вы можете сопоставить элемент (в данном случае пакет) с синтаксической конструкцией Java.
Теперь предположим, что ваше Java-приложение разделено на модули, и каждый модуль представляет собой набор пакетов (представленных в виде единицы развертывания файла jar), и вам представлена диаграмма, содержащая модули и их зависимости, то есть архитектура.В Java (по крайней мере, до Java 7) нет способа сопоставить модуль (набор пакетов) с синтаксической конструкцией.Вы также можете заметить, что эта диаграмма представляет собой ступеньку выше уровня абстракции вашей модели программного обеспечения.Любая диаграмма выше (крупнозернистой) диаграммы пакета представляет собой архитектурное представление при разработке на языке программирования Java.С другой стороны, если вы разрабатываете в Модуле-2, то диаграмма модуля представляет собой Дизайн.
(фрагмент из http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)
Лично мне нравится вот это:
«Дизайнера волнует то, что происходит, когда пользователь нажимает кнопку, а архитектора интересует, что происходит, когда кнопку нажимают десять тысяч пользователей».
Учебное пособие SCEA для Java™ EE Марк Кейд и Хамфри Шейл
Я согласен со многими объяснениями;по сути, мы признаем различие между архитектурным проектом и детальным проектированием программных систем.
Хотя цель дизайнера — составить настолько точные и конкретные спецификации, насколько это необходимо для разработки;Архитектор, по сути, стремится определить структуру и глобальное поведение системы в той степени, в которой это необходимо для начала детального проектирования.
Хороший архитектор будет избегать гиперспецификаций — архитектура не должна быть чрезмерно специфичной, а ровно настолько, (архитектурные) решения должны приниматься только для тех аспектов, которые представляют наиболее дорогостоящие риски для обработки, и эффективно обеспечивать структуру («общность»), внутри которой Над детальным дизайном можно работать, т.е.вариативность локальной функциональности.
Действительно, архитектурный процесс или жизненный цикл просто следует этой теме - адекватный уровень абстракции, чтобы наметить структуру для (архитектурно) значимых бизнес-требований и оставить более подробную информацию на этапе проектирования для более конкретных результатов.
Архитектура — это дизайн, но не весь дизайн — архитектурен. Поэтому, строго говоря, имело бы смысл попытаться провести различие между архитектурный дизайн и неархитектурный дизайн.И в чем разница?Это зависит!У каждого архитектора программного обеспечения может быть свой ответ (угу!).Мы разрабатываем эвристику, чтобы найти ответ, например: «диаграммы классов — это архитектура, а диаграммы последовательности — это дизайн».Видеть книга ДСА для большего.
Принято говорить, что архитектура находится на более высоком уровне абстракции, чем дизайн, или что архитектура логична, а дизайн физичен.Но это понятие, хотя и общепринятое, на практике бесполезно.Где вы проводите грань между высокой и низкой абстракцией, между логическим и физическим?Это зависит!
Итак, мое предложение:
- создать единый проектный документ.
- назовите этот дизайн-документ так, как вам хочется или, лучше, так, как привычнее читателям.Примеры:«Архитектура программного обеспечения», «Спецификация проектирования программного обеспечения».
- разбейте этот документ на представления и имейте в виду, что вы можете создать представление как уточнение другого представления.
- сделайте представления в документе доступными для навигации, добавив перекрестные ссылки или гиперссылки
- тогда у вас будут представления более высокого уровня, показывающие широкий, но поверхностный обзор проекта, и представления, более близкие к реализации, показывающие узкие, но более глубокие детали проекта.
- вы можете взглянуть на пример документа многопредставленной архитектуры (здесь).
Сказав все это... более актуальный вопрос, который нам нужно задать:насколько дизайна достаточно? То есть, когда мне следует перестать описывать дизайн (в схемах или прозе) и перейти к кодированию?
Да, это звучит правильно для меня.Дизайн — это то, что вы собираетесь делать, а архитектура — это способ объединения частей проекта воедино.Он может быть независимым от языка, но обычно определяет используемые технологии, например LAMP v Windows, веб-служба v RPC.
Архитектура программного обеспечения программы или вычислительной системы — это структура или структуры системы, которые включают компоненты программного обеспечения, видимые извне свойства этих компонентов и отношения между ними.
(из Википедии, http://en.wikipedia.org/wiki/Software_architecture)
Проектирование программного обеспечения — это процесс решения проблем и планирования программного решения.После того, как цель и характеристики программного обеспечения определены, разработчики программного обеспечения разрабатывают или нанимают дизайнеров для разработки плана решения.Он включает в себя вопросы реализации низкоуровневых компонентов и алгоритмов, а также архитектурное представление.
(из Википедии, http://en.wikipedia.org/wiki/Software_design)
Я сам не мог бы сказать лучше :)
Я рассматриваю архитектуру так же, как Патрик Керхер – общую картину.Например, вы можете представить архитектуру здания, просмотреть его структурную поддержку, окна, входы и выходы, канализацию и т. д.Но вы не «спроектировали» планировку этажа, расположение ячеек и т. д.
Таким образом, пока вы проектировали здание, вы не разработали планировку каждого офиса.Я думаю, то же самое справедливо и для программного обеспечения.
Однако вы можете рассматривать проектирование макета как «разработку макета»…
Хороший вопрос...Хотя грань между ними вряд ли можно назвать яркой и резкой, имхо, если вы используете оба термина, то архитектура включает в себя больше технических или структурных решений о том, как что-то построить или сконструировать, особенно те решения, которые будет трудно (или труднее) изменить. после реализации, тогда как проектирование включает в себя те решения, которые либо легко изменить позже (например, имена методов, организационная структура файлов классов <->, шаблоны проектирования, использовать ли одноэлементный или статический класс для решения какой-либо конкретной проблемы и т. д.).) и/или те, которые влияют на внешний вид или эстетические аспекты системы или приложения (человеческий интерфейс, простота использования, внешний вид и т. д.)
Программное обеспечение архитектура «занимается проблемами... выходящими за рамки алгоритмов и структур данных вычислений.
Архитектура — это, в частности, не… детали реализации (например, алгоритмы и структуры данных). Архитектурное проектирование включает в себя более богатый набор абстракций, чем обычно предоставляется ООД» (объектно-ориентированное проектирование).
Дизайн занимается модульностью и подробными интерфейсами элементов дизайна, их алгоритмами и процедурами, а также типами данных, необходимыми для поддержки архитектуры и удовлетворения требований.
«Архитектура» часто используется просто как синоним слова «дизайн» (иногда перед ним ставится прилагательное «высокий уровень»).Многие люди используют термин «архитектурные шаблоны» как синоним «шаблонов проектирования».
Проверьте эту ссылку.
Определение терминов «Архитектура», «Проектирование» и «Реализация»
Архитектура:
Структурное проектирование работает на более высоких уровнях абстракции, которые реализуют технически значимые требования к системе.Архитектура закладывает основу для дальнейшего проектирования.
Дизайн:
Искусство заполнения того, чего не делает архитектура, посредством итеративного процесса на каждом уровне абстракции.
Мне очень понравилась эта статья из-за практического правила отделения архитектуры от дизайна:
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
Это называется гипотезой интенсионала/локальности.Нелокальные и интенсиональные утверждения о природе программного обеспечения являются архитектурными.Локальные и интенсиональные высказывания являются замыслом.
...давным-давно в далеком месте философы беспокоились о различии между одним и многим.Архитектура — это отношения, которые требуют многих.Архитектура имеет компоненты.Дизайн — это контент, который требует одного.Дизайн имеет свойства, качества, характеристики.Обычно мы думаем, что дизайн находится внутри архитектуры.Дуалистическое мышление придает многим первобытность.Но архитектура также находится в дизайне.Все зависит от того, как мы решаем смотреть на то, что перед нами – на одно или на множество.
Довольно субъективно, но мое мнение:
АрхитектураОбщий дизайн системы, включая взаимодействие с другими системами, требования к оборудованию, общую конструкцию компонентов и поток данных.
ДизайнОрганизация и поток компонента в общей системе.Это также будет включать API компонента для взаимодействия с другими компонентами.
Архитектуру программного обеспечения лучше всего использовать на уровне системы, когда вам необходимо спроецировать бизнес и функции, идентифицированные более высокими уровнями архитектуры, в приложения.
Например, ваш бизнес связан с «прибылями и убытками» для трейдеров, а ваши основные функции связаны с «оценкой портфеля» и «расчетом рисков».
Но когда Архитектор программного обеспечения подробно расскажет свое решение, он поймет, что:
«Оценка портфеля» не может быть только одним приложением.Его необходимо доработать в управляемых проектах, таких как:
- графический интерфейс
- пусковая установка
- Диспетчер
- ...
(поскольку задействованные операции настолько велики, что их необходимо разделить между несколькими компьютерами, но при этом постоянно контролировать их через общий графический интерфейс)
При проектировании программного обеспечения будут рассмотрены различные приложения, их технические взаимоотношения и их внутренние подкомпоненты.
Он выдаст спецификации, необходимые для последнего Уровень архитектуры («Техническая архитектура») для работы (с точки зрения технической структуры или сквозных компонентов), а также для проектных групп (более ориентированных на реализацию бизнес функции), чтобы начать свои соответствующие проекты.
если кто-то строит корабль, то двигатель, корпус, электросхемы и т. д.будут его «архитектурными элементами».Для него создание двигателя будет «проектной работой».
Если он затем делегирует постройку двигателя другой команде, они создадут «архитектуру двигателя»…
Итак - это зависит от уровня абстракции или детализации.Архитектура одного человека может быть дизайном другого!
Архитектура «проектные решения, которые трудно изменить».
После работы с TDD, что практически означает, что ваш дизайн постоянно меняется, я часто сталкивался с этим вопросом.Приведенное выше определение взято из Шаблоны архитектуры корпоративных приложений, Мартин Фаулер
Это означает, что архитектура зависит от языка, платформы и домена вашей системы.Если вы можете просто извлечь интерфейс из вашего Java-класса за 5 минут, это уже не архитектурное решение.
Версия Cliff Notes:
Дизайн:Внедрение решения на основе характеристик желаемого продукта.
Архитектура:Основа/инструменты/инфраструктура/компоненты, поддерживающие ваш дизайн.
Это довольно обширный вопрос, который вызовет множество ответов.
Архитектура — это результирующий набор шаблонов проектирования для построения системы.
Я думаю, дизайн — это творческий подход, используемый для того, чтобы собрать все это воедино?
Проектирование программного обеспечения имеет более давнюю историю, тогда как термину «архитектура программного обеспечения» едва исполнилось 20 лет.Следовательно, сейчас он переживает проблемы роста.
Ученые склонны рассматривать архитектуру как часть более широкой области проектирования программного обеспечения.Хотя растет понимание того, что Arch — это отдельная область.
Практики склонны рассматривать Arch как проектные решения высокого уровня, которые являются стратегическими, и их отмена может оказаться дорогостоящей в проекте.
Точная грань между Arch и дизайном зависит от области программного обеспечения.Например, в области веб-приложений в настоящее время наибольшую популярность набирает многоуровневая архитектура (уровень бизнес-логики, уровень доступа к данным и т. д.). Части нижнего уровня этой архитектуры считаются проектированием (диаграммы классов, сигнатуры методов и т. д.). ) Это будет определяться по-другому в областях встроенных систем, операционных систем, компиляторов и т. д.
Архитектура — это высокоуровневый, абстрактный и логический дизайн, тогда как дизайн программного обеспечения — это низкоуровневый, детальный и физический дизайн.
Мне нравится определение и объяснение того, что такое архитектура программного обеспечения, данное Роем Томасом Филдингом в его статье:Архитектурные стили и проектирование сетевых архитектур программного обеспечения
Архитектура программного обеспечения — это абстракция элементов времени выполнения программной системы на определенном этапе ее работы.Система может состоять из многих уровней абстракции и многих этапов работы, каждый из которых имеет свою собственную программную архитектуру.
Он подчеркивает «элементы времени выполнения» и «уровни абстракции».
На этот вопрос нет однозначного ответа, поскольку «архитектура программного обеспечения» и «дизайн программного обеспечения» имеют довольно много определений, и ни для одного из них не существует канонического определения.
Хороший способ подумать об этом - это утверждение Лена Басса, Пола Клементса и Рика Казмана о том, что «вся архитектура — это дизайн, но не весь дизайн — это архитектура» [Архитектура программного обеспечения на практике].Я не уверен, что полностью согласен с этим (поскольку архитектура может включать в себя и другие виды деятельности), но это отражает суть того, что архитектура — это деятельность по проектированию, которая имеет дело с критическим подмножеством дизайна.
Моё слегка легкомысленное определение (найдено на Страница определений SEI) заключается в том, что это набор решений, ошибочное принятие которых приводит к отмене вашего проекта.
Полезная попытка разделить архитектуру, проектирование и реализацию как концепции была предпринята Амноном Иденом и Риком Казманом несколько лет назад в исследовательской статье под названием «Архитектура, проектирование, реализация», которую можно найти здесь: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf.Их язык довольно абстрактен, но в упрощенном виде они говорят, что архитектура — это дизайн, который можно использовать во многих контекстах и предназначен для применения во всей системе, дизайн это (ошибочный) дизайн, который может использоваться во многих контекстах, но применяется в определенной части системы, и выполнение это дизайн, специфичный для контекста и применяемый в этом контексте.
Таким образом, архитектурное решение может быть решением интегрировать систему посредством обмена сообщениями, а не RPC (так что это общий принцип, который может применяться во многих местах и предназначен для применения ко всей системе), проектным решением может быть использование главного /slave структура потока в модуле обработки входных запросов системы (общий принцип, который можно использовать где угодно, но в данном случае он используется только в одном модуле) и, наконец, решением по реализации может быть перенос ответственности за безопасность с маршрутизатора запросов. к обработчику запросов в модуле диспетчера запросов (решение, относящееся только к этому контексту и используемое в этом контексте).
Надеюсь, это поможет!
