UML

março 3, 2010

É fato que modelagem é essencial para desenvolvermos sistemas de fácil manutenção e de boa qualidade. Porém, vez ou outra escuto alguém com a ideia de que para modelar devemos representar em UML todos os aspectos do sistema antes de iniciar a implementação, chamando isso de etapa de análise e projeto.

Não é novidade que isso não é nada produtivo e totalmente desnecessário. No livro UML Destilled do Martin Fowler, é proposta a abordagem de uso dos diagramas UML como rascunhos, com o objetivo de facilitar a comunicação na modelagem do sistema. Outros profissionais e autores respeitáveis também compartilham desta opinião. Por exemplo, o Ron Jeffries disse recentemente numa lista de discussão:

If you mean by UML occasionally drawing a picture on a bar napkin, I’m all for it. If you mean something more like using full-on UML to draw a comprehensive diagram of the entire object graph, it is a waste of time.

Designing in code works much better than UML for many people, mostly because when you design in UML you get UML and when you design in code you get the program.

Outro que também tem uma opinião parecida é o Robert Martin:

Look, modeling is an abstraction. We purposely suppress details to see the big picture. In order for these ‘modeling’ tools to generate executable code, they need all the details. Well, I have news for you. If you include all the detail, then you’re not modeling! You’re programming, albeit with a different language!

Concordo com eles, a UML é uma excelente ferramenta de modelagem e não uma linguagem de programação. Papel e caneta, ou quadro e pincel são ferramentas UML tão boas quanto o JBuilder ou o StarUML e demais ferramentas CASE.

Anúncios

Construção é projeto

abril 29, 2008

Escrevi uma tradução de um fragmento do livro “Software Project Secrets: Why Software Projects Fail”. Este trecho retrata bem a má interpretação que é feita do processo de desenvolvimento de software.

Construção é projeto

A construção de estradas consiste em uma sequência de fases bem definidas. O primeiro passo é planejar e projetar, o que resulta em um conjunto de planos e projetos (blueprints) que podem ser assinados. Uma vez que essas tarefas sejam concluídas a construção pode começar. A fase de construção consiste principalmente de tarefas bem definidas e repetitivas que podem ser executadas por empregados menos qualificados.
Ao contrário, o desenvolvimento de software é um processo de pesquisa, portanto em nenhum momento pode-se ter planos definitivos. Quanto mais definitivo tenta-se fazer os planos, mais falhos eles serão, e mais trabalho se terá ao revisá-los para que cumpram as mudanças de circunstâncias. Como a forma do sistema fica incrementalmente mais clara durante o curso do projeto, seu projeto (design) deve ser revisado constantemente. Reprojetar (redesign) a solução completamente de tempos em tempos pode ser custoso e desnecessário, portanto devemos pensar o projeto como um processo de design constante.
Sabemos que o trabalho repetitivo no desenvolvimento de software é rapidamente automatizado. Não existe nenhuma tarefa repetitiva a definir. Mas se as tarefas não são repetitivas, definí-las exaustivamente se torna um processo muito custoso em tempo. Ganha-se muito pouco definindo as tarefas dessa maneira. Software é abstrato, portanto definir as tarefas da construção completamente é equivalente a realizar o trabalho, pois existem ferrametas automatizadas que conseguem transformar estas definições em código.
Se as tarefas não podem ser bem definidas, então não podemos separar claramente as fases de design (projeto) e construção. Aliás, não existe fase de construção; o que existe é design (projeto) em escalas cada vez menores (níveis cada vez mais baixos). Isso significa que não podemos facilmente categorizar as pessoas nos papéis de arquitetos, projetistas (designers), programadores ou analistas. Estes papéis se sobrepoem. Todos os desenvolvedores têm o mesmo tipo de tarefas a fazer, apesar de uns terem mais responsabilidades que outros.
Quando um desenvolvedor cria uma nova funcionalidade num pedaço de software, a sua tarefa é simplesmente responder a seguinte pergunta “Essa funcionalidade irá funcionar exatamente como?”. Ele adiciona um conjunto de instruções ao código fonte que definem cada detalhe de como a funcionalidade funcionará. Porém, cada detalhe é uma decisão de projeto. Por exemplo, um fragmento de texto pode ser armazenado em um objeto imutável para uma maior eficiência, ou em um objeto mutável para maior flexibilidade. A escolha de uma dessas opções depende de como o texto será utilizado. É uma decisão bem significante.
Programar é mais do que apenas escrever código. Cada passo requer que o desenvolvedor analise uma parte do problema e projete uma parte da solução.

NOTA: Diferentemente de outros produtos, software não é construído, é projetado até a sua existência.

Acho que esse é um dos pontos em que as metodologias ágeis acertam e o RUP e os processos tradicionais falham. É um erro absurdo tratar a construção como uma tarefa repetitiva (tradução de diagramas para código fonte) que pode ser executada por empregados mais baratos (codificadores, programadores).
Como escutei lá no FISL, o movimento ágil é legal e funciona porque foi feito por programador para programador. É coisa de nerd mesmo!


Processos e confiança

abril 11, 2008

O processo de desenvolvimento de sw reflete totalmente a maneira como a empresa é administrada e como esta se relaciona com as pessoas.
Achei um artigo que compara alguns aspectos dos processos baseados no CMMI com os processos ágeis. Achei muito interessante a discussão sobre confiança.

The heart of the conversation was on the perception that if a model forces us to write something down then we are not trusted (the more we write stuff down, the less we trust one another).

Me parece ser bem adequada a colocação do autor, uma vez que um dos objetivos de toda a documentação que o CMMI impõe é a independência da empresa em relação às pessoas. Esse objetivo reflete de maneira muito clara a falta de confiança nas pessoas.