Ao longo dos anos tenho estudado e praticado a modelagem de software com UML. Participei de vários foruns de discussão, li vários artigos acadêmicos, artigos do Gartner Group, medotologias como o RUP e livros. Muitos livros.
E como acredito que a teoria na prática é diferente, pratiquei muito do que estudei sobre modelagem seja no desenvolvimento de novos sistemas ou na manutenção de sistemas existentes. Os resultados? Nem sempre animadores…
Geralmente chegava ao final da modelagem com pressão sobre o prazo de entrega do projeto, e a pergunta que sempre ouvia era: quanto do código já está pronto? Eu ainda não tinha código pronto, “apenas” os modelos. E dá-lhe pressão de prazos…
Leia mais …
Um dos grandes desafios do desenvolvimento de um bom software, certamente está em se ter um processo consistente para se capturar as necessidades do cliente, traduzí-las em requisitos e a partir daí definir os casos de uso. A partir deste ponto, como chegar ao início da codificação?
Elaborei um mapa conceitual do que entendo ser uma abordagem prática de análise e projeto de software, contemplando os seguintes artefatos:
- Documento de Visão
- Modelo de Caso de Uso
- Protótipo de Telas e Especificação de Interface Visual
- Diagrama de Classes de Análise e de Projeto
- Documento de Arquitetura do Software
- Diagramas de seqüência
- Modelo de Dados
Com essa abordagem creio que se obtém um modelo de análise e projeto consistente para o início da codificação. Veja o mapa conceitual dessa abordagem na figura abaixo. O que você acha a respeito dessa abordagem?
A comunidade de software livre tem ao longo dos anos influenciado a indústria de software tradicional, no sentido de forçá-la a oferecer alguma versão dos seus produtos para uso sem custo. Empresas grandes como a IBM já adotaram essa abordagem de ofertar uma versão livre de alguns de seus softwares pagos.
Para a modelagem de software utilizando UML tenho usado para fins acadêmicos o Visual Paradigm Community Edition, que é uma versão sem custo e com algumas limitações em relação à versão paga, como por exemplo, só poder criar um diagrama UML de cada tipo sem que apareça a marca d’água da empresa nos diagramas. Uma outra restrição é a de não ter uma funcionalidade que permita o desenho da interface gráfica (elaboração de protótipos de telas)
Essa versão suporta todos os diagramas da UML 2.1, permite a descrição detalhada de requisitos, análise textual dos requisitos para identificação de classes, análise através de cartões CRC e diversas outras funcionalidades relacionadas à etapa de projeto de software.
O Visual Paradigm Community Edition pode ser obtido a partir do endereço http://www.visual-paradigm.com/product/vpuml/communityedition.jsp
Se é de uma ferramenta para modelagem UML que você procura, vale a pena instalar essa versão e testar suas funcionalidades, antes mesmo se for o caso, de partir para a compra de uma versão paga
Nos últimos anos tenho trabalhado bastante com a utilização da técnica de caso de uso tanto para validação das funcionalidades com o usuário, quanto para apoiar a etapa de análise e projeto do software visando um desenvolvimento orientado a casos de uso e que resulte num conjunto de especificações do software que possa ser construído por um programador.
A questão que trago aqui é a que muitos autores recomendam que a descrição do caso de uso deva ser genérica, independente de tecnologia ocultando assim detalhes de implementação e no extremo da abstração, a descrição fica até desassociada da interface gráfica.
Tenho visto que quando se adota essa abordagem, a descrição do caso de uso acaba tendo pouca utilidade, só servindo muitas vezes para validar as funcionalidades de software com o usuário, e mesmo assim com algumas limitações. Para a etapa de análise onde se deseja identificar as classes, suas propriedades e comportamentos, a descrição do caso de uso se torna abstrata, ambígua e incompleta. Daí decorre um problema: ela não ajuda na análise, não é atualizada e daí em diante a análise e o projeto seguem sem as descrições dos casos de uso. Perde-se portanto um importante instrumento para dirigir a analise o projeto e os testes do software.
Penso que ao decidir orientar o desenvolvimento por casos de uso, e isso é muito forte, as descrições de caso de uso devam sim ser detalhadas, escritas na voz ativa, de forma clara e sem ambigüidades. Deve-se escrever os casos de uso mão só pensando no cliente, mas também como eles irão ser úteis na fase de análise de projeto do software. Não esquecer também que um caso de uso fica bem mais preciso quando escrito a partir de alguns esboços da interface gráfica.
Veja esses dois exemplos para um caso de uso RESERVAR VEÍCULO (para um sistema de locadora de veículos). Qual descrição lhe parece mais adequada tanto para a validação pelo cliente, quanto para orientar a análise, o projeto e o teste do software?
| Exemplo 1 |
Exemplo 2 |
|
1.O caso de uso se inicia quando o cliente acessa o site, faz autenticação com seu usuário e senha, e seleciona a opção reservar veículo
2. O sistema solicita ao cliente informar o local, data e horário de retirada e devolução do carro . O cliente indica as datas e locais desejados.
3. O sistema pede para o tipo de veículo que o cliente deseja. O cliente indica o tipo de veículo.
4. O sistema apresenta todos os veículos disponíveis no local data e horário de retirada selecionado. Se o cliente solicitar informações detalhadas sobre um determinado veículo, o sistema apresenta esta informação para o cliente.
5. Se o cliente escolhe um veículo para aluguel, o sistema pede a identificação do cliente. O cliente fornece as informações necessárias.
6. O sistema apresenta informações sobre produtos de proteção e pede ao cliente para aceitar ou recusar cada produto. O cliente indica sua escolha.
7. Se o cliente indica "aceitar reservas", o sistema informa o cliente de que a reserva foi concluída, e apresenta ao cliente uma confirmação de reserva.
8. Este caso de uso termina quando a confirmação da reserva foi apresentado ao cliente.
|
1.O cliente seleciona a opção de efetuar reserva O sistema exibe a página de localidade de retirada e entrega e categoria de carro desejado. O cliente seleciona a localidade de retirada (estado, cidade,loja, data e hora) e de entrega (estado, cidade,loja, data e hora) e a categoria de carro (pequeno, médio, grande) e clica no botão enviar.
2.O sistema exibe a página de carros disponíveis e o valor de locação para o modelo selecionado. O cliente faz sua escolha e clica no botão continuar.
3.O sistema exibe a página com as opções de proteção (básico, completo e premium). O cliente visualiza o detalhamento de cada opção, seleciona sua preferência e clica no botão continuar.
4.O sistema exibe a página de identificação do cliente. O cliente se identifica com nome, cpf, e-mail e telefone.
5.O sistema exibe a página de confirmação da reserva, com todos os dados da reserva e solicita confirmação do cliente.O cliente confirma a reserva
6. O sistema finaliza a reserva exibindo uma página com os dados da mesma que podem ser impressa pelo cliente. O sistema envia um e-mail para o cliente com os dados da mesma
|
No desenvolvimento de software das grandes empresas as fábricas de software vem desempenhando cada vez mais um papel central. O modelo que se busca e o de delegar a programação para a fábrica e manter o foco das áreas de desenvolvimento na análise do negócio, na especificação do que será construído nos testes e implantação.
Para que um programador possa implementar um código ele necessita de uma boa solicitação, e como ela deve ser ?
Seria apenas um formulário de requisição para a fábrica onde as informações contidas nele não formam uma documentação do software, ou a requisição deve ser a própria documentação de requisito análise e projeto do sistema?
Haverá sempre a tentação de se preencher um formulário rápido e enviá-lo para a fábrica de software, pois elaborar uma documentação adequada de requisitos, análise e projeto dão um bocado de trabalho. Entretanto penso que o melhor seria elaborar uma documentação completa de requisitos e análise e projeto e essa mesma documentação passa a servir a dois propósitos: documentação do software e para envio à fábrica de software
Essa documentação deve certamente conter uma página que oriente claramente o programador sobre o que deverá ser feito para que ele não precise ler todos os documentos de requisitos análise e projeto do início ao fim. Essa página serviria como um índice rápido para que o programador pudesse localizar o tipo de informação que ele necessita na documentação existente.
Penso que esse tipo de abordagem além de atender a dois propósitos contribui ainda para a produção de um código de melhor qualidade. O você, o que pensa sobre esse assunto?
