Design de software por pseudocoding?

Você conhece uma boa maneira de projetar (ou seja, escrever) um software com um método baseado em pseudocódigo?

Eu sou novo em design de software e leio algumas informações sobre UML. Minhas humildes hierarquias de classe são boas até agora, no entanto, depois que fica complexa, percebo que, ao "ver todo o quadro", eu poderia ter usado uma estrutura diferente para maior capacidade de expansão futura. Como o Python é bom para a criação de protótipos, estou quase bem em começar a escrever, mas não exatamente.

Então, tentei diagramas de classe UML, mas eles não parecem me ajudar muito. Os problemas que resolvo lá podem ser triviais na minha cabeça. Mas percebo requisitos adicionais de design quando começo a pseudocódigo dos métodos reais.

Então, se você quisesse criar um pseudocódigo, como faria? Acredito para mim um método que é aproximadamente 1 para 1 com código funciona melhor. Mas a maioria dos softwares UML nem mostra o código do método (ao contrário das imagens, por exemplo, no GoF).

Alguém afirmou que a UML é apenas para documentação e apresentação e não é ótima para design? Eu também tenho esse sentimento. Eu pensei que UML puro e alguns esboços simplistas do quadro branco eram a maneira de projetar software até pesquisar no Google no Envision APDT.

Então o desenvolvimento ágil é algo que eu deveria procurar ou eles chamam aleatoriamente de ágil? Ou estou projetando incorretamente (com UML) - alguém cria por pseudocódigo? Como posso encontrar uma boa ferramenta para isso?

 I thought agile is about schedule only?

Não é apenas planejamento. O desenvolvimento ágil de software tem mais a ver com ser um desenvolvimento evolutivo e uma entrega iterativa pontual com planejamento adaptativo que incentiva respostas flexíveis às mudanças solicitadas pelo proprietário do produto.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Na minha experiência, os gráficos são muito mais fáceis de entender do ponto de vista do cliente. Eles são visualmente atraentes e muitas vezes muito coloridos e fáceis de seguir. No entanto, é muito difícil manter gráficos devido à natureza da desconexão com o código do aplicativo real. Toda vez que uma alteração é feita no aplicativo, o desenvolvedor precisa reservar um tempo para atualizar toda a documentação, incluindo gráficos. No entanto, esse problema pode ser facilmente eliminado quando houver um BA na equipe ou empresa, que entenda bem o processo de negócios do cliente e possa gerenciar os diagramas UML.

Ferramentas como UML podem facilitar esse processo, mas só funcionam bem com programação orientada a objetos. O pseudo-código é muito mais fácil para as equipes técnicas. O processo de criação desse código aumenta muito a velocidade da fase de desenvolvimento da linguagem de programação real.

Existem outras alternativas que você também pode procurar:

• Diagramas de fluxo de dados
• Diagramas de Estado
• Fluxogramas do processo

Boas referências para procurar: Tutoriais de design de software . Além disso, eu pessoalmente aconselho a ler um bom blog sobre Pseudocódigo ou Código? Postado por Coding Horror - meu blog favorito para ler :)

Em suma, existem algumas vantagens e desvantagens que você precisa considerar.

Ao programar em linguagem assembly, escrever pseudo-código faz muito sentido. O algoritmo pode ser verificado antes de se esforçar para traduzi-lo manualmente para a linguagem assembly e depois depurar a tradução. Ainda fazia sentido para linguagens compiladas de primeira geração como o FORTRAN IV, onde o único construto de controle era GOTO, todas as variáveis ​​(exceto argumentos formais) eram globais e os nomes de variáveis ​​limitados a seis caracteres.

Hoje fazemos muito pouca programação em linguagem assembly, e vejo pouco valor em escrever pseudo-código em vez de apenas escrever código. Em uma linguagem decente, o código real seguirá o pseudo-código quase palavra por palavra, e o pseudo-código é apenas uma perda de tempo.

No entanto, não começo a codificar na parte inferior. Sigo o TDD e começo com um teste. Então começo a codificar na parte superior e gradualmente trabalho a parte inferior conforme necessário para que os testes sejam aprovados.

A alternativa ao pseudo-código não é escrever 1000 linhas de classes de baixo nível. Em vez disso, comece pelo topo, chamando a API ideal, mas inexistente, para seu domínio. Em seguida, crie a API.

Acho que os diagramas de classe mal valem o esforço, mesmo quando você pula a lista de todos os métodos e simplesmente mostra a hierarquia de herança. Os diagramas de sequência são bons, mas me sinto estranho quando os desenho (provavelmente apenas eu).

Acho que os diagramas de fluxo de dados e os gráficos de estrutura são mais úteis (embora os gráficos de estrutura sejam comumente associados ao BDUF e, portanto, estejam em falta no momento). DFDs são especialmente úteis para decomposição funcional. Cada "bolha" em um DFD pode ser dividida em seu próprio DFD até chegar ao nível de detalhe desejado.

Eu acho que as ferramentas gráficas são melhores do que o pseudocódigo, mas a UML é tão complicada demais que combina o mal nesses métodos :-)

Para ser um pouco mais claro: acho que a programação é principalmente uma maneira de analisar um determinado problema, separá-lo para componentes menores e sua interação. Isso é "uma jornada, não um destino", você aprimora constantemente seu conhecimento sobre o problema, para que o gráfico dos componentes esteja mudando: as camadas aparecem e desaparecem, as funções e os itens de dados se movem para cima e para baixo, etc.

A ferramenta natural para seguir esse processo é um painel de rascunhos, o mais simples possível, mas complexo o suficiente para ajudar no entendimento rápido (mesmas cores, formas, setas para o mesmo significado lógico). Não encontrei a bala de prata e talvez escreva minha própria um dia, mas agora uso gliffy ; combinado com o recurso de zoom do prezi , seria quase perfeito.

Por que não fazer pseudo-codificação? O pseudocódigo é um passo à frente na implementação, uma "forma serializada do gráfico de componentes", quando você ainda molda suas idéias. Não é bom, limita sua cabeça. Na minha experiência, descobri que quanto mais tarde começo a codificar, menos código tenho que jogar fora ...

Mas talvez seja porque eu escrevi todos esses códigos jogados fora, então não preciso escrevê-los agora, a experiência que obtive deles está comigo ao projetar o sistema? Bem, eu tenho que modificar a declaração.

Se você está perdido com o gráfico e vê muitas soluções possíveis equivalentes, vá ao pseudocódigo ou escreva esse código com objetos simulados - em Java, isso quase não faz diferença. Veja o código, sinta a estrutura e a usabilidade desses componentes, ele ajudará a corrigir seu gráfico e a tomar decisões. Mas isso só funciona se você estiver pronto para jogar fora esse código se achar que é ruim. Eu acho que essa é a vantagem do pseudocódigo: menos tentação para mantê-lo quando funciona, mas tem estrutura errada (e como sempre, você não tem tempo suficiente). :-)