Design de software x arquitetura de software [fechado]

Alguém poderia explicar a diferença entre Design de Software e Arquitetura de Software?

Mais especificamente; se você disser a alguém para lhe apresentar o 'design' - o que você espera que ele apresente? O mesmo vale para 'arquitetura'.

Meu entendimento atual é:

• Projeto: diagrama UML / fluxograma / wireframes simples (para interface do usuário) para um módulo específico / parte do sistema
• Arquitetura: diagrama de componentes (mostrando como os diferentes módulos do sistema se comunicam entre si e com outros sistemas), que linguagem deve ser usada, padrões ...?

Corrija-me se eu estiver errado. Mencionei que a Wikipedia possui artigos em http://en.wikipedia.org/wiki/Software_design e http://en.wikipedia.org/wiki/Software_architecture , mas não tenho certeza se os compreendi corretamente.

Você está certo, sim. A arquitetura de um sistema é seu "esqueleto". É o nível mais alto de abstração de um sistema. Que tipo de armazenamento de dados está presente, como os módulos interagem entre si, quais sistemas de recuperação estão em vigor. Assim como os padrões de design, existem padrões de arquitetura: MVC, design em camadas de 3 camadas, etc.

O design de software trata da criação de módulos / componentes individuais. Quais são as responsabilidades, funções do módulo x? Da classe Y? O que pode fazer e o que não? Quais padrões de design podem ser usados?

Em resumo, a arquitetura de software é mais sobre o design de todo o sistema, enquanto o design de software enfatiza o nível do módulo / componente / classe.

Em algumas descrições do SDLC (Ciclo de Vida de Desenvolvimento de Software), eles são intercambiáveis, mas o consesus é que eles são distintos. Eles são ao mesmo tempo: diferentes (1) estágios , (2) áreas de responsabilidade e (3) níveis de tomada de decisão .

• A arquitetura é a visão geral: a escolha de estruturas, linguagens, escopo, objetivos e metodologias de alto nível ( Rational , cascata , ágil etc.).
• Design é a imagem menor: o plano de como o código será organizado; como serão os contratos entre diferentes partes do sistema; a implementação contínua das metodologias e objetivos do projeto. As especificações são escritas durante esta fase.

Esses dois estágios parecerão se misturar por diferentes razões.

1. Projetos menores geralmente não têm escopo suficiente para separar o planejamento nesses estágios.
2. Um projeto pode fazer parte de um projeto maior e, portanto, partes de ambos os estágios já estão decididas. (Já existem bancos de dados, convenções, padrões, protocolos, estruturas, código reutilizável etc.)
3. Novas maneiras de pensar sobre o SDLC (consulte metodologias ágeis ) reorganizam um pouco essa abordagem tradicional. O design (arquitetura em menor grau) ocorre em todo o SDLC de propósito . Muitas vezes, existem mais iterações em que todo o processo acontece repetidamente.
4. De qualquer maneira, o desenvolvimento de software é complicado e difícil de planejar, mas os clientes / gerentes / vendedores geralmente dificultam a mudança de metas e requisitos durante o processo. As decisões de design e até de arquitetura devem ser tomadas posteriormente no projeto, seja esse o plano ou não.

Mesmo que os estágios ou áreas de responsabilidade se misturem e aconteçam em todo o lugar, é sempre bom saber que nível de tomada de decisão está acontecendo. (Poderíamos continuar para sempre com isso. Estou tentando manter um resumo.) Terminarei com: Mesmo que pareça que seu projeto não tenha um estágio formal de arquitetura ou design / AOR / documentaiton, está acontecendo se alguém está conscientemente fazendo isso ou não. Se ninguém decide fazer arquitetura, acontece um padrão que provavelmente é ruim. O mesmo vale para o design. Esses conceitos são quase mais importantes se não houver estágios formais que os representem.

A arquitetura é estratégica, enquanto o design é tático.

A arquitetura compreende estruturas, ferramentas, paradigmas de programação, padrões de engenharia de software baseados em componentes, princípios de alto nível.

Embora o design seja uma atividade relacionada a restrições locais, como padrões de design, idiomas de programação e refatorações.

Eu encontrei isso enquanto procurava uma distinção simples entre arquitetura e design;
O que você acha dessa maneira de vê-los:

• arquitetura é "o que" estamos construindo;
• design é "como" estamos construindo;

1. Arquitetura significa a estrutura conceitual e organização lógica de um computador ou sistema baseado em computador.

   Projeto significa um plano ou desenho produzido para mostrar a aparência e a função ou funcionamento de um sistema ou objeto antes de ser feito.

2. Se você está “arquitetando” um componente, está definindo como ele se comporta no sistema maior.

   Se você está “projetando” o mesmo componente, está definindo como ele se comporta internamente.

Toda arquitetura é design, mas nem todo design é arquitetura.

Whatparte é o Design, a Howimplementação concreta e a interseção Whate Howé a Arquitetura.

Imagem para diferenciar Arquitetura e Design :

Também existem decisões de design, que não são arquitetonicamente significativas, ou seja, não pertencem ao ramo de arquitetura do design. Por exemplo, decisões internas de design de alguns componentes, como escolha de algoritmo, seleção da estrutura de dados etc.

Qualquer decisão de design que não seja visível fora do limite de seu componente é o design interno de um componente e não é arquitetural. Essas são as decisões de design que um arquiteto de sistema deixaria a critério do projetista do módulo ou da equipe de implementação, desde que o design não rompa as restrições arquiteturais impostas pela arquitetura no nível do sistema.

O link que dá uma boa analogia

Eu diria que você está certo, em minhas próprias palavras;

Arquitetura é a alocação de requisitos do sistema para elementos do sistema. Quatro declarações sobre uma arquitetura:

1. Ele pode introduzir requisitos não funcionais, como linguagem ou padrões.
2. Define a interação entre componentes, interfaces, tempo, etc.
3. Não deve introduzir novas funcionalidades,
4. Ele aloca as funções (projetadas) que o sistema se destina a executar nos elementos.

A arquitetura é uma etapa essencial da engenharia quando uma complexidade do sistema é subdividida.

Exemplo: pense em sua casa, você não precisa de um arquiteto para sua cozinha (apenas um elemento envolvido), mas o edifício completo precisa de algumas definições de interação, como portas e um telhado .

Design é uma representação informativa da implementação (proposta) da função. Pretende-se obter feedback e discutir com as partes interessadas. Pode ser uma boa prática, mas não é uma etapa essencial da engenharia .

Seria bom ver o design da cozinha antes de instalar a cozinha, mas isso não é essencial para os requisitos de cozimento :

Se eu pensar sobre isso, você pode declarar:

• arquitetura é para um público / engenheiros em um nível de abstração mais detalhado
• design é destinado ao público em um nível de abstração menos detalhado

Meu lembrete:

• Podemos mudar o design sem perguntar a alguém
• Se mudarmos a arquitetura, precisamos comunicá-la a alguém (equipe, cliente, parte interessada, ...)

Eu acho que devemos usar a regra a seguir para determinar quando falamos sobre Design x Arquitetura: Se os elementos de uma imagem de software que você criou podem ser mapeados de um para um para uma construção sintática da linguagem de programação, então é Design, se não for Arquitetura.

Portanto, por exemplo, se você estiver vendo um diagrama de classes ou um diagrama de sequência, poderá mapear uma classe e seus relacionamentos para uma linguagem de programação orientada a objetos usando a construção sintática de classe. Isso é claramente design. Além disso, isso pode trazer à tona que essa discussão tem uma relação com a linguagem de programação que você usará para implementar um sistema de software. Se você usa Java, o exemplo anterior se aplica, pois Java é uma Linguagem de Programação Orientada a Objetos. Se você criar um diagrama que mostra pacotes e suas dependências, isso também é Design. Você pode mapear o elemento (neste caso, um pacote) para uma construção sintática Java.

Agora, suponha que seu aplicativo Java seja dividido em módulos, e cada módulo seja um conjunto de pacotes (representado como uma unidade de implementação de arquivo jar), e você será apresentado a um diagrama contendo módulos e suas dependências, ou seja, Arquitetura. Não existe uma maneira em Java (pelo menos até o Java 7) mapear um módulo (um conjunto de pacotes) para uma construção sintática. Você também pode observar que este diagrama representa uma etapa mais alta no nível de abstração do seu modelo de software. Qualquer diagrama acima (de granulação grossa que) um diagrama de pacotes representa uma visualização da Arquitetura ao desenvolver na linguagem de programação Java. Por outro lado, se você estiver desenvolvendo no Modula-2, um diagrama de módulo representa um Design.

(Um fragmento de http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Pessoalmente, eu gosto deste:

"O designer está preocupado com o que acontece quando um usuário pressiona um botão, e o arquiteto está preocupado com o que acontece quando dez mil usuários pressionam um botão".

Guia de Estudo do SCEA para Java ™ EE de Mark Cade e Humphrey Sheil

Eu concordo com muitas das explicações; essencialmente, estamos reconhecendo a distinção entre o projeto arquitetônico e o projeto detalhado dos sistemas de software.

Embora o objetivo do projetista seja ser tão preciso e concreto nas especificações quanto necessário para o desenvolvimento; o arquiteto visa essencialmente especificar a estrutura e o comportamento global do sistema, tanto quanto necessário para começar o projeto detalhado.

Um bom arquiteto evitará hiperespecificações - a arquitetura não deve ser excessivamente especificada, mas apenas o suficiente, as decisões (arquitetônicas) estabelecidas apenas para os aspectos que apresentam riscos mais caros de serem tratados e fornecem efetivamente uma estrutura ("comunalidade") dentro da qual o projeto detalhado pode ser trabalhado, isto é, variabilidade para funcionalidade local.

De fato, o processo de arquitetura ou o ciclo de vida segue apenas esse tema - nível adequado de abstração para delinear a estrutura para os requisitos de negócios significativos (arquitetonicamente) e deixar mais detalhes na fase de design para entregas mais concretas.

Arquitetura é design, mas nem todo design é arquitetônico. Portanto, estritamente falando, faria mais sentido tentar diferenciar entre projeto arquitetônico e projeto não arquitetônico . e qual é a diferença? Depende! Cada arquiteto de software pode ter uma resposta diferente (ymmv!). Desenvolvemos nossas heurísticas para obter uma resposta, como 'diagramas de classes são arquitetura e diagramas de seqüência são design'. Veja o livro DSA para mais.

É comum dizer que a arquitetura está em um nível de abstração mais alto que o design, ou a arquitetura é lógica e o design é físico. Mas essa noção, embora comumente aceita, é na prática inútil. Onde você desenha a linha entre abstração alta ou baixa, entre lógica e física? Depende!

Então, minha sugestão é:

• crie um único documento de design.
• nomeie este documento de design da maneira que desejar ou, melhor, da maneira como os leitores estão mais acostumados. Exemplos: "Arquitetura de software", "Especificação de design de software".
• divida este documento em vistas e lembre-se de que você pode criar uma vista como um refinamento de outra vista.
• Torne as visualizações no documento navegáveis ​​adicionando referências cruzadas ou hiperlinks
• você terá vistas de nível superior, mostrando uma visão geral ampla, porém superficial, do design e vistas mais próximas da implementação, mostrando detalhes de design estreitos, mas mais profundos.
• você pode dar uma olhada em um exemplo de documento de arquitetura com várias visualizações ( aqui ).

Dito tudo isso ... uma pergunta mais relevante que precisamos fazer é: quanto design é suficiente? Ou seja, quando devo parar de descrever o design (em diagramas ou prosa) e passar para a codificação?

Sim, isso parece certo para mim. O design é o que você fará, e a arquitetura é a maneira pela qual os bits e partes do design serão unidos. Poderia ser independente do idioma, mas normalmente especificaria as tecnologias a serem usadas, por exemplo, LAMP v Windows, Serviço da Web v RPC.

A arquitetura de software de um programa ou sistema de computação é a estrutura ou estruturas do sistema, que compreende componentes de software, as propriedades visíveis externamente desses componentes e os relacionamentos entre eles.

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

O design de software é um processo de solução de problemas e planejamento de uma solução de software. Após a determinação do objetivo e das especificações do software, os desenvolvedores de software projetam ou empregam designers para desenvolver um plano para uma solução. Inclui problemas de implementação de componentes e algoritmos de baixo nível, bem como a visualização da arquitetura.

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

Não poderia ter dito melhor :)

Eu vejo a arquitetura como Patrick Karcher - o cenário geral. Por exemplo, você pode fornecer a arquitetura de um edifício, visualizar seu suporte estrutural, janelas, entradas e saídas, drenagem de água etc. Mas você não "projetou" o layout do piso, as posições dos cubículos, etc.

Portanto, enquanto você arquitetou o prédio, não projetou o layout de cada escritório. Eu acho que o mesmo vale para o software.

Você pode visualizar o design do layout, como "arquitetando o layout" ...

Boa pergunta ... Embora a linha entre eles dificilmente seja uma linha nítida e brilhante, se você estiver usando os dois termos, a Arquitetura engloba decisões mais técnicas ou estruturais sobre como construir ou construir algo, especialmente aquelas que serão difíceis ( ou mais difícil) mudar uma vez implementado, enquanto o Design abrange aquelas decisões que são fáceis de alterar posteriormente (como nomes de métodos, estrutura organizacional do arquivo de classe <->, padrões de design, se você deve usar um singleton ou uma classe estática para resolver algum problema específico , etc.) e / ou aqueles que afetam a aparência ou os aspectos estéticos de um sistema ou aplicativo (interface humana, facilidade de uso, aparência etc.)

A arquitetura de software está “preocupada com problemas ... além dos algoritmos e estruturas de dados da computação.

A arquitetura não se refere especificamente a ... detalhes de implementações (por exemplo, algoritmos e estruturas de dados). O projeto arquitetônico envolve uma coleção mais rica de abstrações do que normalmente é fornecida pelo OOD ”(design orientado a objetos).

O design se preocupa com a modularização e as interfaces detalhadas dos elementos do design, seus algoritmos e procedimentos e os tipos de dados necessários para suportar a arquitetura e satisfazer os requisitos.

"Arquitetura" é freqüentemente usada como mero sinônimo de "design" (às vezes precedido pelo adjetivo "alto nível"). E muitas pessoas usam o termo "padrões arquitetônicos" como sinônimo de "padrões de design".

Confira este link.

Definindo os termos Arquitetura, Design e Implementação

Arquitetura: o
projeto estrutural trabalha em níveis mais altos de abstração que atendem a requisitos tecnicamente significativos no sistema. A arquitetura estabelece as bases para um design adicional.

Design:
a arte de preencher o que a arquitetura não faz por meio de um processo iterativo em cada camada de abstração.

Gostei muito deste artigo como uma regra prática sobre a separação da arquitetura do design:

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

É chamada de hipótese de Intensão / Localidade. Declarações sobre a natureza do software que não são locais e intensivas são arquitetônicas. Declarações locais e intensivas são design.

... há muito tempo, em um lugar distante, filósofos preocupados com a distinção entre um e muitos. Arquitetura é sobre relacionamento, o que exige muitos. Arquitetura tem componentes. Design é sobre conteúdo, o que requer um. O design tem propriedades, qualidades, características. Normalmente pensamos que o design está dentro da arquitetura. O pensamento dualista dá a muitos como primordial. Mas a arquitetura também está dentro do design. É tudo como escolhemos ver o que está diante de nós - um ou muitos.

Muito subjetivo, mas minha opinião:

Arquitetura O design geral do sistema, incluindo interações com outros sistemas, requisitos de hardware, design geral dos componentes e fluxo de dados.

Design A organização e o fluxo de um componente no sistema geral. Isso também inclui a API do componente para interação com outros componentes.

A arquitetura de software é melhor usada no nível do sistema, quando você precisa projetar negócios e funções identificadas por níveis mais altos de arquitetura nos aplicativos.

Por exemplo, sua empresa trata de "Lucros e perdas" para traders, e suas principais funções envolvem "avaliação de portfólio" e "computação de risco".

Mas quando um arquiteto de software detalhar sua solução, ele perceberá que:

"avaliação de portfólio" não pode ser apenas um aplicativo. Ele precisa ser refinado em projetos gerenciáveis, como:

• GUI
• Launcher
• Expedidor
• ...

(porque as operações envolvidas são tão grandes que precisam ser divididas entre vários computadores, enquanto ainda são monitoradas o tempo todo por meio de uma GUI comum)

Um design de software examinará os diferentes aplicativos, seu relacionamento técnico e seus subcomponentes internos.
Ele produzirá as especificações necessárias para o trabalho da última camada de Arquitetura (a "Arquitetura Técnica") (em termos de estrutura técnica ou componentes transversais) e para o início das equipes do projeto (mais orientadas para a implementação das funções de negócios ) seus respectivos projetos.

se alguém constrói um navio, então o motor, o casco, os circuitos elétricos etc. serão seus "elementos arquitetônicos". Para ele, a construção do motor será "trabalho de design".

Se ele delegar a construção do mecanismo para outra equipe, eles criarão uma "arquitetura de mecanismo" ...

Então - depende do nível de abstração ou detalhe. A arquitetura de uma pessoa pode ser o design de outra!

Arquitetura são "as decisões de design difíceis de mudar".

Depois de trabalhar com o TDD, o que praticamente significa que o seu design muda o tempo todo, muitas vezes me vi lutando com essa pergunta. A definição acima é extraída de Patterns of Enterprise Application Architecture , por Martin Fowler

Isso significa que a arquitetura depende da linguagem, estrutura e domínio do seu sistema. Se você pode apenas extrair uma interface da sua Classe Java em 5 minutos, não é mais uma decisão da arquitetura.

Versão do Cliff Notes:

Design: Implementando uma solução com base nas especificações do produto desejado.

Arquitetura: a base / ferramentas / infraestrutura / componentes que dão suporte ao seu design.

Essa é uma pergunta bastante ampla que invocará muitas respostas.

Arquitetura é a coleção resultante de padrões de design para construir um sistema.

Eu acho que Design é a criatividade usada para juntar tudo isso?

O design de software tem uma história mais longa, enquanto o termo arquitetura de software tem apenas 20 anos. Por isso, está passando por dores de crescimento agora.

Os acadêmicos tendem a ver a arquitetura como parte de um campo maior de design de software. Embora haja um reconhecimento crescente de que o Arch é um campo em si.

Os profissionais tendem a ver a Arch como decisões de design de alto nível que são estratégicas e podem ser caras em um projeto para desfazer.

A linha exata entre o Arch e o design depende do domínio do software. Por exemplo, no domínio de aplicativos da Web, a arquitetura em camadas está ganhando mais popularidade atualmente (camada lógica de negócios, camada de acesso a dados etc.). As partes de nível inferior deste arco são consideradas design (diagramas de classes, assinaturas de métodos etc.). ) Isso seria definido de maneira diferente nos domínios de sistemas embarcados, sistemas operacionais, compiladores etc.

A arquitetura é de alto nível, design abstrato e lógico, enquanto o design de software é de baixo nível, detalhado e físico.

Além disso, consulte: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Gosto da definição e explicação de Roy Thomas Fielding sobre o que é arquitetura de software em seu artigo: Estilos arquitetônicos e design de arquiteturas de software baseadas em rede

Uma arquitetura de software é uma abstração dos elementos de tempo de execução de um sistema de software durante alguma fase de sua operação. Um sistema pode ser composto de muitos níveis de abstração e muitas fases de operação, cada um com sua própria arquitetura de software.

Ele enfatiza "elementos de tempo de execução" e "níveis de abstração".

Não existe uma resposta definitiva para isso, porque "arquitetura de software" e "design de software" têm várias definições e também não existe uma definição canônica.

Uma boa maneira de pensar sobre isso é a afirmação de Len Bass, Paul Clements e Rick Kazman de que "toda arquitetura é design, mas nem todo design é arquitetura" [Arquitetura de Software na Prática]. Não sei se concordo plenamente com isso (porque a arquitetura pode incluir outras atividades), mas captura a essência de que a arquitetura é uma atividade de design que lida com o subconjunto crítico do design.

Minha definição levemente irreverente (encontrada na página de definições do SEI ) é que é o conjunto de decisões que, se tomadas de maneira errada, fazem com que seu projeto seja cancelado.

Uma tentativa útil de separar arquitetura, design e implementação como conceitos foi realizada por Amnon Eden e Rick Kazman, há alguns anos, em um trabalho de pesquisa intitulado "Arquitetura, Design, Implementação", que pode ser encontrado aqui: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Sua linguagem é bastante abstrata, mas simplisticamente eles dizem que a arquitetura é um design que pode ser usado em muitos contextos e deve ser aplicado em todo o sistema, design é um design (err) que pode ser usado em muitos contextos, mas é aplicado em uma parte específica do sistema e a implementação é design específico para um contexto e aplicado nesse contexto.

Portanto, uma decisão de arquitetura pode ser uma decisão de integrar o sistema via sistema de mensagens em vez de RPC (portanto, é um princípio geral que pode ser aplicado em muitos locais e se destina a ser aplicado a todo o sistema), uma decisão de design pode ser o uso de um mestre / estrutura de encadeamento escravo no módulo de tratamento de solicitações de entrada do sistema (um princípio geral que poderia ser usado em qualquer lugar, mas neste caso é apenas usado em um módulo) e, finalmente, uma decisão de implementação pode ser a de transferir responsabilidades pela segurança do Request Router ao manipulador de solicitações no módulo Gerenciador de solicitações (uma decisão relevante apenas para esse contexto, usada nesse contexto).

Eu espero que isso ajude!