Um desenvolvedor deve aderir aos diagramas de classe produzidos durante o design do sistema?

5

O diagrama de classes é modelado nos requisitos do sistema e é importante criar soluções com base nesses requisitos. Se eu disser diagrama de classes, devo segui-lo estritamente? E quanto a refatoração? E se o diagrama não fornecesse algum princípio de design que eu sinto que foi deixado de fora?

    
por Jonn 23.09.2010 / 15:41
fonte

3 respostas

5

Resposta curta: Não.

Sua saída deve estar funcionando (esperamos que tenha sido testada) código que executa a função de negócios que deveria fazer. Como você realiza essa tarefa não deve ser obrigatório (novamente, a menos que você trabalhe para a NASA).

Uma analogia idiota: eu entro em um táxi e digo a eles para onde ir. Deixo para eles me levarem até lá. Eu confio neles para me levar até lá com segurança e em tempo hábil. Eu não vou sentar lá e microgerenciar o taxista e dizer a ele quando ligar o sinal de sua vez, quanto apertar o acelerador, ou quando pegar gasolina. Esse é o trabalho dele.

    
por 23.09.2010 / 17:56
fonte
2

Você tem diagramas de classe em suas necessidades? Deve ser parte de uma especificação, não de suas necessidades, mas acho que as lojas de todos são diferentes;) É importante seguir suas especificações. Se você não fizer isso, você pode estar impactando outra área do aplicativo, mesmo sem saber quando você se desviar. Se a especificação estiver errada, você a reabre, comunique a alteração e faça a revisão e, em seguida, altere o código. Mesmo quando você discordar. Você pode não conhecer todos os motivos pelos quais uma implementação foi escolhida em detrimento de outra.

    
por 17.02.2011 / 17:24
fonte
0

Os pontos a seguir são apresentados para você considerar antes de tomar sua decisão, a ideia é examinar os fatores que geralmente afetariam um caso como o seu.

Ponto 0: você precisa implementar todas as regras de negócios, qualquer que seja seu estilo de implementação.

Ponto 1: Na UML, os Diagramas de Classes são apenas parte do modelo inteiro. Existem outros diagramas que utilizam classes definidas, como Caso de Uso, Sequência, etc.

Ponto 2: Em aplicações OO que usam o RDBMS, você precisa decidir se seu aplicativo é construído usando uma Abordagem Primeira Objeto ou uma Abordagem Inicial de Dados. Com base nisso, o modelo de domínio é criado. Os dois tipos de modelo podem ser muito diferentes. Veja: Objeto Relacional Imp. Missmatch .

Ponto 3: No OO e parcialmente como resultado do ponto # 3, os objetos que representam a camada do banco de dados podem ser diferentes dos objetos usados em outras camadas ou serviços do aplicativo. Se você estiver usando serviços da Web, provavelmente a API definiria objetos de uma maneira diferente da definição da camada de negócios e da camada de dados.

Ponto 4: os modelos UML têm fases, geralmente definidas por uma metodologia como em Mapeando Modelos para o Dev. Processo , cada fase pode produzir um modelo diferente. Alterar um modelo de fase de implementação é, obviamente, o menos desejável e mais crítico devido ao seu impacto.

Ponto 5: Você deve considerar o impacto da mudança no estágio do ciclo de vida do projeto, seus dados existentes, se houver, e sobre outros colegas de trabalho e DBAs.

    
por 10.11.2011 / 14:56
fonte

Tags