Software Design vs. Software Architecture [chiuso]

Qualcuno potrebbe spiegare la differenza tra Software Design e Software Architecture?

Più specificamente; se dici a qualcuno di presentarti il ​​"design" - cosa ti aspetti che presentino? Lo stesso vale per "architettura".

La mia attuale comprensione è:

• Design: diagramma UML / diagramma di flusso / wireframe semplici (per l'interfaccia utente) per un modulo specifico / parte del sistema
• Architettura: diagramma dei componenti (che mostra come i diversi moduli del sistema comunicano tra loro e con altri sistemi), che lingua usare, schemi ...?

Correggimi se sbaglio. Ho fatto riferimento a Wikipedia con articoli su http://en.wikipedia.org/wiki/Software_design e http://en.wikipedia.org/wiki/Software_architecture , ma non sono sicuro di averli compresi correttamente.

Hai ragione si. L'architettura di un sistema è il suo "scheletro". È il livello più alto di astrazione di un sistema. Che tipo di archiviazione dei dati è presente, in che modo i moduli interagiscono tra loro, quali sistemi di ripristino sono in atto. Proprio come i modelli di design, ci sono modelli di architettura: MVC, design a 3 livelli, ecc.

La progettazione del software riguarda la progettazione dei singoli moduli / componenti. Quali sono le responsabilità, le funzioni del modulo x? Di classe y? Cosa può fare e cosa no? Quali modelli di design possono essere utilizzati?

Quindi, in breve, l'architettura del software è più incentrata sulla progettazione dell'intero sistema, mentre la progettazione del software enfatizza il livello del modulo / componente / classe.

In alcune descrizioni dell'SDLC (Software Development Life Cycle) sono intercambiabili, ma il consesus è che sono distinti. Sono allo stesso tempo: diverse (1) fasi , (2) aree di responsabilità e (3) livelli di processo decisionale .

• L'architettura è il quadro più ampio: la scelta di framework, linguaggi, ambito, obiettivi e metodologie di alto livello ( razionale , a cascata , agile , ecc.).
• Il design è un quadro più piccolo: il piano per l'organizzazione del codice; come appariranno i contratti tra le diverse parti del sistema; l' implementazione in corso delle metodologie e degli obiettivi del progetto. Le specifiche sono scritte durante questa fase.

Queste due fasi sembreranno fondersi insieme per ragioni diverse.

1. I progetti più piccoli spesso non hanno abbastanza spazio per separare la pianificazione da questi a fasi.
2. Un progetto potrebbe far parte di un progetto più ampio, e quindi parti di entrambe le fasi sono già state decise. (Esistono già database, convenzioni, standard, protocolli, framework, codice riutilizzabile, ecc.)
3. I nuovi modi di pensare all'SDLC (vedi metodologie Agile ) in qualche modo riorganizzano questo approccio tradizionale. Il design (architettura in misura minore) si svolge appositamente in SDLC . Esistono spesso più iterazioni in cui l'intero processo si ripete all'infinito.
4. Lo sviluppo del software è comunque complicato e difficile da pianificare, ma i clienti / i gestori / i venditori di solito lo rendono più difficile cambiando obiettivi e requisiti a metà flusso. Le decisioni di progettazione e persino di architettura devono essere realizzate più avanti nel progetto, indipendentemente dal fatto che si tratti o meno del piano.

Anche se le fasi o le aree di responsabilità si fondono e si verificano in tutto il luogo, è sempre bene sapere quale livello di processo decisionale sta accadendo. (Potremmo continuare per sempre con questo. Sto cercando di mantenerlo in sintesi.) Concluderò con: Anche se sembra che il tuo progetto non abbia una fase formale di architettura o design / AOR / documentaiton, sta accadendo se qualcuno è farlo consapevolmente o no. Se nessuno decide di fare l'architettura, allora accade uno predefinito che probabilmente è scadente. Idem per il design. Questi concetti sono quasi più importanti se non ci sono fasi formali che li rappresentano.

L'architettura è strategica, mentre il design è tattico.

L'architettura comprende framework, strumenti, paradigmi di programmazione, standard di ingegneria del software basati su componenti, principi di alto livello.

Mentre il design è un'attività che riguarda i vincoli locali, come i modelli di progettazione, i linguaggi di programmazione e i refactoring.

L'ho trovato mentre cercavo una semplice distinzione tra architettura e design;
Cosa ne pensi di questo modo di guardarli:

• l'architettura è "cosa" stiamo costruendo;
• il design è "come" stiamo costruendo;

1. Architettura significa struttura concettuale e organizzazione logica di un computer o di un sistema basato su computer.

   Per design si intende un piano o un disegno prodotto per mostrare l'aspetto e la funzione o il funzionamento di un sistema o di un oggetto prima che sia realizzato.

2. Se stai "progettando" un componente, stai definendo come si comporta nel sistema più grande.

   Se stai "progettando" lo stesso componente, stai definendo come si comporta internamente.

Tutta l'architettura è design ma NON tutta la progettazione è architettura.

Whatparte è il Design, Howè l'implementazione concreta e l'intersezione di Whated Howè Architecture.

Immagine per differenziare architettura e design :

Ci sono anche decisioni di progettazione, che non sono significative dal punto di vista architettonico, cioè non appartengono al ramo dell'architettura del design. Ad esempio, le decisioni di progettazione interne di alcuni componenti, come la scelta dell'algoritmo, la selezione della struttura dei dati, ecc.

Qualsiasi decisione di progettazione, che non è visibile al di fuori del suo limite di componente, è una progettazione interna di un componente e non è architetturale. Queste sono le decisioni di progettazione che un architetto di sistema lascerebbe a discrezione del progettista del modulo o del team di implementazione, purché il loro design non rompa i vincoli architetturali imposti dall'architettura a livello di sistema.

Il collegamento che fornisce una buona analogia

Direi che hai ragione, con le mie stesse parole;

L'architettura è l'assegnazione dei requisiti di sistema agli elementi di sistema. Quattro dichiarazioni su un'architettura:

1. Può introdurre requisiti non funzionali come linguaggio o schemi.
2. Definisce l'interazione tra componenti, interfacce, tempistica, ecc.
3. Non deve introdurre nuove funzionalità,
4. Alloca le funzioni (progettate) che il sistema è destinato a svolgere sugli elementi.

L'architettura è un passaggio di ingegneria essenziale quando viene suddivisa una complessità del sistema.

Esempio: pensa alla tua casa, non hai bisogno di un architetto per la tua cucina (solo un elemento coinvolto) ma l'edificio completo ha bisogno di alcune definizioni di interazione, come porte e un tetto .

Il design è una rappresentazione informativa dell'implementazione (proposta) della funzione. Ha lo scopo di suscitare feedback e discutere con le parti interessate. Potrebbe essere una buona pratica ma non è un passaggio di ingegneria essenziale .

Sarebbe bello vedere il design della cucina vedere prima dell'installazione della cucina, ma non è essenziale per il requisito di cottura :

Se ci penso, puoi affermare:

• l'architettura è per un pubblico / ingegneri a un livello di astrazione più dettagliato
• il design è destinato al pubblico a un livello di astrazione meno dettagliato

Il mio promemoria:

• Possiamo cambiare il design senza chiedere a qualcuno
• Se cambiamo l'architettura dobbiamo comunicarla a qualcuno (team, cliente, stakeholder, ...)

Penso che dovremmo usare la seguente regola per determinare quando parliamo di Design vs Architecture: Se gli elementi di un'immagine software che hai creato possono essere mappati uno a uno su una costruzione sintattica del linguaggio di programmazione, allora è Design, se non è Architecture.

Quindi, ad esempio, se stai vedendo un diagramma di classe o un diagramma di sequenza, puoi mappare una classe e le sue relazioni con un linguaggio di programmazione orientato agli oggetti usando la costruzione sintattica della classe. Questo è chiaramente design. Inoltre, questo potrebbe portare al tavolo che questa discussione ha una relazione con il linguaggio di programmazione che userete per implementare un sistema software. Se si utilizza Java, si applica l'esempio precedente, poiché Java è un linguaggio di programmazione orientato agli oggetti. Se ti viene in mente un diagramma che mostra i pacchetti e le sue dipendenze, anche questo è Design. È possibile mappare l'elemento (un pacchetto in questo caso) su una costruzione sintattica Java.

Supponiamo ora che la tua applicazione Java sia divisa in moduli e che ogni modulo sia un insieme di pacchetti (rappresentato come unità di distribuzione di file jar) e che ti venga presentato un diagramma contenente i moduli e le relative dipendenze, quindi, ovvero Architecture. In Java (almeno non prima di Java 7) non esiste un modo per mappare un modulo (un insieme di pacchetti) su una costruzione sintattica. Potresti anche notare che questo diagramma rappresenta un livello superiore nel livello di astrazione del tuo modello software. Qualsiasi diagramma sopra (a grana grossa di) un diagramma di pacchetto, rappresenta una vista architettonica durante lo sviluppo nel linguaggio di programmazione Java. D'altra parte, se si sta sviluppando in Modula-2, quindi, un diagramma del modulo rappresenta un Design.

(Un frammento di http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Personalmente, mi piace questo:

"Il progettista si preoccupa di ciò che accade quando un utente preme un pulsante e l'architetto si preoccupa di ciò che accade quando diecimila utenti premono un pulsante".

SCEA per Java ™ EE Guida allo studio di Mark Cade e Humphrey Sheil

Sono d'accordo con molte delle spiegazioni; essenzialmente stiamo riconoscendo la distinzione tra la progettazione architettonica e la progettazione dettagliata dei sistemi software.

Mentre l'obiettivo del progettista è quello di essere preciso e concreto nelle specifiche come sarà necessario per lo sviluppo; l'architetto mira essenzialmente a specificare la struttura e il comportamento globale del sistema tanto quanto è necessario per iniziare la progettazione dettagliata.

Un buon architetto eviterà le iper-specifiche: l'architettura non deve essere eccessivamente specificata ma quanto basta, le decisioni (architettoniche) stabilite solo per gli aspetti che presentano rischi più costosi da gestire e forniscono effettivamente un quadro ("comunanza") all'interno del quale la progettazione dettagliata può essere elaborata in base alla variabilità per la funzionalità locale.

In effetti, il processo o il ciclo di vita dell'architettura segue proprio questo tema: un livello adeguato di astrazione per delineare la struttura per i requisiti aziendali (architettonicamente) significativi e lasciare maggiori dettagli alla fase di progettazione per risultati più concreti.

L'architettura è design, ma non tutto il design è architettonico. Pertanto, a rigor di termini, avrebbe più senso cercare di distinguere tra design architettonico e design non architettonico . E qual è la differenza? Dipende! Ogni architetto del software può avere una risposta diversa (ymmv!). Sviluppiamo la nostra euristica per trovare una risposta, ad esempio "i diagrammi di classe sono architettura e i diagrammi di sequenza sono design". Vedi il libro DSA per di più.

È comune affermare che l'architettura ha un livello di astrazione più elevato rispetto al design, oppure l'architettura è logica e il design è fisico. Ma questa nozione, sebbene comunemente accettata, è in pratica inutile. Dove traccia la linea tra alta o bassa astrazione, tra logica e fisica? Dipende!

Quindi, il mio suggerimento è:

• creare un unico documento di progettazione.
• nominare questo documento di design nel modo desiderato o, meglio, nel modo in cui i lettori sono più abituati. Esempi: "Software Architecture", "Software Design Specification".
• suddividere questo documento in viste e tenere presente che è possibile creare una vista come perfezionamento di un'altra vista.
• rendere navigabili le viste nel documento aggiungendo riferimenti incrociati o collegamenti ipertestuali
• quindi avrai viste di livello superiore che mostrano una panoramica ampia ma superficiale del design e viste più vicine all'implementazione che mostrano dettagli di progettazione ristretti ma più profondi.
• potresti voler dare un'occhiata a un esempio di documento di architettura multi-view ( qui ).

Detto questo ... una domanda più rilevante che dobbiamo porre è: quanto design è sufficiente? Cioè, quando dovrei smettere di descrivere il progetto (in diagrammi o in prosa) e passare alla codifica?

Sì, mi sembra giusto. Il design è ciò che farai e l'architettura è il modo in cui i pezzi del design verranno uniti. Potrebbe essere indipendente dal linguaggio, ma normalmente specifica le tecnologie da utilizzare, ad esempio LAMP v Windows, Web Service v RPC.

L'architettura software di un programma o sistema informatico è la struttura o le strutture del sistema, che comprendono componenti software, le proprietà visibili esternamente di tali componenti e le relazioni tra di essi.

(da Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

La progettazione del software è un processo di risoluzione dei problemi e pianificazione di una soluzione software. Dopo aver determinato lo scopo e le specifiche del software, gli sviluppatori del software progetteranno o impiegheranno i progettisti per sviluppare un piano per una soluzione. Include problemi di implementazione di componenti e algoritmi di basso livello e la vista architettonica.

(da Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Non avrei potuto dirlo meglio :)

Vedo l'architettura come Patrick Karcher - il quadro generale. Ad esempio, è possibile fornire l'architettura a un edificio, visualizzarne il supporto strutturale, le finestre, le entrate e le uscite, il drenaggio dell'acqua, ecc. Ma non è stato "progettato" il layout del pavimento, le posizioni dei cubicoli ecc.

Quindi, mentre hai progettato l'edificio, non hai progettato il layout di ogni ufficio. Penso che lo stesso valga per il software.

È possibile visualizzare la progettazione del layout come "architettura del layout" sebbene ...

Buona domanda ... Sebbene la linea tra loro non sia quasi una linea netta e brillante, tuttavia, se si utilizzano entrambi i termini, l'architettura comprende decisioni più tecniche o strutturali su come costruire o costruire qualcosa, in particolare quelle decisioni che saranno difficili ( o più difficile) da modificare una volta implementato, mentre il Design comprende quelle decisioni che possono essere facilmente modificate in un secondo momento (come nomi dei metodi, struttura dell'organizzazione dei file di classe <->, schemi di progettazione, se utilizzare un singleton o una classe statica per risolvere alcuni problemi specifici , ecc.) e / o quelli che influiscono sull'aspetto o sugli aspetti estetici di un sistema o di un'applicazione (interfaccia umana, facilità d'uso, aspetto grafico, ecc.)

Architettura del software è “interessata a problemi ... al di là degli algoritmi e delle strutture dati del calcolo.

L'architettura non riguarda in particolare ... i dettagli delle implementazioni (ad es. Algoritmi e strutture di dati). La progettazione architettonica implica una raccolta più ricca di astrazioni rispetto a quella fornita da OOD ”(progettazione orientata agli oggetti).

Design riguarda la modularizzazione e le interfacce dettagliate degli elementi di progettazione, i loro algoritmi e procedure e i tipi di dati necessari per supportare l'architettura e soddisfare i requisiti.

"Architettura" è spesso usato come un semplice sinonimo di "design" (talvolta preceduto dall'aggettivo "di alto livello"). E molte persone usano il termine "modelli architettonici" come sinonimo di "modelli progettuali".

Dai un'occhiata a questo link.

Definizione dei termini Architettura, progettazione e implementazione

Architettura:
lavori di progettazione strutturale a livelli più elevati di astrazione che realizzano requisiti tecnicamente significativi nel sistema. L'architettura pone le basi per ulteriori progetti.

Design:
l'arte di riempire ciò che l'architettura non fa attraverso un processo iterativo su ogni strato di astrazione.

Mi è piaciuto molto questo documento per una regola empirica sulla separazione dell'architettura dal design:

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

Si chiama ipotesi Intensione / Località. Le dichiarazioni sulla natura del software che non sono locali e intenzionali sono architettoniche. Dichiarazioni locali e intenzionali sono design.

... molto tempo fa in un luogo lontano i filosofi si preoccupavano della distinzione tra l'uno e i molti. L'architettura riguarda le relazioni, che richiedono molte. L'architettura ha componenti. Il design riguarda il contenuto, che richiede quello. Il design ha proprietà, qualità, caratteristiche. Generalmente pensiamo che il design sia all'interno dell'architettura. Il pensiero dualistico dà i molti come primordiali. Ma anche l'architettura è nel design. È tutto come scegliamo di vedere ciò che è davanti a noi - l'uno o i molti.

Abbastanza soggettivo ma la mia opinione:

Architettura La progettazione generale del sistema, comprese le interazioni con altri sistemi, i requisiti hardware, la progettazione generale dei componenti e il flusso di dati.

Progettazione Organizzazione e flusso di un componente nel sistema complessivo. Ciò include anche l'API del componente per l'interazione con altri componenti.

L'architettura software viene utilizzata al meglio a livello di sistema, quando è necessario proiettare business e funzioni identificabili da livelli di architettura più elevati in applicazioni.

Ad esempio, la tua attività riguarda "profitti e perdite" per i trader e le tue funzioni principali riguardano la "valutazione del portafoglio" e il "calcolo del rischio".

Ma quando un architetto del software descriverà in dettaglio la sua soluzione, si renderà conto che:

La "valutazione del portafoglio" non può essere solo un'applicazione. Deve essere perfezionato in progetti gestibili come:

• GUI
• Launcher
• Dispatcher
• ...

(poiché le operazioni coinvolte sono così enormi che devono essere suddivise tra più computer, pur essendo sempre monitorate attraverso una GUI comune)

una progettazione software esaminerà le diverse applicazioni, le loro relazioni tecniche e i loro sottocomponenti interni.
Produrrà le specifiche necessarie per il funzionamento dell'ultimo livello di Architettura (l '"Architettura tecnica") (in termini di quadro tecnico o componenti trasversali) e per l'avvio dei team di progetto (più orientati all'implementazione delle funzioni aziendali ) i loro rispettivi progetti.

se qualcuno costruisce una nave, allora motore, scafo, circuiti elettrici ecc. saranno i suoi "elementi architettonici". Per lui, la costruzione del motore sarà un "lavoro di progettazione".

Se poi delega la costruzione del motore a un altro team, creeranno una "architettura del motore" ...

Quindi - dipende dal livello di astrazione o dettaglio. L'architettura di una persona potrebbe essere il design di un altro!

L'architettura è "le decisioni di progettazione che sono difficili da cambiare".

Dopo aver lavorato con TDD, il che significa praticamente che il tuo design cambia continuamente, mi sono trovato spesso alle prese con questa domanda. La definizione sopra è estratta da Patterns of Enterprise Application Architecture , di Martin Fowler

Significa che l'architettura dipende dalla lingua, dalla struttura e dal dominio del sistema. Se riesci a estrarre un'interfaccia dalla tua classe Java in 5 minuti, non è più una decisione di architettura.

Versione di Cliff Notes:

Design: implementazione di una soluzione basata sulle specifiche del prodotto desiderato.

Architettura: la base / strumenti / infrastruttura / componenti che supportano la progettazione.

Questa è una domanda piuttosto ampia che invocherà molte risposte.

L'architettura è la raccolta risultante di modelli di progettazione per costruire un sistema.

Immagino che il design sia la creatività utilizzata per mettere tutto insieme?

La progettazione del software ha una storia più lunga mentre il termine architettura del software ha appena 20 anni. Quindi, sta attraversando dolori crescenti proprio ora.

Gli accademici tendono a vedere l'architettura come parte del più ampio campo della progettazione del software. Anche se c'è un crescente riconoscimento che Arch è un campo al suo interno.

I professionisti tendono a vedere Arch come decisioni di design di alto livello che sono strategiche e che possono essere costose in un progetto da annullare.

La linea esatta tra Arch e il design dipende dal dominio del software. Ad esempio, nel dominio delle applicazioni Web, l'architettura a più livelli sta guadagnando attualmente la maggiore popolarità (livello logico Biz, livello di accesso ai dati, ecc.) Le parti di livello inferiore di questo Arch sono considerate design (diagrammi di classe, firme dei metodi, ecc. ) Ciò sarebbe definito in modo diverso nei domini di sistemi integrati, sistemi operativi, compilatori, ecc.

L'architettura è di alto livello, progettazione astratta e logica, mentre la progettazione software è di basso livello, progettazione dettagliata e fisica.

Inoltre, fare riferimento a: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Mi piace la definizione e la spiegazione di Roy Thomas Fielding su ciò che è l'architettura software nel suo documento: stili architettonici e progettazione di architetture software basate su rete

Un'architettura software è un'astrazione degli elementi di runtime di un sistema software durante alcune fasi del suo funzionamento. Un sistema può essere composto da molti livelli di astrazione e molte fasi operative, ognuna con la propria architettura software.

Sottolinea "elementi run-time" e "livelli di astrazione".

Non esiste una risposta definitiva a questo perché "architettura del software" e "progettazione del software" hanno un certo numero di definizioni e non esiste una definizione canonica per nessuno dei due.

Un buon modo di pensarci è l'affermazione di Len Bass, Paul Clements e Rick Kazman secondo cui "tutta l'architettura è design ma non tutta la progettazione è architettura" [Software Architecture in Practice]. Non sono sicuro di essere abbastanza d'accordo con questo (perché l'architettura può includere altre attività) ma cattura l'essenza che l'architettura è un'attività di progettazione che si occupa del sottoinsieme critico del design.

La mia definizione leggermente fluttuante (trovata nella pagina delle definizioni SEI ) è che è l'insieme di decisioni che, se prese in modo errato, causano la cancellazione del progetto.

Un utile tentativo di separare architettura, design e implementazione come concetti è stato fatto alcuni anni fa da Amnon Eden e Rick Kazman in un documento di ricerca intitolato "Architecture, Design, Implementation" che può essere trovato qui: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Il loro linguaggio è piuttosto astratto, ma semplicisticamente affermano che l' architettura è un design che può essere utilizzato in molti contesti ed è pensato per essere applicato in tutto il sistema, il design è (err) design che può essere usato in molti contesti ma è applicato in una parte specifica del sistema e l' implementazione è specifica per un contesto e applicata in quel contesto.

Quindi una decisione architettonica potrebbe essere una decisione di integrare il sistema tramite messaggistica piuttosto che RPC (quindi è un principio generale che potrebbe essere applicato in molti luoghi ed è destinato ad applicarsi all'intero sistema), una decisione di progettazione potrebbe essere quella di utilizzare un master / struttura del thread slave nel modulo di gestione della richiesta di input del sistema (un principio generale che potrebbe essere utilizzato ovunque ma in questo caso viene utilizzato solo in un modulo) e, infine, una decisione di implementazione potrebbe essere quella di spostare le responsabilità per la sicurezza dal router di richiesta al Gestore richieste nel modulo Gestore richieste (una decisione pertinente solo a quel contesto, utilizzata in quel contesto).

Spero che aiuti!