Como você planeja a arquitetura de um aplicativo antes de escrever qualquer código? [fechadas]

Uma coisa com a qual tenho dificuldade é planejar a arquitetura de um aplicativo antes de escrever qualquer código.

Não me refiro a reunir requisitos para restringir o que o aplicativo precisa fazer, mas sim pensar efetivamente sobre uma boa maneira de organizar a classe geral, as estruturas de dados e de fluxo, e iterar esses pensamentos para que eu tenha um plano confiável de ação em mente antes mesmo de abrir o IDE. No momento, é muito fácil apenas abrir o IDE, criar um projeto em branco, começar a escrever bits e bobs e deixar o design 'crescer' a partir daí.

Acho que UML é uma maneira de fazer isso, mas não tenho experiência com isso, então parece meio nebuloso.

Como você planeja a arquitetura de um aplicativo antes de escrever qualquer código? Se UML é o caminho a percorrer, você pode recomendar uma introdução concisa e prática para um desenvolvedor de aplicativos pequenos?

Agradeço sua opinião.

Eu realmente acho que escrever no papel ou no quadro branco é realmente crucial. Em seguida, mude para UML se quiser, mas nada supera a flexibilidade de apenas desenhar à mão no início.

Eu considero o seguinte:

1. o que o sistema deve fazer, ou seja, qual é o problema que o sistema está tentando resolver
2. quem é o cliente e quais são os seus desejos
3. com o que o sistema tem que se integrar
4. existem aspectos legados que precisam ser considerados
5. quais são as interações do usuário
6. etc ...

Então eu começo a olhar para o sistema como uma caixa preta e:

1. quais são as interações que precisam acontecer com aquela caixa preta
2. quais são os comportamentos que precisam acontecer dentro da caixa preta, ou seja, o que precisa acontecer com essas interações para que a caixa preta exiba o comportamento desejado em um nível superior, por exemplo, receber e processar mensagens de entrada de um sistema de reserva, atualizar um banco de dados etc. .

Então, isso vai começar a dar a você uma visão do sistema que consiste em várias caixas pretas internas, cada uma das quais pode ser dividida da mesma maneira.

UML é muito bom para representar esse comportamento. Você pode descrever a maioria dos sistemas usando apenas dois dos muitos componentes da UML, a saber:

• diagramas de classes e
• diagramas de seqüência.

Você também pode precisar de diagramas de atividades se houver algum paralelismo no comportamento que precise ser descrito.

Um bom recurso para aprender UML é o excelente livro de Martin Fowler "UML Distilled" ( link da Amazon - higienizado para o script kiddie link nazis por aí (-:). Este livro oferece uma visão rápida das partes essenciais de cada um dos componentes do UML.

Oh. O que descrevi é basicamente a abordagem de Ivar Jacobson. Jacobson é um dos Três Amigos de OO. Na verdade, a UML foi inicialmente desenvolvida por outras duas pessoas que formam os Três Amigos, Grady Booch e Jim Rumbaugh

Você definitivamente deve dar uma olhada no Code Complete de Steve McConnell - e especialmente em seu capítulo de doação sobre "Design in Construction"

Você pode baixá-lo de seu site:

http://cc2e.com/File.ashx?cid=336

Se você estiver desenvolvendo para .NET, a Microsoft acaba de publicar (como um e-book gratuito!) O Application Architecture Guide 2.0b1 . Ele fornece muitas informações realmente boas sobre como planejar sua arquitetura antes de escrever qualquer código.

Se você estiver desesperado, espero que possa usar grandes pedaços dele para arquiteturas não baseadas em .NET.

Vou começar dizendo que faço principalmente desenvolvimento web onde grande parte da arquitetura já está decidida com antecedência (WebForms, agora MVC) e a maioria dos meus projetos são razoavelmente pequenos, esforços de uma pessoa que levam menos de um ano. Também sei que terei um ORM e DAL para lidar com meu objeto de negócios e interação de dados, respectivamente. Recentemente, mudei para o uso do LINQ para isso, muito do "design" torna-se design e mapeamento de banco de dados por meio do designer DBML.

Normalmente, eu trabalho em uma maneira TDD (desenvolvimento dirigido por teste). Não passo muito tempo trabalhando em detalhes arquitetônicos ou de design. Eu obtenho a interação geral do usuário com o aplicativo por meio de histórias. Eu uso as histórias para trabalhar o design de interação e descobrir os principais componentes do aplicativo. Eu faço muitos quadros brancos durante esse processo com o cliente - às vezes capturando detalhes com uma câmera digital se eles parecem importantes o suficiente para manter a forma de diagrama. Principalmente minhas histórias são capturadas em forma de história em um wiki. Eventualmente, as histórias são organizadas em lançamentos e iterações.

A essa altura, geralmente tenho uma boa ideia da arquitetura. Se for complicado ou houver partes incomuns - coisas que diferem das minhas práticas normais - ou se estiver trabalhando com outra pessoa (não típico), vou fazer um diagrama das coisas (novamente em um quadro branco). O mesmo é verdadeiro para interações complicadas - posso projetar o layout da página e fluir em um quadro branco, mantendo-o (ou capturando pela câmera) até terminar essa seção. Assim que tiver uma ideia geral de para onde estou indo e o que precisa ser feito primeiro, começarei a escrever testes para as primeiras histórias. Normalmente, é assim: "Ok, para fazer isso, vou precisar dessas classes. Vou começar com este e ele precisa fazer isso." Então eu começo alegremente o TDD e a arquitetura / design cresce com as necessidades do aplicativo.

Periodicamente, fico querendo escrever alguns pedaços de código novamente ou penso "isso realmente cheira mal" e vou refatorar meu design para remover a duplicação ou substituir os pedaços fedorentos por algo mais elegante. Principalmente, estou preocupado em reduzir a funcionalidade e, ao mesmo tempo, seguir bons princípios de design. Acho que usar padrões conhecidos e prestar atenção aos bons princípios à medida que avança funciona muito bem.

http://dn.codegear.com/article/31863

Eu uso UML e acho esse guia muito útil e fácil de ler. Deixe-me saber se você precisa de algo diferente.

UML é uma notação. É uma forma de registrar seu design, mas não (na minha opinião) de fazer um design. Se você precisar anotar as coisas, eu recomendaria o UML, não porque seja o "melhor", mas porque é um padrão que outros provavelmente já sabem ler, e é melhor do que inventar seu próprio "padrão".

Acho que a melhor introdução à UML ainda é UML Distilled , de Martin Fowler, porque é concisa, dá orientações práticas sobre onde usá-la e deixa claro que você não precisa comprar toda a história da UML / RUP para que ela seja útil

Fazer design é difícil. Não pode ser capturado em uma resposta StackOverflow. Infelizmente, minhas habilidades de design, tais como são, evoluíram ao longo dos anos e, portanto, não tenho uma fonte a que possa encaminhá-lo.

No entanto, um modelo que achei útil é a análise de robustez (google para isso, mas há uma introdução aqui ). Se você tem seus casos de uso para o que o sistema deve fazer, um modelo de domínio de quais coisas estão envolvidas, então descobri que a análise de robustez é uma ferramenta útil para conectar os dois e descobrir quais componentes-chave do sistema precisam ser .

Mas o melhor conselho é lido amplamente, pense bastante e pratique. Não é uma habilidade puramente ensinável, você precisa realmente fazer isso.

Não sou inteligente o suficiente para planejar com antecedência. Quando eu planejo com antecedência, meus planos sempre dão errado, mas agora eu gastei n dias em planos ruins. Meu limite parece ser de cerca de 15 minutos no quadro branco.

Basicamente, faço o mínimo possível para descobrir se estou indo na direção certa.

Eu vejo meu projeto em busca de questões críticas: quando A faz B para C, será rápido o suficiente para D? Caso contrário, precisamos de um design diferente. Cada uma dessas perguntas pode ser respondida com um pico. Se as pontas parecerem boas, então temos o design e é hora de expandi-lo.

Eu codifico no sentido de obter algum valor real para o cliente o mais rápido possível, para que um cliente possa me dizer onde devo ir.

Como sempre entendo as coisas erradas, confio na refatoração para me ajudar a acertar. Refatorar é arriscado, então tenho que escrever testes de unidade enquanto prossigo. Escrever testes de unidade após o fato é difícil por causa do acoplamento, então eu escrevo meus testes primeiro. Manter a disciplina sobre essas coisas é difícil, e um cérebro diferente vê as coisas de maneira diferente, então gosto de ter um amigo codificando comigo. Meu amigo de programação tem nariz, então tomo banho regularmente.

Vamos chamá-lo de "Programação Extrema".

"Quadros brancos, esboços e notas de post-it são excelentes ferramentas de design. Ferramentas de modelagem complicadas tendem a distrair mais do que iluminar." De Practices of an Agile Developer, de Venkat Subramaniam e Andy Hunt .

Não estou convencido de nada podeser planejado com antecedência antes da implementação. Eu tenho 10 anos de experiência, mas isso aconteceu em apenas 4 empresas (incluindo 2 locais em uma empresa, que eram quase pólos opostos), e quase toda a minha experiência foi em termos de assistir a um cluster colossal. ****** ** s ocorrem. Estou começando a achar que coisas como refatorar são realmente a melhor maneira de fazer as coisas, mas, ao mesmo tempo, percebo que minha experiência é limitada e posso estar apenas reagindo ao que vi. O que eu realmente gostaria de saber é como obter a melhor experiência para poder chegar às conclusões adequadas, mas parece que não há atalhos e isso envolve apenas muito tempo vendo as pessoas fazendo coisas erradas :(. I realmente gostaria de tentar trabalhar em uma empresa onde as pessoas fazem as coisas certas (como evidenciado por implantações de produtos bem-sucedidas),

Eu discordo: UML pode ser usada para arquitetura de aplicativo, mas é mais frequentemente usada para arquitetura técnica (frameworks, classes ou diagramas de sequência, ...), porque é aqui que esses diagramas podem ser mais facilmente mantidos em sincronia com o desenvolvimento .

Arquitetura de Aplicativo ocorre quando você pega algumas especificações funcionais (que descrevem a natureza e os fluxos de operações sem fazer suposições sobre uma implementação futura) e as transforma em especificações técnicas.

Essas especificações representam os aplicativos de que você precisa para implementar algumas necessidades comerciais e funcionais.

Portanto, se você precisa processar várias grandes carteiras financeiras (especificação funcional), pode determinar que precisa dividir essa grande especificação em:

• um despachante para atribuir esses cálculos pesados ​​a diferentes servidores
• um inicializador para garantir que todos os servidores de cálculo estejam funcionando antes de começar a processar esses portfólios.
• uma GUI para poder mostrar o que está acontecendo.
• um componente "comum" para desenvolver os algoritmos específicos do portfólio, independentemente do resto da arquitetura da aplicação, a fim de facilitar os testes de unidade, mas também alguns testes funcionais e de regressão.

Então, basicamente, pensar sobre a arquitetura do aplicativo é decidir qual "grupo de arquivos" você precisa desenvolver de forma coerente (você não pode desenvolver no mesmo grupo de arquivos um iniciador, uma GUI, um despachante, ...: eles não seria capaz de evoluir no mesmo ritmo)

Quando uma arquitetura de aplicativo é bem definida, cada um de seus componentes é geralmente um bom candidato para um componente de configuração , ou seja, um grupo de arquivos que pode ser versionado como um tudo em um VCS (Version Control System), ou seja, todos os seus arquivos serão rotulados juntos toda vez que você precisar gravar um instantâneo desse aplicativo (novamente, seria difícil rotular todo o seu sistema, cada um de seus aplicativos não pode estar em um estado estável ao mesmo tempo)

Eu faço arquitetura há um tempo. Eu uso BPML para primeiro refinar o processo de negócios e então uso UML para capturar vários detalhes! A terceira etapa geralmente é ERD! Quando terminar de usar BPML e UML, seu ERD estará razoavelmente estável! Nenhum plano é perfeito e nenhuma abstração será 100%. Planeje a refatoração, o objetivo é minimizar a refatoração o máximo possível!

Tento dividir meu pensamento em duas áreas: uma representação das coisas que estou tentando manipular e o que pretendo fazer com elas.

Quando estou tentando modelar as coisas que estou tentando manipular, venho com uma série de definições de itens distintos - um site de comércio eletrônico terá um SKU, um produto, um cliente e assim por diante. Também terei algumas coisas não materiais com as quais estou trabalhando - um pedido ou uma categoria. Depois de ter todos os "substantivos" no sistema, farei um modelo de domínio que mostra como esses objetos estão relacionados uns aos outros - um pedido tem um cliente e vários SKUs, muitos skus são agrupados em um produto e assim em.

Esses modelos de domínio podem ser representados como modelos de domínio UML, diagramas de classes e SQL ERDs.

Uma vez que tenho os substantivos do sistema resolvidos, passo para os verbos - por exemplo, as operações pelas quais cada um desses itens passa para confirmar um pedido. Geralmente, eles mapeiam muito bem os casos de uso de meus requisitos funcionais - a maneira mais fácil de expressá-los que encontrei é sequência UML, atividades ou diagramas de colaboração ou diagramas de raia.

É importante pensar nisso como um processo iterativo; Vou fazer um pequeno canto do domínio, depois trabalhar nas ações e depois voltar. Idealmente, terei tempo para escrever o código para experimentar as coisas à medida que estou avançando - você nunca quer que o design fique muito à frente do aplicativo. Esse processo geralmente é terrível se você pensa que está construindo a arquitetura completa e final para tudo; na verdade, tudo o que você está tentando fazer é estabelecer os fundamentos básicos que a equipe terá em comum à medida que avança no desenvolvimento. Você está basicamente criando um vocabulário compartilhado para os membros da equipe usarem enquanto descrevem o sistema, não estabelecendo a lei de como isso deve ser feito.

Estou tendo problemas para pensar completamente em um sistema antes de codificá-lo. É muito fácil dar uma olhada superficial em alguns componentes que você só percebe mais tarde que são muito mais complicados do que você pensava que eram.

Uma solução é tentar muito. Escreva UML em qualquer lugar. Passe por todas as aulas. Pense em como ele irá interagir com suas outras classes. Isso é difícil de fazer.

O que eu gosto de fazer é primeiro fazer uma visão geral. Não gosto de UML, mas gosto de desenhar diagramas que transmitam a ideia. Então começo a implementá-lo. Mesmo enquanto estou apenas escrevendo a estrutura da classe com métodos vazios, frequentemente vejo coisas que deixei passar antes, então atualizo meu design. Enquanto estou programando, perceberei que preciso fazer algo diferente, então atualizarei meu design. É um processo iterativo . O conceito de "projetar tudo primeiro e depois implementar tudo" é conhecido como o modelo em cascata, e acho que outros mostraram que é uma maneira ruim de fazer software.

Experimente o Archimate.