A primeira observação é que não devemos fazer diagramas de sequência para todos os casos de uso do sistema. Apenas as partes mais complicadas devem ser exploradas para isso, pois este diagrama pode ser trabalhoso e criá-lo para todas as partes do sistema não seria produtivo nem traria benefícios extra.

Vejamos um caso prático, digamos um cadastro seguindo os moldes do já tradicional CRUD. Este tipo de módulo de sistema é tão bem resolvido que temos padrões de caso de uso, de análise e até de codificação, inclusive o Netbeans é capaz de gerar automaticamente. Neste caso, criar diagramas de sequência geraria uma enorme carga de trabalho, mas não traria nenhuma informação nova.

Uma boa dica para identificar casos de uso que devem gerar diagramas de sequência é buscar pelas quantidades de entidades e passos envolvidos. Isso não é uma regra fixa, mas pode ajudar bastante!

A segunda dica é procurar as ações descritas no caso de uso e podemos fazer isso identificando os verbos nas sentenças. Isto está relacionado ao fato de que os métodos (que são o ponto chave deste diagrama) modelam o comportamento dos objetos de uma classe e portanto o que pode ou não ser feito.

Essa relação entre ações e métodos direciona o analista para pensar em termos de código e é por isso que este diagrama faz parte da fase de projeto. Quando criamos um diagrama de sequência pensamos de forma mais concreta identificando nomes de métodos, dependências, tipos de retorno e listas de parâmetros. Dependendo da ferramenta gráfica utilizada os métodos adicionados nesta etapa já vão popular as classes, quando gerarmos o código esses esqueletos de método serão inseridos. Essa característica favorece até mesmo o uso de técnicas de teste já que com os métodos identificados fica mais fácil de gerar seus testes.

A seguir alguns exemplos de diagramas de sequência.

A primeira coisa a entender é que esta ferramenta é visual, no sentido de que define componentes visuais para representar os conceitos identificados em um sistema e as formas como esses conceitos se relacionam. Isto não quer dizer que a ferramenta tenha uma plataforma visual, sendo apenas uma especificação que diversos fabricantes usam para definir suas próprias plataformas (gratuitas ou pagas) para suportar o uso da ferramenta (UML). Isso significa, inclusive, que os fabricantes estão livres para representar internamente essas estruturas que compõe a especificação da forma que acharem mais conveniente. As evoluções no sentido de interpretar modelos para gerar código propostas pela MDA tentam convencer fabricantes para convergir para uma representação unificada (ou pelo menos de fornecer a capacidade de exportar em um modelo comum em XML) a fim de que possa ser possível processar a informação, já que a leitura de imagens seria totalmente sem cabimento.

A segunda coisa a ter em mente é que a UML não é uma metogologia, técnica ou processo para desenvolver sistemas. Simples assim, não é e pronto. Usar UML não significa ter um sistema orientado a objetos, não significa nem mesmo ter um sistema certo (nem certo do ponto de vista de realizar as funções esperadas pelo usuário, nem do ponto de vista de estar sem erros.) Possivelmente é nesta segunda etapa que os estudantes e usuários de UML tenham mais problemas.

Atualmente no mercado é praticamente impossível achar uma vaga de estágio ou emprego para desenvolvimento de sistemas que não peça conhecimentos de modelagem e de UML. Muitas vezes o que os empregadores não percebem é que o tanto que é requisitado, principalmente de estagiários, torna praticamente impossível contratar alguém, acabam que as entrevistas passam a ser mecanismos repletos de ficção, porque o candidato diz que sabe e o entrevistador tenta avaliar o melhor possível se isso é uma verdade. Considerando que os cursos de computação tem duração de 3 a 5 anos dependendo da instituição e do enfoque e que para o aluno entender realmente de anális e e desenvolvimento de sistemas demora até que tenha completado um ciclo de disciplinas que pode levar de 1 a 2 anos. Além disso, para que o aluno entenda como as disciplinas se relacionam também existe um tempo próprio. Então até que o aluno-candidato esteja pronto para fazer uma entrevista ele estará praticamente formado pelo curso e aí a ideia de um estágio já começa perder o sentido já que seu princípio é o de colocar na prática o que se está vendo no curso.

A relação entre esses tempos e o uso correto da UML está no fato de que são requisitos para o uso eficiente e correto da UML saber fazer análise e um processo de desenvolvimento de sistemas. Esses dois requisitos são extensos e densos por si só, e se não forem conhecidos corretamente não tem sentido usar UML. Vejamos porque:

• UML serve para documentar a análise – para documentar alguma coisa precisamos das técnicas para identificar essa coisa, em sistemas são técnicas de entrevista, escrita, itens tecnológicos (que vão fundamentar a infraestrutura do sistema e sua arquitetura,) textos, algoritmos e padrões entre outros. Se o analista não conhecer esses fundamentos corretamente não conseguirá fazer o levantamento de informações necessário para usar a UML.
• Diagramas da UML não têm uma ordem implícita – a UML define um conjunto de diagramas que são mais ou menos úteis em cada tipo de situação de desenvolvimento de sistemas, mas esses diagramas na verdade são TODOS opcionais, isso mesmo, o analista vai usar os diagramas que julgar mais importantes, que o cliente solicitar (quando o cliente tem um processo próprio), ou que se adequarem melhor à situação. Além disso, não tem nada na UML que diga que deve-se fazer primeiro o diagrama X ou Y, então por si só a UML não é capaz de definir o fluxo pelo qual vamos executar nosso trabalho a fim de conceber e desenvolver o sistema para o usuário. O efeito colateral disso é que muitas vezes o sistema é feito de maneira ad-hoc e no final são usadas ferramentas para gerar modelos reversos, ou seja, ler o código e gerar os diagramas. Está técnica de gerar modelos reversos é muito útil quando estamos tentando entender um sistema existente e não temos documentação nem acesso aos desenvolvedores originais da equipe, mas não deveria ser usada como técnica de desenvolvimento normal.

Então as empresas deveriam gastar mais tempo investindo em consolidar seus processos de desenvolvimento e treinar seus contratados do que buscar pessoas já prontas.

Além de saber usar a UML como linguagem para representar seus conceitos, o analista precisa dominar técnicas de levantamento e escrita das necessidades de seu cliente, a correta identificação dos requisitos é fundamental para o desenvolvimento de um sistema que atenda o cliente. E mais uma vez não existe representação de requisitos na UML, essa é uma outra parte que precisa ser realizada antes de partirmos para utilizá-la. Até mesmo os casos de uso que são tão falados não fazem parte da UML! O que existe na UML é um diagrama que representa as relações entre casos de usos bem como com seus atores, mas não quais os passos de um caso de uso. Até podemos falar que um diagrama de atividades poderia ser usado para representar os passos de um caso de uso, mas isso seria uma subutilização deste elemento.

Uma vez que o analista domine todos esses aspectos e essas dimensões chega a hora de usar a UML e nesse momento surge uma outra dúvida, qual ferramenta gráfica usar? Vale a pena mesmo usar uma ferramenta gráfica diretamente?

Existem várias ferramentas gráficas para UML gratuitas e pagas, com diferentes capacidades e recursos, e claro diferentes faixas de preços. Uma comparação entre as ferramentas precisa de um artigo próprio, mas uma coisa que pode ser evidenciada as ferramentas gratuitas apresentam realmente muitas limitações em relação as suas versões pagas. Se o custo for um fator determinante para o projeto (e normalmente é) deve-se levar em conta que as ferramentas que são integradas ao ambiente de desenvolvimento podem oferecer mais capacidades de geração de código e isso pode ajudar no desenvolvimento do projeto.

Quanto ao aspecto de quando começar a usar uma boa dica vem do pessoal de métodos agéis, que pregam que devemos fazer a análise em um quadro branco ou mesmo em uma janela, e somente depois de chegarmos a algum acordo básico sobre o que será feito devemos passar aquilo para uma ferramenta. Na verdade essa dica é bem compreensível porque a área visível que temos em qualquer ferramenta é muito menor do que qualquer quadro branco (ou janela) e como no início vamos fazer muitas modificações até chegar a uma versão mais estável então é muito incomodo trabalhar direto em uma ferramenta.

Então para encadearmos o conhecimento a melhor ideia é seguir:

1. Conhecer as técnicas de análise – permite escrever as necessidades do cliente
2. Conhecer um processo de desenvolvimento de sistemas – determina como encadear o que deve ser feito e quando deve ser feito
3. Conhecer a UML – contém os artefatos que são necessários para documentar o que foi analisado
4. Conhecer uma ferramenta gráfica UML – permite desenhar os conceitos e possivelmente gerar os códigos base para o sistema.

Seguindo essa ordem a chance de ter sucesso com o desenvolvimento de sistemas aumenta drasticamente porque passa a ser uma atividade coordenada.

Muitas vezes os casos de uso são confundindos com os diagramas de caso de uso, estes são representações gráficas que permitem visualizar os relacionamentos entre atores e casos de uso além de relações entre casos de uso. No entanto esses diagramas não apresentam quais são os passos necessários para atingir o objetivo do requisito funcional representado. Para que seja possível desenvolver um sistema, precisamos entender qual é a necessidade do usuário, e isso é feito com entrevistas que serão documentadas para nortear a criação ou atualização de módulos no sistema.

É importante utilizar o texto de um caso de uso para descrever, de forma clara e objetiva, o que precisa ser feito em cada funcionalidade do sistema. Neste aspecto uma característica interessante é que existem diversos modelos de casos de uso com mais ou menos seções, cada tipo se adequa melhor a um tipo de situação ou contexto de trabalho, mas são necessárias pelos menos seis seções:

1. Título – é o nome do caso de uso propriamente dito, pode incluir um código para simplificar as referências
2. Descri̤̣o Рpequeno texto que descreve a que esse caso de uso se refere, ou seja, explica de forma resumida o que acontece nesse caso de uso.
3. Pré-condições – são todas as condições que devem ser verdadeiras para que o caso de uso possa executar, então para o desenvolvedor significa que terão que ser testadas antes de seguir em frente. Uma pré-condição clássica: “Usuário precisa estar autenticado no sistema,” indica que devemos testar (de alguam forma) se o usuário está autenticado (além de ter autorização para acessar o recurso). Em sistemas web é muito comum tentar quebrar a segurança digitando o endereço de alguma página do sistema diretamente no browser.
4. Pós-condições – são todos os itens que garantimos como válidos se o caso de uso terminar com sucesso. Recibos impressos, dados salvos, e todo tipo de resultado obtido a partir da execução desse caso de uso.
5. Fluxo Principal – aqui descrevemos os passos, em uma lista numerada, para se atingir o objetivo do caso de uso. Aqui não devemos incluir referências a tecnologias específicas (tais como “clicar no botão” ou “fazer um insert no banco”) e consideramos que não acontecem erros, simplesmente porque fica muito mais fácil de enteder o que deve ser feito se pensarmos de forma isolada em um caso correto.
6. Fluxos Alternativos – descrevemos aqui todas as situações que podem acontecer em relação ao fluxo principal, situações de erro ou de desvio, por exemplo, usuário escolhe outra forma de pagamento por não ter dinheiro suficiente para a compra. Aqui fica fácil pensar de forma pontual em cada situação de falha ou exceção porque o fluxo principal está completo, então cada item de fluxo alternativo deve começar com o número do passo que referencia no fluxo principal e deve descrever textualmente qual é a situação de erro (ou exceção) que aconteceu, em seguida apresenta uma lista numerada de passos para contornar a situação.

É claro que existem outras seções possíveis, mas muitas vezes trabalhamos com sistemas pequenos/médios nos quais seções extra não agregam muita informação considerando o trabalho necessário para mantê-las. A primeira coisa a ter em mente é que não devemos utilizar associações com tecnologias, não deve ser usada nenhuma instrução de código, referências a tela ou bancos de dados. No entanto podemos ajudar na criação do sistema através do uso de certas palavras-chave para guiar o entendimento, a escrita é uma ferramenta fundamental no desenvolvimento de sistemas. Quando escrevemos que o usuário “seleciona” uma opção isso indica para o leitor que vai haver alguma maneira de escolher entre opções existentes e que serão apresentadas para ele, ou seja, ele não vai escrever um valor, apenas a forma de concretizar isso é que depende da tecnologia. Da mesma forma quando escrevemos que o usuário “informa” um valor, isso indica que deverá existir uma forma para o usuário inserir um texto livre, o que vai restringir será o tipo de dado, se utilizaremos um número inteiro, um número real ou um texto tal como um nome.

Uma outra característica interessante é o fato de que no Fluxo Principal devemos nos concentrar em apresentar para o usuário um cenário sem erros, isso é importante para que fique claro como atingir o objetivo daquele caso de uso, se misturarmos o tratamento de erro ou de exceção aos passos principais, pode ficar confuso o que é parte da solução e o que é situação de erro. Além disso, facilita muito termos um “roteiro” de como atingir o objetivo do caso de uso para então incluir os tratamentos de possíveis erros.