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

Чи може хтось пояснити різницю між розробкою програмного забезпечення та архітектурою програмного забезпечення?

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

Моє сучасне розуміння:

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

Виправте мене, якщо я помиляюся. Я згадав, що у Вікіпедії є статті про http://en.wikipedia.org/wiki/Software_design та http://en.wikipedia.org/wiki/Software_architecture , але я не впевнений, чи правильно їх зрозумів.

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

Дизайн програмного забезпечення полягає в розробці окремих модулів / компонентів. Які обов'язки, функції модуля x? З класу Y? Що він може робити, а що ні? Які шаблони дизайну можна використовувати?

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

У деяких описах SDLC (Software Development Life Cycle) вони взаємозамінні, але суть полягає в тому, що вони відрізняються. Вони є одночасно: різними (1) етапами , (2) зонами відповідальності та (3) рівнями прийняття рішень .

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

Ці два етапи, здається, зливаються разом з різних причин.

1. Менші проекти часто не мають достатнього обсягу, щоб розділити їх планування на етапи.
2. Проект може бути частиною більшого проекту, і тому частини обох етапів уже вирішені. (Є вже існуючі бази даних, конвенції, стандарти, протоколи, рамки, код для багаторазового використання тощо)
3. Новіші способи мислення щодо SDLC (див. Методики Agile ) дещо переставляють цей традиційний підхід. Проектування (меншою мірою архітектура) відбувається за всією SDLC спеціально . Часто буває більше ітерацій, коли весь процес відбувається знову і знову.
4. Розробка програмного забезпечення складна і складна в будь-якому випадку планувати, але клієнти / менеджери / продавці зазвичай ускладнюють це, змінюючи цілі та вимоги середнього потоку. Проектні та навіть архітектурні рішення повинні бути згодом в проекті, чи це план чи ні.

Навіть якщо етапи чи зони відповідальності поєднуються разом і трапляються всюди, завжди добре знати, який рівень прийняття рішень відбувається. (Ми могли б продовжувати це з цим назавжди. Я намагаюся тримати це підсумком.) Я закінчу: Навіть якщо здається, що ваш проект не має офіційного архітектурного або дизайнерського етапу / AOR / documententaiton, це трапляється, чи хтось свідомо роби це чи ні. Якщо ніхто не вирішує займатися архітектурою, тоді трапляється за замовчуванням, що, ймовірно, погано. Дитто для дизайну. Ці поняття майже важливіші, якщо немає офіційних етапів їх представлення.

Архітектура є стратегічною, а дизайн - тактичною.

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

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

Я виявив це, шукаючи просте розмежування між архітектурою та дизайном;
Що ви думаєте про такий спосіб їх погляду:

• архітектура - це те, що ми будуємо;
• дизайн - це "як" ми будуємо;

1. Архітектура означає концептуальну структуру та логічну організацію комп'ютера або комп'ютерної системи.

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

2. Якщо ви "архітектуєте" компонент, ви визначаєте, як він поводиться у більшій системі.

   Якщо ви "проектуєте" один і той же компонент, ви визначаєте, як він поводиться всередині себе.

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

Whatчастина - це дизайн, Howконкретна реалізація та перетин Whatта Howє архітектура.

Зображення для розмежування архітектури та дизайну :

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

Будь-яке проектне рішення, яке не видно за межами його компонентної межі, є внутрішнім дизайном компонента і не є архітектурним. Це проектні рішення, які архітектор системи залишає на розсуд дизайнера модулів або команди з реалізації, доки їх дизайн не порушує архітектурні обмеження, накладені архітектурою системного рівня.

Посилання, що дає добру аналогію

Я б сказав, що ти маєш рацію, моїми власними словами;

Архітектура - це розподіл системних вимог до елементів системи. Чотири твердження про архітектуру:

1. Він може вводити нефункціональні вимоги, такі як мова чи зразки.
2. Він визначає взаємодію між компонентами, інтерфейсами, термінами тощо.
3. Він не повинен запроваджувати нові функціональні можливості,
4. Він виділяє (розроблені) функції, які система призначена виконувати елементам.

Архітектура є важливим інженерним кроком, коли складність системи підрозділяється.

Приклад: Подумайте про свій будинок, вам не потрібен архітектор для вашої кухні (задіяний лише один елемент), але вся будівля потребує певних визначень взаємодії, як двері та дах .

Дизайн - це інформативне представлення (запропонованої) реалізації функції. Він призначений для отримання зворотного зв'язку та обговорення із зацікавленими сторонами. Це може бути хорошою практикою, але не є важливим інженерним кроком .

Було б непогано побачити дизайн кухні перед установкою кухні, але це не є важливим для вимоги до приготування :

Якщо я подумаю про це, ви можете сказати:

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

Моє нагадування:

• Ми можемо змінити Дизайн, не запитуючи когось
• Якщо ми змінимо Архітектуру, нам потрібно повідомити її комусь (команді, клієнту, зацікавленій особі, ...)

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

Так, наприклад, якщо ви бачите діаграму класів або послідовну діаграму, ви можете зіставити клас і їх зв’язки з мовою програмування, орієнтованої на об'єкти, використовуючи синтаксичну побудову класу. Це однозначно Дизайн. Крім того, це може призвести до того, що ця дискусія має відношення до мови програмування, яку ви використовуєте для впровадження програмної системи. Якщо ви використовуєте Java, застосовується попередній приклад, оскільки Java - це об'єктно-орієнтована мова програмування. Якщо ви придумали діаграму, яка показує пакети та її залежності, це також Design. Ви можете зіставити елемент (пакунок у цьому випадку) в синтаксичну конструкцію Java.

Тепер, припустимо, ваша програма Java розділена на модулі, і кожен модуль - це набір пакетів (представлений у вигляді блоку розгортання файлів jar), і вам представлена ​​діаграма, що містить модулі та її залежності, тобто архітектура. Немає способу в Java (принаймні не до Java 7) зіставити модуль (набір пакетів) до синтаксичної конструкції. Ви також можете помітити, що ця діаграма є на крок вище рівня абстракції вашої моделі програмного забезпечення. Будь-яка діаграма вище (грубозерниста, ніж) схема діаграм пакетів, являє собою архітектурний вигляд при розробці на мові програмування Java. З іншого боку, якщо ви розробляєте модуль-2, то, модульна схема являє собою дизайн.

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

Особисто мені це подобається:

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

Посібник з дослідження SCEA для Java ™ EE від Марка Кейда та Хамфрі Шейла

Я згоден з багатьма поясненнями; по суті ми визнаємо відмінність між архітектурним дизайном та детальним дизайном програмних систем.

Хоча мета дизайнера полягає в тому, щоб бути максимально точним і конкретним у специфікаціях, наскільки це буде потрібно для розробки; архітектор по суті має на меті конкретизувати структуру та глобальну поведінку системи стільки, скільки потрібно для детального проектування.

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

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

Архітектура - це дизайн, але не весь дизайн є архітектурним. Тому, строго кажучи, було б доцільніше спробувати розмежувати архітектурний дизайн і не архітектурний дизайн . І в чому різниця? Це залежить! У кожного архітектора програмного забезпечення може бути різна відповідь (ymmv!). Ми розвиваємо нашу евристику, щоб вийти з відповіддю, наприклад, «діаграми класів - це архітектура, а діаграми послідовностей - це дизайн». Докладніше див. У книзі DSA .

Загальноприйнято говорити, що архітектура знаходиться на більш високому рівні абстракції, ніж дизайн, або архітектура є логічною, а дизайн - фізичним. Але це поняття, хоч і загальноприйняте, на практиці марне. Де ви проводите межу між високою або низькою абстракцією, між логічною та фізичною? Це залежить!

Отже, моя пропозиція:

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

Сказавши все це ... більш релевантним питанням, яке нам потрібно задати, є: на скільки вистачить дизайну? Тобто, коли я повинен перестати описувати дизайн (на схемах чи прозі) і повинен перейти до кодування?

Так, це здається мені правильним. Дизайн - це те, що ви збираєтеся робити, а архітектура - це спосіб з'єднання шматочків і фрагментів дизайну. Це може бути агностиком мови, але, як правило, вказувати використовувані технології, тобто LAMP v Windows, Web Service v RPC.

Архітектура програмного забезпечення програми або обчислювальної системи - це структура або структури системи, які містять програмні компоненти, зовнішні видимі властивості цих компонентів та взаємозв'язки між ними.

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

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

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

Я не міг би сказати це краще сам :)

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

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

Ви можете бачити проектування макета як "архітектуру макета", хоча ...

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

Архітектура програмного забезпечення "стосується питань ... поза алгоритмами та структурами даних обчислення.

Архітектура конкретно не стосується… деталей реалізацій (наприклад, алгоритмів та структур даних.) Архітектурне проектування передбачає більш багату колекцію абстракцій, ніж зазвичай надається OOD ”(об’єктно-орієнтована конструкція).

Дизайн стосується модуляризації та деталізованих інтерфейсів елементів дизайну, їх алгоритмів та процедур, а також типів даних, необхідних для підтримки архітектури та задоволення потреб.

"Архітектура" часто використовується як простий синонім "дизайн" (іноді передує прикметнику "високий рівень"). І багато людей використовують термін «архітектурні візерунки» як синонім «дизайнерських моделей».

Перевірте це посилання.

Визначення термінів Архітектура, дизайн та реалізація

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

Дизайн:
Мистецтво заповнення того, що архітектура не здійснює через ітераційний процес на кожному шарі абстракції.

Мені справді сподобався цей документ за правило про відділення архітектури від дизайну:

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

Це називається гіпотезою про інтенсивність / локальність. Заяви про характер програмного забезпечення, які є не локальними та інтенсивними, є архітектурними. Заяви, які мають місцевий та інтенсивний характер, є дизайном.

... давно в далекому місці філософи турбувалися про відмінність між тим і багатьма. Архітектура стосується відносин, яких вимагає багато. Архітектура має компоненти. Дизайн - це зміст, який вимагає одного. Дизайн має властивості, якості, характеристики. Ми зазвичай думаємо, що дизайн знаходиться в архітектурі. Дуалістичне мислення надає багатьом первісне. Але архітектура також входить в дизайн. Це все, як ми обираємо, щоб переглянути те, що перед нами - одне чи багато.

Досить суб’єктивно, але я вважаю:

Архітектура Загальний дизайн системи, включаючи взаємодію з іншими системами, вимоги до обладнання, загальний дизайн компонентів і потік даних.

Дизайн Організація та потік компонента в загальній системі. Сюди також слід включити API компонента для взаємодії з іншими компонентами.

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

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

Але коли архітектор програмного забезпечення детально розробить своє рішення, він зрозуміє, що:

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

• GUI
• Пускова установка
• Диспетчер
• ...

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

Програма програмного забезпечення буде вивчати різні програми, їх технічні відносини та їх внутрішні підкомпоненти.
Він створить специфікації, необхідні для останнього рівня архітектури ("Технічна архітектура") для роботи (з точки зору технічної бази або поперечних компонентів), а для проектних команд (більш орієнтованих на реалізацію бізнес- функцій) розпочнеться їхні відповідні проекти.

якщо хтось сконструює корабель, то його "архітектурними елементами" стануть двигун, корпус, електричні ланцюги тощо. Для нього будівництво двигунів буде "проектними роботами".

Якщо він потім делегує конструкцію двигуна іншій команді, вони створять "архітектуру двигуна" ...

Отже - це залежить від рівня абстракції чи деталізації. Архітектура однієї людини може бути чужим дизайном!

Архітектура - це "дизайнерські рішення, які важко змінити".

Після роботи з TDD, що практично означає, що ваш дизайн весь час змінюється, я часто стикався з цим питанням. Визначення, викладене вище, витягнуте з " Шаблони архітектури корпоративних додатків" Мартіна Фаулера

Це означає, що архітектура залежить від мови, основи та домену вашої системи. Якщо ви можете просто витягти інтерфейс зі свого Java класу за 5 хвилин, це вже не рішення архітектури.

Версія Cliff Notes:

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

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

Це досить широке запитання, яке спричинить багато відповідей.

Архітектура - це отримана колекція моделей дизайну для побудови системи.

Я здогадуюсь, Дизайн - це творчість, яка використовується для з’єднання всього цього?

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

Вчені, як правило, розглядають архітектуру як частину більш широкої галузі дизайну програмного забезпечення. Хоча зростає визнання, що Арка - це поле в межах власного.

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

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

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

Також зверніться до: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Мені подобаються визначення та пояснення Роя Томаса Філдінга про те, що таке архітектура програмного забезпечення в його статті: Архітектурні стилі та дизайн мережевих програмних архітектур

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

Він підкреслює "елементи часу виконання" та "рівні абстракції".

На це немає остаточної відповіді, оскільки "архітектура програмного забезпечення" та "дизайн програмного забезпечення" мають досить багато визначень, і для них немає канонічного визначення.

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

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

Корисна спроба відокремити архітектуру, дизайн та реалізацію як концепцій була зроблена Амноном Еденом та Ріком Казманом кілька років тому в дослідницькій роботі під назвою "Архітектура, дизайн, реалізація", яку можна знайти тут: http: //www.sei.cmu .edu / бібліотека / активи / ICSE03-1.pdf . Їх мова досить абстрактно , але спрощено вони кажуть , що архітектура є дизайном , який може бути використаний у багатьох ситуаціях і призначений для застосування в рамках всієї системи, дизайн є (ERR) дизайн , який може бути використаний у багатьох контекстах , але застосовується в певній частині системи, а реалізація - це дизайн, специфічний для конкретного контексту, і застосовується в цьому контексті.

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

Я сподіваюся, що це допомагає!