Mostramos aqui quais papéis os desenvolvedores irão ocupar na MDA:
Analista de requisitos
- A análise de requisitos não muda. A captura dos requisitos em modelos UML que possam ser lidos pelo computador diminui as chances dessa análise ser mal-interpretada. Modelos UML como diagramas de atividade e diagramas de casos de uso ajudam na comunicação e visualização dos requisitos mas sua construção não pode ser automatizada.
Analista/Designer
- Os requisitos precisam ser expressados formalmente em outros tipos de diagramas como diagramas de classe e diagramas de transição de estado. A precisão desses diagramas é crucial, pois eles serão tranformados em outros modelos ou código, evitando modificações posteriores. No entanto apenas a lógica do negócio precisa ser embutida nesses modelos, não é necessário se preocupar com estruturas de dados, distribuição, concorrência, etc. O analista pode ainda utilizar uma ferramenta que gere UML executável, podendo obter assim, um feedback mais rápido com o cliente.
Arquiteto
- O arquiteto, como o próprio nome diz, cuidará da arquitetura do sistema, ou seja, sua estrutura geral. Ele utilizará sua experiência para selecionar os modelos e mapeamentos específicos para melhorar a performance do sistema, podendo inclusive reutilizar modelos e mapeamentos já pelo mercado.
Analista/Prorogramador
- O programador tem um papel semelhante, mas com duas diferenças essenciais. A primeira é que ele começará a se expressar no formato QVT (Query, Views & Transaction), não em uma linguagem convencional como Java ou C#. A segunda diferença é que ele criará regras mais genéricas: em vez de criar uma "lista para um conjunto de contas", ele criará uma regra para uma "lista de qualquer classe que tenha o mesmo padrão de acesso de uma conta". Assim a experiência do programador na plataforma é melhor usada, aumentando a influência do arquiteto de um design pontual para um design com visão de sistema.
Testador
- A criação de testes passa a ser mais eficiente com o auxílio de ferramentas que criam scripts de teste a partir dos modelos. O testador passa a ser mais produtivo, e a tarefa, menos tediosa.
Mantenedor
- A manutenção também torna-se mais produtiva por causa dos modelos, pois não é mais necessário entender a lógica lendo o código. O mantenedor pode realizar alterações diretamente no modelo. Uma alteração na lógica gera alterações no PIM, enquanto a mudança de tecnologia muda os mapeamentos utilizados.
Cliente
- O resultado é um produto melhor para o cliente.
Do artigo "Roles in the MDA Process" de Stephen J. Mellor e Andrew Watsono
Disponível aqui.
Nenhum comentário:
Postar um comentário