As necessidades de quem vai utilizar o software foram identificadas. Mas como representa-las de forma que o software possa ser desenvolvido?

Continuando a série A saga do herói… Ou melhor, do software!, hoje vamos falar sobre análise, a segunda atividade do desenvolvimento de software. No primeiro texto expliquei que, durante essa atividade, os analistas de sistemas usam os requisitos identificados para gerar uma série de modelos que descrevem o que o sistema deve fazer.

Existem várias notações a serem usadas, mas a UML (Unified Modeling Language) é vista como linguagem padrão para geração desses modelos. Ela foi organizada pela OMG (Object Management Group) e tem como objetivo fornecer mecanismos que permitam a visualização, especificação, documentação e comunicação de artefatos de software seguindo os conceitos de orientação a objetos (detalhes desses conceitos em texto futuro ?). Para isso, ela detalha 14 diagramas que ajudam a representar diferentes visões do software a ser desenvolvido, não sendo necessário utilizar todos esses diagramas em todos os projetos de desenvolvimento de software (você pode e deve escolher os diagramas adequados para cada situação!).

Para exemplificar como um software pode ser representado utilizando a UML, vou usar o cenário de um caixa eletrônico e alguns dos modelos oferecidos por ela. Simplificando um pouco tudo o que um software para esse cenário poderia fazer, digamos que nosso cliente, responsável pela automatização do banco em que trabalha, está interessado em um software que possibilite os correntistas do banco consultarem saldos e efetuarem saques/depósitos nos caixas eletrônicos espalhados pela cidade. Todas essas operações devem ser feitas com bastante segurança, para que não sejam debitados/creditados valores incorretos.

Um diagrama que podemos gerar para ter uma visão geral do sistema é o diagrama de casos de uso. Ele permite visualizar as funcionalidades oferecidas pelo software, associando-as aos atores responsáveis por elas. No exemplo do caixa eletrônico, por exemplo, sabemos que os correntistas do banco (cliente) podem consultar seus saldos e efetuar saques/depósitos. Mais do que isso, para garantir a segurança dessas operações, esse cliente precisará efetuar um login antes de iniciar a operação desejada.

Outro diagrama muito útil é o diagrama de atividades. Ele permite entender o comportamento dinâmico do software ou parte dele através do fluxo das ações realizadas. Pense em um saque. Ao chegar no caixa eletrônico, o correntista precisa selecionar a opção de saque, a partir da qual será solicitado que ele realize o seu login (seja por inserção de um cartão, uma senha, biometria etc.). Ele só poderá prosseguir com a operação de saque caso o login seja efetuado. Além disso, uma verificação do status da conta é realizada, para avaliar se essa conta está ou não ativa. Em caso positivo, o correntista informa a quantia que deseja sacar. Após algumas verificações, o caixa eletrônico ou (a) debita o dinheiro da conta e libera o saque, no caso de existir a quantia solicitada na conta do correntista e o caixa eletrônico possuir dinheiro, ou (b) informa que o saque está indisponível, caso contrário.

Além disso, devemos armazenar uma série de informações para que os clientes possam utilizar o software do caixa eletrônico. O diagrama de classes possibilita isso. Através dele conseguimos visualizar, por exemplo, que é necessário armazenar o nome, RG e CPF do cliente (vide “FichaCliente”) ou a senha, número, saldo e status da conta (vide “Conta”).

Além dos diagramas mencionados, outros diagramas mais técnicos também podem ser adotados. Abaixo, dois diagramas detalham aspectos mais dinâmicos do software. O diagrama de estados representa dois estados que uma conta pode assumir durante o uso do caixa eletrônico e o que faz com que ocorra uma mudança de um estado para outro. Por exemplo, após uma conta ser criada, ela passa a estar disponível para o caixa eletrônico, sendo possível realizar depósitos e saques da mesma. Ou, após 30 dias que uma conta está bloqueada, é necessário aplicar juros sobre a mesma.

Já o diagrama de sequência mostra a troca de mensagens que deve ocorrer ao longo do tempo para que as funcionalidades oferecidas pelo software sejam realizadas. Por exemplo, quando um correntista (cliente) efetua um saque, é necessário obter o número da conta dele de forma que seja verificado o status dessa conta e o saldo existente na mesma. Com isso, o sistema pode fazer as verificações necessárias para decidir se é possível debitar e liberar o valor solicitado ou se é necessário informar ao correntista a impossibilidade do saque.

Apesar de parecerem complexos, modelos ajudam muito na compreensão do software a ser desenvolvido. É como quando um prédio é construído e diferentes plantas (baixa, hidráulica, elétrica etc.) precisam ser geradas para orientar a obra (no nosso caso, obra = desenvolvimento do software). Conhecendo o objetivo e detalhes de cada diagrama oferecido pela UML, a equipe de TI tem um poderoso mecanismo para garantir que, lá no final do desenvolvimento, o software entregue realmente atenda às necessidades identificadas durante a atividade de levantamento de requisitos.