TCC – Casos de Uso

Para este post, estarei falando um pouco sobre Diagrama de Casos de Uso, tendo como exemplo um caso de uso criado para representar uma das funcionalidade do meu projeto do TCC.

O diagrama de casos de uso tem como finalidade facilitar a comunicação entre o analista e o cliente podendo ser usado para descrever o cenário em que a aplicação irá funcionar e suas funcionalidades.

Um diagrama de casos de usos é composto por componentes de notação como: Ator e Caso de Uso e entre estes componentes pode existir relacionamentos como: Associação, generalização, comunicação, includes e extends, que explicarei depois como e quando utilizá-los.

Bom, no segundo post sobre meu TCC eu utilizei um formulário de Modelo de Requisitos (Caso não tenha visto o formulário, está aqui), como foi dito, apesar de não ter visto utilidade naquele momento e ter passado varias aulas arrumando desculpas para não fazer, acabei fazendo. Pois bem aqui é que encontrei a utilidade dele.

Para este post estarei utilizando um modelo que fiz pro meu estágio. Nele uma das funcionalidades é Gerenciar Vendas,  ficando representada no modelo da seguinte funcionalidade:

Usuário

Funcionalidade Regra de Negócio Pré-Requisito Ações Pós-Requisito
Supervisor de vendas ou funcionários autorizados. Gerenciar Vendas Setor de vendas é responsável por liberação de ordem de produção Obter relação de pedidos aguardando aprovação Confirmar o pedido junto ao cliente caso for necessário

Emitir Ordem de produção

Lançar Contas a Receber

Analisando a tabela observamos o seguinte:

Somente o Supervisor de Vendas e Funcionários autorizados possuem acesso a funcionalidade.

O setor de venda é responsável por liberar às ordens de produção da empresa, para isso é necessário que tenha sido efetuado um pedido e que este não tenha sido aprovado até o momento.

Se necessário este pedido precisa ser confirmado junto ao cliente.

Após isso é emitida a ordem de produção e  efetuado o lançamento da venda no contas a receber.

A confirmação destas contas a receber é feita em outra funcionalidade do sistema, deixei somente  estes requisitos para não estender o post.

Agora vamos passar isso pro caso de uso.

Primeiro passo e saber quando usar cada componente:

Ator: Representa um usuário do sistema, podendo este ser um ser humano ou um outro sistema.

Entre atores pode ocorrer dois tipos de relacionamentos:

Comunicação: Representação em que ocorre a troca de mensagens entre atores.

Generalização: Representação em que um ator herda as características de outro ator. O mesmo conceito de Herança em Orientação a Objetos.

Caso de uso: Seu objetivo é especificar funcionalidades do sistema.

Entre casos de uso podemos encontrar os  relacionamentos de extend, include e generalização.

Include: Ao utilizar o relacionamento de include, dizemos que uma funcionalidade está incluída em outra funcionalidade. Para que seja executada, obrigatoriamente é necessário passar pela funcionalidade em que ela está incluída.

No exemplo estamos dizendo repesentamos que o acesso ao sistema somente pode acontecer caso o login tenha sido executado.

Extend: O relacionamento de extend representa uma exceção, ou seja, representa um comportamento que pode ocorrer separadamente do caso de uso que o estende.

No exemplo estamos dizendo que para efetuar a compra podemos consultar o preço, porém também podemos consultar o preço sem a necessidade de efetuarmos uma compra, por isso utilizamos o extend para representar este relacionamento.

Generalização: O relacionamento de generalização é usado para representar uma herança de um caso de uso genérico para um mais específico.

No exemplo dizemos que podemos Cartão de Crédito e Duplicata herdam o caso de uso Efetuar pagamento, ou seja, que cartão de crédito e duplica também são formas de efetuar pagamento.

Uma observação em que devemos estar sempre atentos é o nível de abstração. Alguns casos um caso de uso não necessariamente precisam aparecer, pois ficam implícitos dentro de outro caso de uso. O interessante é deixar à mostra somente casos de uso que representam funções que realmente interessem ao programador e ao cliente, caso uma funcionalidade interesse somente a um dos dois, não necessariamente precisa ser criado um caso de uso para  representá-la.

 Agora que já sabemos quando e quanto utilizar os casos de uso, voltaremos à tabela.

Temos nossos atores já definidos, que são Supervisor e Funcionário autorizado. Como temos dois tipos de usuário e cada um tem um nível de acesso diferente do outro, faremos uma generalização para representar isso, ficando da seguinte forma.

No exemplo temos,  Supervisor herda as funções do Funcionário podendo ter mais funções especificas. Por exemplo, somente o supervisor pode ter acesso a relatórios, desta forma criariamos um caso de uso pra relatório e fariamos um relacionamento diretamente com Supervisor, mais neste caso de uso não será usada esta representação.

Dando sequência, temos o nosso pré-requisito da funcionalidade que é obter a relação de pedidos não aprovados.

Criamos uma funcinalidade Consultar Pedido, e relacionamos ela a Funcionário, desta forma tanto Funcionário quanto Supervisor terão acesso a ela.

No caso de uso ficaria representado dessa forma.

 

Agora temos mais dois pós-requisitos na tabela que são: Emitir Ordem e Lançar Contas a Receber. Porém temos uma ação que é Confirmar o Pedido se Necessário.

Primeiro vamos para a ação. Como a ação já diz que só vai ocorrer necessário, entendemos que ela é um extend.


Já com o emitir ordem de produção observamos o que é um comportamento que poderá ocorrer independente de consultar o pedido.

Por exemplo, caso o usuário queira emitir a ordem de produção sem consultar, ele poderá fazer, portanto entendemos como outro extend.

Porém o lançar contas a pagar, só poderá ocorrer se realmente forem emitidas ordens de produção. Neste caso um include relacionado com ordem de produção.

Este Caso de uso está em um nível de abstração que pode ser facilmente compreendido, logicamente poderíamos abstrair ainda mais, porém ficaria complicado para explicar ao cliente suas funcionalidades.

Uma frase que um amigo chamado Igor me falou uma vez e que acho bastante válida, é que não existe caso de uso mal feito e sim caso de uso mal compreendido.

Portanto, não poupe esforços para deixar seu caso de uso com as funcionalidades bem definidas e claras, isso influência muito no produto final, e lembre-se também que em algum momento será necessario dar manutenção neste sistema e com certeza depois de um tempo você não irá se lembrar como foi implantada tal funcionalidade.

Como visto, à tabela de modelo de requisitos é bastante útil para a criação dos casos de uso, uma vez que as informações estarão descritas ali, basta passarmos para o diagrama.

Terminado nosso Diagrama de caso de uso da funcionalidade Gerenciar Venda e termino este post por aqui também.

Até o próximo.

TCC – Ferramentas e Frameworks

Neste post estarei falando um pouco sobre as ferramentas e frameworks escolhidos para o desenvolvimento deste trabalho.

A princípio, na segunda etapa deste trabalho foi feito o levantamento de requisitos. Nesta etapa diversos requisitos não funcionais foram analisados, entre estes requisitos estão quais ferramentas deveriam ser utilizadas para o desenvolvimento deste software.

Por se tratar de um software para desktop em que uma pequena parte será desenvolvida para web, diversos nomes de ferramentas foram listados, sendo elas: IDEs, banco de dados, frameworks, ferramentas de modelagem entre outros.

De inicio, diversas delas chamam atenção de todo desenvolvedor por apresentar uma inteface bonita, parecer de fácil implementação ou até mesmo por que alguém falou muito bem de tal ferramenta. Como todo mundo sabe, nem tudo é o que parece ser, algumas vezes escolher uma ferramenta sem conhece-la pode se torna um problema e por isso existe o estudo de viabilidade.

No estudo de viabilidade estas ferramentas listadas precisam ser bem estudas, pois pode-se comprometer todo um projeto simplesmente por ter feito a escolha da ferramenta errada. Outro requisito que deve ser levado em consideração é a escolha de ferramentas que necessitam a aquisição de licenças para uso.

Atualmente no mercado podemos encontrar diversas ferramentas gratuitas, com um poder igual ou até mesmo superior ao de ferramentas pagas, oferecendo mais agilidade se aplicadas de maneira correta e na área certa. Com esta afirmação não estou defendendo que todos os projetos devam utilizar ferramentas gratuitas. Cada projeto possui suas características e em alguns casos é inevitável que seja necessária aquisição ferramentas especificas. A ideia é escolher a melhor ferramenta sendo ela paga ou gratuita, levando-se em consideração a complexidade do software que se esta desenvolvendo. Caso seja necessária uma ferramenta paga, de alguma forma alguém terá que pagar pela licença, portanto cuidado com este requisito, pois é necessário que se tenha uma atenção especial, se esta parte passa sem analise pode-se encarecer o projeto e o tornar inviável financeiramente.

Bom, se você nunca pensou em nada disso antes de um projeto espero ter levantado uma duvida. Neste caso, como escolher a melhor ferramenta?

Muitos requisitos devem ser levados em consideração, dentre eles, verifique se esta ferramenta possui fóruns ativos na internet, uma vez que em todo projeto chega-se a um momento em que se encontra um problema para a implementação de algum método, e é nestes fóruns que se vai encontrar a ajuda necessária para se solucionar tal problema. Verifique a quantidade de profissionais que utilizam a ferramenta e analise qual a opinião deles sobre tal ferramenta, e o principal, a que área aplicar e como aplicar o uso tal ferramenta no projeto. Pode-se perdem tempo analisando estas informações? Sim, porém é um tempo necessário, para que seu projeto seja bem executado e não tire suas horas de sono.

Para o meu projeto foram escolhidas algumas ferramentas que achei interessantes. Confesso que algumas delas ainda estou aprendendo como é seu funcionamento, e escolhi por motivos próprios por não se tratar de uma aplicação o comercial e sim de um trabalho de conclusão de curso. Neste caso testar algumas ferramentas e frameworks novos se torna interessante, uma vez que entre estas que escolhi,  existem algumas que estão em alta no mercado, e um profissional que esta se formando agora como eu, precisa de um conhecimento amplo para se preparar para o mercado de trabalho. Vou da uma breve descrição de algumas ferramentas que estarei utilizando neste projeto.

Ferramentas aplicadas neste projeto nas áreas Desktop e Web.

Apache Maven: Apache Maven ou simplesmente Maven esta atualmente na sua versão 3,  é uma ferramenta de automação de projetos em Java. Desenvolvido em cima da ferramenta Ant, o Maven se tornou uma ferramenta bastante utilizada por sua configuração serem mais simples, uma vez que sua configuração é baseada em XML. Por se tratar de uma ferramenta de automação de projeto, ele é quem descreve todo o processo de construção de um software. O Maven gerencia as dependências de um projeto, seus módulos e componentes e sequencia de construção através de uma estrutura conhecida como POM (Project Object Model).  Uma característica marcante do Maven é a possibilidade de trabalhar em rede onde seu núcleo pode baixar as dependências diretamente de um repositório.

Mais informações:  http://maven.apache.org/

Subverison: O Subversion é uma ferramenta de controle de versão, ou seja, ele gerencia arquivos e diretórios salvando todas as modificações feitas no projeto com o tempo. Com isso pode se recuperar versões mais antigas do projeto ou examinar o histórico de alterações. O Subversion pode funcionar em rede, com isso permite-se que varias pessoas trabalhem no mesmo projeto estando em computadores diferentes. Em grandes projetos ganha se em produtividade, pois e sempre que um profissional envolvido termine determinada tarefa, pode submetê-la e outro profissional que ao atualizar seu projeto estará com a versão atualiza em sua maquina.

Mais informações:  http://svnbook-pt-br.googlecode.com/svn/snapshots/1.4/svn.intro.whatis.html

Hibernate: O Hibernate é um framework para mapeamento objeto-relacional que tem como objetivo diminuir a complexidade entre programas Java que utilizam o modelo de programação orientada a objetos e banco de dados modelo objeto relacional.  Sua principal característica e transformar classes em Java em tabelas de banco de dados, além de gerar todo o SQL da aplicação liberando o programador desta tarefa.

Mais Informações: http://www.hibernate.org/

Ferramentas para Web:

Spring: Spring é um framework que trabalha com Inversão de Controle e Injeção de Dependência. Possui sua arquitetura baseada em POJOS (Plain Old Java Object) e oferece a eles a eles a possibilidade de alcançar coisas que somente eram possíveis com EJBs.  No Spring o container se encarrega de instanciar as classes e definir quais são suas dependências através de um arquivo de configuração no formato XML permitindo o baixo acoplamento entre classes.

Spring Security: O Spring Security trabalha com segurança baseada em roles. Com isso não é necessário chamar nenhum método para realizar autenticação ou autorização de acesso a usuários em um sistema. Com os roles definidos informamos a aplicação quais recursos podem ser acessados por um usuário que acessou uma área restrita.

Mais informações:  http://www.springsource.org/

JSF: Sobre o Java Server Faces (JSF) não falarei aqui para que o post não fique muito extenso. Fiz um post sobre JSF há algum tempo, então segue o link  Fernando Godoy – JSF.

PrimeFaces: O Primefaces é uma biblioteca de componentes de código aberto para JSF e citada por muitos como uma das melhores bibliotecas do mercado, possuindo cerca de 100 componentes.

Mais informações: http://www.primefaces.org/

Estas são as ferramenta mais interessantes e que estarei utilizando, dentre outras tenho o Astah, Ireport, DbDesigner, DbWrenchapp, PostGreSQL que será meu banco de dados e o NetBeans que será minha IDE.

Estas são algumas das ferramentas e frameworks escolhidas, postei junto com cada descrição o link que contem mais informações caso interesse a mais alguém. Não me aprofundei muito nas explicações para o post não ficar muito extenso, mais sem duvida vale a pena estudar cada uma delas.

Em breve estarei postando códigos e tutorias de configuração de cada uma das ferramentas listadas acima.

Espero que gostem e até o próximo.

3ª Etapa TCC – Estudo de Viabilidade

      Após obtermos o conhecimento sobre a regra de negocio da empresa e termos todos os requisitos funcionais e não funcionais do sistema, passamos para o estudo de viabilidade.

     Algumas pessoas acabam não levando a sério esta parte do projeto pulando esta etapa. Ao se pular esta etapa, assumindo se um risco, pois é nela que iremos identificar se o sistema proposto é viável ou não para a empresa. Para isto o estudo de viabilidade é divido em 3 partes que são: Viabilidade técnica, econômica e legal.

     Viabilidade técnica: Esse estudo visa avaliar a função, desempenho e limitações que um software terá dentro de uma empresa, com isso é possível identificar se o sistema proposto atenderá ou não as necessidades do cliente. A viabilidade técnica é citada por muitos como a mais difícil a se fazer, uma vez que a função do sistema pode acabar ficando um pouco vaga quando o cliente não sabe exatamente o que quer, com isso desempenho e limitações são feitos por meio de previsões, o que em alguns casos pode-se comprometer módulos do sistema ou até mesmo o sistema inteiro, não se obtendo o resultado esperado ao final. Em alguns casos por não se conseguir identificar exatamente o que o cliente deseja, acaba-se optando pelo modelo de ciclo de vida espiral e combinando ele com o modelo de prototipação, caindo em um loop infinito e tornando assim o projeto um fracasso uma vez que nunca se consegue chegar a um produto final.

     Viabilidade Econômica: Este estudo já tem como objetivo o levantamento de custos e impactos econômicos que o software terá dentro da empresa. Por exemplo, se a equipe de desenvolvimento possui o conhecimento necessário da linguagem de programação, se será necessária aquisição de alguma licença especial tanto para o desenvolvimento ou para a implantação do sistema dentro da empresa, custos com hardware, pessoal capacitado, ou seja, nesta etapa tende-se a avaliar todo e qualquer custo que ocorrerá tanto no desenvolvimento quanto na implantação do sistema, levando-se em consideração sempre o custo benefício. O objetivo final desta etapa e provar ao cliente que o investimento que ele esta fazendo terá lucro ou benefícios para a empresa, uma vez que se isto não for comprovando o projeto pode morrer nesta etapa mesmo.

     Viabilidade Legal: Para este estudo o objetivo passa a ser identificar aspectos legais do sistema. Para isto deve-se estar atento a leis federais, estaduais e municipais para que nenhuma delas seja infringida. Lembrando que caso a empresa que utilize um sistema e passe por uma fiscalização e nesta seja encontrada algum tipo de irregularidade com o sistema, como por exemplo, você foi contratado para desenvolver um sistema para um mercado, e quando você estava fazendo o levantamento de requisitos o cliente diz que precisaria de um controle “a parte” para entradas e saídas, e que este controle seja feito fora do controle fiscal, nesta hora, muitas vezes para alimentar seu ego e provar que se pode fazer tudo ou até mesmo por impulso, acaba-se dizendo que não terá problemas para se implementar e que não será nada difícil, e este controle “a parte” acaba sendo implementado. No caso desta empresa sofrer uma fiscalização e que seja detectado este controle “a parte” quem fez o sistema acaba respondendo como cumplice por sonegação de impostos e pode enriquecer seu curriculum com alguns anos de cadeia.

     Para que o sistema se torne viável ele deve ser submetido a estes 3 estudos e deve obrigatoriamente receber um aval favorável de todos. Uma vez que se o sistema não for viável financeiramente para a empresa, significa que a empresa não poderá pagar por ele. Se não for viável tecnicamente significa que o sistema não atenderá o cliente da forma que ele necessita e não terá o desempenho esperado. Se não for viável legalmente problemas com multas ou até mesmo prisões tendem a aparecer, gerando muitas reclamações por parte do cliente. Resumindo tudo, se o sistema não é viável para o cliente, com certeza não será viável para a equipe de desenvolvimento uma vez que será tempo gasto com um projeto que estava condenado ao fracasso desde seu inicio.

     Concluindo, vejo o estudo de viabilidade um ponto de extrema importância para um projeto. Uma vez que ele influência muito no produto final. E se você é um desenvolvedor sério que visa vender seus softwares, ganhar mercado, garantir a qualidade de seu produto e satisfação de seus clientes, vale muito a pena dar uma atenção especial a este item.

TCC 2º Etapa – Levantamento de requisitos.

Para esta etapa estarei falando um pouco sobre levantamento de requisitos.

Após termos passado a primeira etapa do projeto que foi conhecer a regra de negócios bem a fundo entramos nesta segunda etapa, assim como a primeira esta também é de extrema importância, porém esta tem um peso muito grande sobre o software.

2º Etapa – Levantamento de requisitos.

Se na faze de conhecimento da regra de negócio sonhamos com o sistema é nesta que começamos a construir aquilo com o que sonhamos, então muita calma para esta etapa, pois uma analise de requisitos mal feita trará problemas futuros, falhas, atraso na entrega entre muitas outras coisas que comprometem o projeto e com isso temos como consequência um sistema sem qualidade nenhuma e um cliente insatisfeito.

Requisitos estão resumidos em dois tipos que são funcionais e não funcionais. De certa forma eles são:

Requisitos funcionais: São requisitos que influenciam diretamente no software. Estes requisitos tem uma característica importante, pois são eles que agregam valor ao software ou facilitam a vida do usuário. Tendo meu trabalho como exemplo, na primeira fase propus para a empresa a criação de um pagina web para que seus clientes pudessem fazer seus pedidos. Por característica isso é um requisito funcional do software que estou desenvolvendo. Para deixar ainda mais clara à ideia, a empresa poderia ainda me pedir um relatório específico que comparasse as vendas entre os seus representantes comerciais, telefones e web. Isso seria mais um requisito funcional do meu sistema.

Requisitos não funcionais: Os requisitos funcionais são aqueles requisitos que geralmente estão mais ligados ao uso da aplicação, geralmente são estes requisitos que dão acesso aos requisitos funcionais. Dando continuidade ao exemplo do meu sistema, dei o exemplo de requisito funcional que é a pagina Web para os pedidos, agora um requisito não funcional para isto seria, para ter acesso a estes pedidos o cliente precisa estar cadastrado na empresa e possuir um login e senha.

Gosto bastante da ideia de dizer que, requisitos funcionais são aqueles que interessam ao cliente e não funcionais interessam ao programador. Porém não é uma maneira correta de se explicar isto. A maneira que julgo ser correta é que requisito funcional é o que precisa ter no nosso sistema e não funcional que é como nosso sistema vai funcionar.

Uma forma que acho legal de trabalhar nesta esta etapa é criando questionários intuitivos, como por exemplo, se pra cada funcionalidade do sistema você se fizer estas 3 perguntas simples.

  • Como se chamará funcionalidade? Exemplo de resposta: Cadastro de cliente
  • Quais dados preciso para criar este cadastro? Exemplo de resposta: Nome, documentos pessoais, endereço completo, etc.
  • Onde irei armazenar estes dados? Exemplo de resposta: Banco de dados, Arquivo de texto, etc.

Com este exemplo básico já teremos um grande número de informações que nos ajudaram a definir o que iremos fazer, o que precisamos para fazer e teremos até uma ideia de como fazer.

Logicamente que somente com estas perguntinhas básicas não se resolve o levantamento de requisitos, para isto o questionário seria um pouco maior e mais complexo, usei isto somente para exemplificar minha ideia e por que eu acho bastante interessante esta forma de trabalhar e se alguém achar interessante esta abordagem pode criar o seu próprio questionário.

Uma experiência legal que tive também foi no meu segundo ano dentro da universidade onde uma professora, Drª Daniela Eloise Flor apresentou o formulário que auxilia neste processo, particularmente no inicio eu não gostei da ideia e fiquei varias aulas tentado arrumar um motivo pra não fazer, mais após ter feito fui perceber que com este formulário fica fácil a compreensão do sistema de forma geral. Disponibilizei um exemplo que ela mesmo me envio, vale a pena conferir, a ideia é simples e genial pra cada funcionalidade do sistema você anota todas regras de negócio que regem aquela funcionalidade, os pré-requisitos para que esta funcionalidade seja executada, as ações que serão executadas e os pós requisitos que será o resultado de cada ação.

Como prometi deixar algo que acho interessante de exemplo estou disponibilizando o projeto arquitetural do sistema.

Aqui esta o link para o download dos arquivos de exemplo para modelo de requisitos que a prof. me enviou:

Modelo de Requisitos