TiEspec - Sistema de Apoio a Construção de Especificações de Caso de Uso de Software

UNIVERSIDADE VILA VELHA

TiEspec – Sistema de Apoio a Construção de Especificações de Caso de Uso de Software

Hermann Miertschink Neto Orientador Prof. Msc. Cristiano Biancardi

VILA VELHA, ES 2012

  HERMANN MIERTSCHINK NETO

TiEspec – Sistema de Apoio a Construção de Especificações de Caso de Uso de Software Trabalho de conclusão de curso apresentado a Universidade Vila Velha, como parte dos requisitos para

a

obtenção

Bacharel

em

do

grau

Sistemas

Informação. Orientador Prof. Msc. Cristiano Biancardi

VILA VELHA, ES 2012  

de de

 

AGRADECIMENTOS   Agradeço primeiramente a Deus, por me permitir a oportunidade e a força para cursar estes quarto anos de graduação. Em segundo lugar, agradeço a minha família, por ter me dado aconselhamento durante este período, me apoiando sempre que precisei, e me ajudando a superar todas as dificuldades encontradas. Agradeço aos mestres, que dia após dia, me ensinavam um pouco mais sobre o gigantesco mundo da computação, em especial a profa. Msc. Susiléa de Abreu Dos Santos, pela oportunidade dada a mim durante a graduação, e a meu coordenador, prof. Msc. Cristiano Biancardi, pelo direcionamento e paciência durante a elaboração deste artefato. Sou grato também pelas amizades que tive a oportunidade de cultivar durante este período, que com certeza irão durar por longos anos.

 

 

“Procure ser um homem de valor, em vez de ser um homem de sucesso.” Albert Einstein

 

 

RESUMO   O ambiente computacional vêm crescendo em uma velocidade cada vez maior nos últimos anos, principalmente no que se diz respeito a velocidade de processamento de dados e ao barateamento de tecnologias. Para acompanhar esta velocidade de crescimento, os processos envolvidos na criação de softwares precisam ser melhorados, seja com inovações, otimizações de processos ou por meio de ferramentas computacionais especializadas. O TiEspec, sistema desenvolvido, se propõe a ser uma ferramenta que auxilie os analistas de sistemas a construírem descrições de caso de uso de software, e que permita a reutilização de cenários de caso de uso. Tudo isso de forma confiável, rápida, por meio de uma interface web. Para alcançar tais objetivos, foi utilizada a Análise e Projeto de Sistemas Orientados a Objetos, conceitos de UML, a linguagem de programação Java, o servidor de aplicação GlassFish e o banco de dados PostgreSQL. Ao término do projeto, foi possível criar a ferramenta com sucesso, provendo funcionalidades de manutenção de cenários de caso de uso, e permitindo o reuso destas na construção de caso de uso de software. Foi possível perceber que a automatização da criação e manutenção de descrições de caso de uso de software pode ser aplicada para melhorar o processo de desenvolvimento de software.

Palavras-Chave: Análise de Sistemas, Especificação de Sistemas, Elicitação de Casos de Uso, UML, Java, Arquitetura Java EE 6, PostgreSQL.    

 

 

LISTA DE TABELAS Tabela  1  –  Problemas,  Causas  e  Possíveis  Soluções  ..........................................................  22   Tabela  2  –  Fontes  de  Informação  e  Técnicas  Utilizadas  ..................................................  24   Tabela  3  –  Descrição  Sucinta  de  Casos  de  Uso  do  Sistema  .............................................  27   Tabela  4  –  Dicionário  de  Dados  –  Entidade  ..........................................................................  45   Tabela  5  –  Dicionário  de  Dados  –  Anexo  ................................................................................  46   Tabela  6  –  Dicionário  de  Dados  –  Artefato  ............................................................................  46   Tabela  7  –  Dicionário  de  Dados  –  Atores  ...............................................................................  46   Tabela  8  –  Dicionário  de  Dados  –  Cenário  .............................................................................  46   Tabela  9  –  Dicionário  de  Dados  -­‐  Cliente  de  Portal  ...........................................................  47   Tabela  10  –  Dicionário  de  Dados  –  Cliente  de  Projeto  .....................................................  47   Tabela  11  –  Dicionário  de  Dados  –  Configuração  de  Descrição  Estendida  .............  48   Tabela  12  –  Dicionário  de  Dados  –  Contatos  ........................................................................  48   Tabela  13  –  Dicionário  de  Dados  –  Dados  .............................................................................  49   Tabela  14  –  Dicionário  de  Dados  –  Descrição  Estendida  ................................................  49   Tabela  15  –  Dicionário  de  Dados  –  Documento  ..................................................................  50   Tabela  16  –  Dicionário  de  Dados  –  Fluxo  ...............................................................................  50   Tabela  17  –  Dicionário  de  Dados  –  Fluxo  Base  ....................................................................  50   Tabela  18  –  Dicionário  de  Dados  –  Perfil  ...............................................................................  50   Tabela  19  –  Dicionário  de  Dados  –  Projeto  ...........................................................................  51   Tabela  20  –  Dicionário  de  Dados  –  Usuário  ..........................................................................  51   Tabela  21  –  PF  –  Contagem  de  Tipos  de  Dados  ...................................................................  56   Tabela  22  –  PF  –  Contagem  de  Tipo  Transação  ..................................................................  57   Tabela  23  –  PF  –  Fator  de  Ajuste  ...............................................................................................  59   Tabela  24  –  Tabela  de  Produtividade  de  Profissionais  de  TI  ........................................  60   Tabela  25  –  Tempos  e  Custo  de  Desenvolvimento  ............................................................  61   Tabela  26  –  Disponibilização  de  Planos  do  Portal  .............................................................  62   Tabela  27  –  Simulação  de  Faturamento  do  Portal  .............................................................  62   Tabela  28  –  Descrição  do  Equipamento  da  Primeira  Proposta  Tecnológica   (DELL,2012)  .............................................................................................................................  63   Tabela  29  –  Descrição  do  Serviço  da  Segunda  Proposta  Tecnológica  (UNDER,   2012)  ...........................................................................................................................................  64   Tabela  30  –  Lista  de  tecnologias  Java  EE  6  (JAVA  MAGAZINE,  2012)  .......................  68   Tabela  31  –  Dicionário  de  Dados  –  Tabela  de  Relacionamento  Ator  x  Descrição   Estendida  ...................................................................................................................................  90   Tabela  32  –  Ícones  Utilizados  .....................................................................................................  93   Tabela  33  –  Componentes  do  JSF  e  do  PrimeFaces  Utilizados  .....................................  95   Tabela  34  –  Template  utilizado  na  Fábrica  de  Software  do  Grupo  Europa   Empreendimentos  e  Negócios  ........................................................................................  189   Tabela  35  –  Modelo  De  Descrição  utilizado  para  descrever  o  sistema  TiEspec  .  190  

 

 

LISTA DE FIGURAS Figura  1  –  Independência  entre  formato,  grau  de  abstração  e  detalhamento  de   um  caso  de  uso  (BEZERRA,  2007)  ..................................................................................  18   Figura  2  –  Diagrama  de  Pacotes  .................................................................................................  25   Figura  3  –  Diagrama  de  Casos  de  Uso  ......................................................................................  26   Figura  4  –  Diagrama  de  Classes  .................................................................................................  32   Figura  5  –  DS  –  Aprovação  de  Clientes  do  Portal  ...............................................................  34   Figura  6  –  DS  –  Aprovação  de  Clientes  do  Portal  ...............................................................  34   Figura  7  –  DS  –Aprovação  de  Usuários  ...................................................................................  35   Figura  8  –  DS  –  Atualizar  Ator  ....................................................................................................  35   Figura  9  –  DS  –  Cadastrar  Ato  .....................................................................................................  35   Figura  10  –  DS  –  Excluir  Ator  ......................................................................................................  35   Figura  11  –  DS  –  Listar  Atores  ....................................................................................................  36   Figura  12  –  DS  –Cadastrar  Descrição  Estendida  ................................................................  36   Figura  13  –  DS  –  Cadastrar  Projeto  ..........................................................................................  36   Figura  14  –  DS  –  Alterar  Projeto  ................................................................................................  37   Figura  15  –  DS  –  Excluir  Projeto  ................................................................................................  37   Figura  16  –  DS  –  Visualizar  Projeto  ..........................................................................................  37   Figura  17  –  DS  –  Configurar  Descrições  Estendidas  .........................................................  38   Figura  18  –  DS  –  Criar  Artefato  ..................................................................................................  38   Figura  19  –  DS  –  Alterar  Artefato  ..............................................................................................  38   Figura  20  –  DS  –  Excluir  Artefato  ..............................................................................................  39   Figura  21  –  DS  –  Imprimir  Descrição  Estendida  .................................................................  39   Figura  22  –  DS  –  Listar  Usuários  (Administrador)  ............................................................  40   Figura  23  –  DS  –  Solicitar  Cadastro  No  Portal  (Cliente  Existente)  ..............................  40   Figura  24  –  DS  –  Solicitar  Cadastro  no  Portal  (Cliente  Não  Existente)  .....................  41   Figura  25  –  DS  –  Visualizar  Cliente  de  Portal  .......................................................................  41   Figura  26  –  DTE  –  Cliente  de  Portal  .........................................................................................  42   Figura  27  –  DTE  –  Cliente  de  Projeto  .......................................................................................  43   Figura  28  –  DTE  –  Perfil  ................................................................................................................  43   Figura  29  –  DTE  -­‐  Projetos  ...........................................................................................................  44   Figura  30  –  DTE  –  Usuários  .........................................................................................................  45   Figura  31  –  Tabelas  de  Complexidade  Funcional  e  Contribuição  (VAZQUEZ,   SIMÕES,  ALBERT,  2010)  .....................................................................................................  56   Figura  32  –  Cálculo  de  Pontos  de  Função  ..............................................................................  60   Figura  33  –  Diagrama  de  Pacotes  Revisado  ..........................................................................  78   Figura  34  –  Divisão  de  Camadas  ................................................................................................  79   Figura  35  –  Divisão  de  Camadas  e  o  Relacionamento  com  Pacotes  de   Programação  ............................................................................................................................  80   Figura  36  –  Domínio  do  Problema  –  Modelo  –  Parte  I  .....................................................  82   Figura  37  –  Domínio  do  Problema  –  Modelo  –  Parte  II  ....................................................  83   Figura  38  –  Domínio  do  Problema  –  EJB  ................................................................................  84   Figura  39  –  Gerência  de  Tarefas  –  Managed  Bean  .............................................................  85   Figura  40  –  Gerência  de  Dados  –  Camada  DAO  –  Parte  I  ................................................  87   Figura  41  –  Gerência  de  Dados  –  Camada  DAO  –  Parte  II  ...............................................  88   Figura  42  –  Diagrama  Relacional  ..............................................................................................  89   Figura  43  –  Grid  960  (24)  .............................................................................................................  91    

  Figura  44  –  Grid  486  (18)  .............................................................................................................  92   Figura  45  –  Grid  432  (16)  .............................................................................................................  92   Figura  46  –  Classe  CSS  Width  ......................................................................................................  92   Figura  47  –  Classe  CSS  Dialog_Width  .......................................................................................  93   Figura  48  –  Exemplo  de  Mensagens  ao  Usuário  .................................................................  94   Figura  49  –  Exemplo  de  Botões  ..................................................................................................  95   Figura  50  –  Tela  de  Visualização  de  Atores  Cadastrados  ...............................................  97   Figura  51  –  Diálogo  de  Criação  de  Atores  ..............................................................................  97   Figura  52  –  Diálogo  de  Busca  de  Atores  .................................................................................  98   Figura  53  –  Tela  de  Visualização  de  Descrição  Estendida  –  Aba  Dados  Básicos  ..  98   Figura  54  –  Tela  de  Visualização  de  Descrição  Estendida  –  Aba  Tipos  de  Dados  99   Figura  55  –  Diálogo  de  Busca  de  Clientes  de  Portal  ..........................................................  99   Figura  56  –  DS  Revisado  –  Cadastrar  Ator  ..........................................................................  100   Figura  57  –  DS  Revisado  –  Atualizar  Ator  ............................................................................  100   Figura  58  –  DS  Revisado  –  Listar  Atores  ..............................................................................  100   Figura  59  –  DS  Revisado  –  Excluir  Ator  ................................................................................  100   Figura  60  –  DS  Revisado  –  Buscar  Projeto  Pré-­‐Impressão  ...........................................  101   Figura  61  –  DS  Revisado  –  Imprimir  Descrição  Estendida  ...........................................  101   Figura  62  –  DS  Revisado  –  Cadastrar  Dado  .........................................................................  101   Figura  63  –  Organização  dos  Módulos  de  Empacotamento  na  Visão  de   Codificação  ..............................................................................................................................  102   Figura  64  –  Diagrama  de  Implantação  ..................................................................................  103   Figura  65  –  Diagrama  de  Implantação  com  UML  .............................................................  103  

 

 

LISTA DE SIGLAS DE – Descrição Estendida DAO – Data Access Object DP – Domínio do Problema GD – Gerência de Dados GT – Gerência de Tarefas IU – Interface com Usuário SHA-1 – Secure Hash Algorithm MVC – Model, View and Controller UML – Unified Modeling Language XML – eXtensible Markup Language TI – Tecnologia da Informação IT – Information Technology PDS – Processo de Desenvolvimento de Software APF – Análise de Pontos de Função ALI – Arquivo Lógico Interno AIE – Arquivo de Interface Externa EE – Entrada Externa SE – Saída Externa CE – Consulta Externa TR – Tipos de Registros TD – Tipos de Dados AR – Arquivos Referenciados EJB - Enterprise Java Beans Java EE – Java Enterprise Edition JSF – Java Server Faces POJO – Plain And Old Java Object FSW-UVV – Fábrica de Software da Universidade de Vila Velha FSW-GEEN – Fábrica de Software do Grupo Europa Empreendimentos e Negócios RUP – Rational Unified Process

 

 

SUMÁRIO 1   Introdução  ..................................................................................................................  11   1.1   Motivação  e  Justificativa  ............................................................................................  12   1.2   Objetivos  ..........................................................................................................................  13   1.3   Metodologia  ....................................................................................................................  13   1.4   Descrição  dos  Capítulos  .............................................................................................  13   2   Conceitos  ....................................................................................................................  15   2.1   Análise  de  Requisitos  ..................................................................................................  15   2.2   Analista  de  sistemas  ....................................................................................................  15   2.3   Modelagem  de  Caso  de  Uso  .......................................................................................  16   2.3.1   Diagrama  de  Casos  de  Uso  ................................................................................................  16   2.3.2   Atores  .........................................................................................................................................  16   2.3.3   Descrição  de  Casos  de  Uso  ................................................................................................  17   3   Levantamento  e  especificação  de  Requisitos  .................................................  21   3.1   Descrição  do  Mini  Mundo  ..........................................................................................  21   3.2   Problemas,  Causas  e  Possíveis  Soluções  ...............................................................  22   3.3   Fontes  de  Informação  e  Técnicas  Utilizadas  .......................................................  24   3.4   Diagrama  de  Pacotes  ...................................................................................................  24   3.5   Modelagem  de  Caso  de  Uso  .......................................................................................  26   3.5.1   Diagrama  de  Casos  de  Uso  ................................................................................................  26   3.5.2   Descrição  de  Atores  .............................................................................................................  27   3.5.3   Descrição  de  Caso  de  Uso  ..................................................................................................  27   4   Especificação  de  Análise  ........................................................................................  30   4.1   Diagrama  de  Classes  ....................................................................................................  30   4.2   Diagramas  de  Sequência  ............................................................................................  33   4.3   Diagrama  de  Transição  de  Estados  ........................................................................  41   4.3.1   DTE  Cliente  de  Portal  ..........................................................................................................  42   4.3.2   DTE  Cliente  de  Projeto  ........................................................................................................  42   4.3.3   DTE  Perfil  .................................................................................................................................  43   4.3.4   DTE  Projeto  ..............................................................................................................................  43   4.3.5   DTE  Usuário  .............................................................................................................................  44   4.4   Dicionário  de  Dados  ....................................................................................................  45   5   Propostas  Tecnológicas  .........................................................................................  53   5.1   Pontos  de  Função  ..........................................................................................................  53   5.1.1   Elementos  de  Contagem  de  Pontos  de  Função  .........................................................  54   5.1.2   Contagem  de  Pontos  de  Função  ......................................................................................  55   5.1.2.1   Tabela  de  Pontos  de  Função  ....................................................................................................  56   5.1.3   Composição  da  Equipe  de  Desenvolvimento  ............................................................  60   5.1.4   Mão  de  obra  para  o  Desenvolvimento  do  Sistema  ..................................................  60   5.1.5   Plano  de  Venda  de  Serviço  ................................................................................................  61   5.1.6   Primeira  Proposta  Tecnológica  .......................................................................................  63   5.1.6.1   Custo  Operacional  ........................................................................................................................  63   5.1.6.2   Custo  de  Investimento  (CI)  .......................................................................................................  64   5.1.6.3   Custo  Total  .......................................................................................................................................  64   5.1.7   Segunda  Proposta  Tecnológica  .......................................................................................  64   5.1.7.1   Custo  Operacional  ........................................................................................................................  65   5.1.7.2   Custo  de  Investimento  (CI)  .......................................................................................................  65   5.1.7.3   Custo  Total  .......................................................................................................................................  65   5.1.8   Proposta  Escolhida  ...............................................................................................................  66  

 

  6   Especificação  de  Projeto  ........................................................................................  67   6.1   Escolha  da  Tecnologia  .................................................................................................  67   6.1.1   Java  ..............................................................................................................................................  67   6.1.2   Arquitetura  Java  EE  6  ..........................................................................................................  68   6.1.2.1   Enterprise  JavaBeans  (EJB)  ......................................................................................................  69   6.1.2.2   Java  Server  Faces  –  JSF  ...............................................................................................................  70   6.1.2.3   PrimeFaces  ......................................................................................................................................  71   6.1.2.4   JSP/Servlets  ....................................................................................................................................  71   6.1.2.5   Java  Persistence  API  e  Hibernate  ...........................................................................................  71   6.1.3   Servidor  de  Aplicação  ..........................................................................................................  72   6.1.4   Maven  .........................................................................................................................................  73   6.1.5   PostgreSQL  ...............................................................................................................................  74   6.1.6   Spring  Tool  Suite  ...................................................................................................................  74   6.1.7   Controle  de  Versões  .............................................................................................................  75   6.1.8   Apache  HTTP  Server  ............................................................................................................  75   6.2   Padrões  de  Projeto  e  Outras  Técnicas  ...................................................................  76   6.2.1   Plain  Old  Java  Object  ............................................................................................................  76   6.2.2   Suporte  a  Internacionalização  .........................................................................................  76   6.3   Arquitetura  do  Sistema  ..............................................................................................  77   6.3.1   Diagrama  de  Pacotes  ...........................................................................................................  77   6.3.2   Divisão  em  Camadas  ............................................................................................................  78   6.3.3   Camada  Domínio  do  Problema  ........................................................................................  80   6.3.4   Camada  Gerência  de  Tarefas  ............................................................................................  85   6.3.5   Camada  Gerência  de  Dados  ...............................................................................................  85   6.3.6   Dicionário  de  Dados  do  Diagrama  Gerência  de  Dados  ..........................................  88   6.3.7   Diagrama  Relacional  ............................................................................................................  88   6.3.8   Dicionário  de  Dados  do  Diagrama  Relacional  ..........................................................  90   6.3.9   Camada  de  Interface  ao  Usuário  .....................................................................................  90   6.3.9.1   Grids  Base  ........................................................................................................................................  90   6.3.9.2   Ícones,  Botões  e  Mensagens  .....................................................................................................  93   6.3.9.3   Componentes  JSF  e  PrimeFaces  utilizados  na  Interface  ..............................................  95   6.3.9.4   Exemplos  de  Telas  do  Sistema  ................................................................................................  97   6.3.10   Diagramas  de  Sequência  Revisados  ..............................................................................  99   6.3.11   Estrutura  do  Projeto  ..........................................................................................................  101   6.3.12   Diagrama  de  Implantação  ...............................................................................................  102   7   Políticas  de  Segurança  .........................................................................................  104   8   Conclusão  .................................................................................................................  106   9   Referências  bibliográficas  ..................................................................................  107   ANEXO  A  –  DESCRIÇÕES  ESTENDIDAS  ....................................................................  110   ANEXO  B  –  MODELOS  DE  DESCRIÇÃO  DE  CASOS  DE  USO  DE  SOFTWARE  ....  188    

 

 

11  

1 INTRODUÇÃO É

notável

que

o

ser

humano

depende

muito

de

soluções

computacionais. Nas mais simples coisas que executadas ou relacionadas, por mais imperceptível que seja, elas estão presentes: computadores, internet, celulares, tablets, carros, geladeiras, enfim, a lista é realmente enorme. De uma forma geral, cada vez mais, processos antes feitos única e exclusivamente por humanos estão sendo computadorizados ou, ao menos sendo auxiliados por recursos computacionais. Medicina, indústria, educação, comércio, agropecuária, entre outros. Dificilmente conseguiremos pensar em alguma área que não esteja sendo incorporada ou que não esteja incorporando a informática em seus amplos fins. Este grande crescimento computacional precisa ser acompanhado pelo crescimento da quantidade de sistemas para auxiliar na resolução de tais tarefas. É fato que a construção de sistemas computacionais não é algo simples. Não basta sair por aí programando, pondo a ‘mão na massa’ ou algo do tipo. Este tipo de atitude já deveria ter se tornado coisa do passado. Qualquer profissional que trabalhe na área da computação deveria saber da importância de uma análise correta, um planejamento, um projeto e outros passos que envolvem a criação e a construção de um software ou sistema computacional. Outro fato é que, quando analistas de sistemas estão a confeccionar os artefatos da fase de levantamento de requisitos, geralmente usam templates em ferramentas não especializadas, como Microsoft Word ou em textos HTML, utilizando facilidades providas por meio de copiar e colar. Infelizmente, este processo é muito trabalhoso e propenso a erros e retrabalho. Estes são alguns dos problemas que o sistema desenvolvido se propõe a resolver, buscando ser uma ferramenta que automatize a criação de descrições estendidas de caso de uso, provendo reuso, facilidade de manutenção e controle, produtividade, diminuição de custos e outros.

 

 

1.1

12  

Motivação e Justificativa Ao longo principalmente da graduação, foi percebido o fato de que

muitas

das

tarefas

antes

exclusivamente

humanas

vêm

sendo

computadorizadas, removendo a complexidade e o risco e transferindo isto para um ambiente controlável, suportado por sistemas computacionais. A área de levantamento e especificação de requisitos não deveria ser diferente. Não foram encontradas ferramentas que se propõem a automatizar a criação e manutenção de descrições de caso de uso. Algumas empresas de tecnologia da informação acabam criando seus próprios templates e formas de trabalhar, porém o processo quase sempre gira em torno de editores de texto ou ferramentas que não são específicas ou direcionadas para esta finalidade. Imagine o problema: Tenho um componente de busca que realiza um filtro nos registros de Usuários do sistema. Este filtro se repete muitas vezes, em vários locais da aplicação. Idealmente, assim como na UML, eu apenas devo referenciar aquele caso de uso, porém na hora de fazer a especificação os analistas acabam por copiar e colar aquele caso de uso de uma especificação para a outra. Continuando, caso uma regra de negócio mude, agora vou filtrar usuários por e-mail, ou por uma situação específica. Replicar tudo isso em todas as especificações, pode ser uma tarefa extremamente trabalhosa! Pior ainda: como vou saber quais locais da minha aplicação deverão ser modificados? Isso vai exigir um conhecimento muito grande do sistema por parte do analista. Isso não seria um problema em projetos menores, onde um ou dois analistas dão conta do trabalho. Agora imagine um projeto grande, ou mesmo imagine se os analistas que inicialmente descreveram as especificações deixarem a empresa. No final das contas, podemos resumir que estas situações geram improdutividade, atrasos, falhas, extrapolação de custos, entre outros.

 

 

13  

1.2

Objetivos Este projeto têm como principal objetivo automatizar a criação e

manutenção de descrições de caso de uso de software, auxiliando o analista de sistemas em seu trabalho. Os objetivos específicos são: •

Desenvolver um software que possa ser acessado de diversos locais, com interface amigável, e que ajude o analista de sistemas na construção do artefato;

•

Coletar informações atuais de como as especificações de caso de uso de software são construídas, e com base nestas, projetar um padrão que possa ser seguido, facilmente expansível e adaptável aos processos mais utilizados na geração deste artefato;

•

Criar funcionalidades de software que permitam aos usuários reutilizar cenários de caso de uso de forma fácil, rápida e segura;

1.3

Metodologia O projeto será desenvolvido utilizando princípios de UML, com

conceitos de orientação a objetos, com a linguagem de programação Java, e prezando-se pelas boas práticas em análise, projeto e desenvolvimento de software.

1.4

Descrição dos Capítulos Os capítulos presentes neste documento estão dispostos da seguinte

forma: •

O capítulo 2, Conceitos, descreve os conceitos que devem ser compreendidos para o entendimento do software aqui proposto. A maioria deles está ligado à área de Análise de Requisitos de Software, que será utilizada tanto para a construção da especificação do sistema quanto para modelagem da solução.

 

 

14   •

O capítulo 3, Levantamento e Especificação de Requisitos, têm como objetivo descrever o ambiente no qual o sistema está inserido, apresentando as técnicas que foram utilizadas, as fontes de informações, os casos de uso, atores e pacotes que foram encontrados, além das propostas de melhoria.

•

O capítulo 4, Especificação de Análise, apresenta os artefatos que foram gerados a partir do levantamento e especificação de requisitos, como por exemplo o diagrama de classes, de sequência, de transição de estados, além do dicionário dos dados que foram utilizados na criação dos mesmos.

•

O capítulo 5, Propostas Tecnológicas, contempla a contagem de pontos de função para se desenvolver o sistema, as propostas tecnológicas que poderão ser adotadas, custos, previsão de retorno de investimento, entre outros.

•

O capítulo 6, Especificação de Projeto, abrange de forma específica toda a parte de escolha de tecnologia, englobando a linguagem de programação, padrões, divisão das camadas, especificações do pacote, entre outros.

•

O capítulo 7, Políticas de Segurança, define uma série de medidas para prevenir, diminuir e/ou contornar os riscos que são gerados ameaças, evitando ou minimizando ao máximo os danos que estas possam vir a causar no sistema.

•

O capítulo 8, Conclusão, descreve as dificuldades que foram encontradas no projeto, bem como o que foi aprendido.

•

Por fim, temos o capítulo Anexos, que contém as Descrições de Caso de Uso Estendidas do sistema TiEspec, além dos modelos de caso de uso utilizados durante a fase de análise.

 

 

15  

2 CONCEITOS São apresentados neste capítulo assuntos relevantes para o entendimento e a elaboração do projeto TiEspec.

2.1

Análise de Requisitos A análise de requisitos está associada ao processo de descobrir quais

são as operações que o sistema deve realizar e quais são as restrições que existem sobre elas. É nesta fase serão gerados os artefatos que o analista de sistema irá se apoiar para poder modelar e posteriormente projetar o sistema. Ela visa identificar as funcionalidades e operações presentes no sistema de forma a responder as seguintes perguntas: “De que forma essas operações se realizam?”, ou ainda “Quando, como, onde, para quem, por que, por quanto tempo, estas operações se realizam?”. (WAZLAVICK, 2004)

2.2

Analista de sistemas Este é o profissional que deve ter o conhecimento do domínio do

negócio. Ele precisa ter esta qualidade para que possa, com sucesso, definir o que o sistema precisará fazer (WAZLAVICK, 2004). Geralmente, o analista não é um especialista na área, mas precisa estar familiarizado com o vocabulário e os processos da mesma, no mínimo de forma macroscópica. Um dos principais papeis do analista de sistemas é entender as necessidades dos clientes e repassar este entendimento aos demais envolvidos no desenvolvimento do projeto, funcionando como uma ponte entre os dois grupos. No processo de desenvolvimento de um software, é este profissional que irá confeccionar os artefatos como descrições de caso de uso, diagramas de classes, diagramas de casos de uso, entre outros. (PRESSMANN, 2011)

 

 

16  

2.3

Modelagem de Caso de Uso O modelo de casos de uso serve como representação das

funcionalidades que o sistema irá prover, bem como dos elementos externos que interagem com o sistema. É nesta parte que os requisitos funcionais do sistema proposto serão refinados (BEZERRA, 2007). A construção deste modelo é composta por vários componentes. Entre eles podemos citar: diagramas de caso de uso, descrições de casos de uso, definição de atores e seus relacionamentos.

2.3.1 Diagrama de Casos de Uso O diagrama de caso de uso (DCU) é responsável por descrever o que o sistema faz do ponto de vista do usuário. (BEZERRA, 2007) Ele demonstra as funcionalidades do sistema e quais atores estão envolvidos com os mesmos. Em um DCU não se descrevem detalhes técnicos de como o sistema executa as funcionalidades; apenas quais funcionalidades ele executa. São úteis para dar uma visão clara ao cliente sobre as funcionalidades do sistema. São compostos basicamente de: •

Cenário: Sequência de eventos que acontecem quando um usuário interage com o sistema.

•

Ator: Usuário do sistema, ou melhor, um tipo de usuário.

•

Caso de Uso: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário).

•

Comunicação: é o que liga um ator com um caso de uso.

2.3.2 Atores Um ator define um conjunto coerente de papéis que os usuários do sistema podem desempenhar ao interagir com ele. Uma instância de

 

 

17  

ator pode ser desempenhada tanto por um indivíduo quanto por um sistema externo. Um ator é uma entidade que interage com o sistema participando e frequentemente iniciando um Caso de Uso. Eles não representam uma pessoa física ou algum sistema em si, mas sua regra, (WALZLAVICK, 2004).

2.3.3 Descrição de Casos de Uso

Segundo BEZERRA, 2007, um caso de uso é a especificação de uma sequência completa de interações entre um sistema e um ou mais agentes externos a esse sistema. São artefatos gerados com base nas funcionalidades que o sistema deve executar, que foram exibidas no diagrama de casos de uso, e têm como finalidade descrever de forma genérica qual o fluxo de trabalho que será adotado. É importante salientar que as descrições de caso de uso devem ser genéricas de forma a não entrar em detalhes técnicos de implementação, ao mesmo tempo devem ser detalhadas o suficiente para não gerarem dúvidas e ou pontas soltas no processo de desenvolvimento. Existem basicamente três dimensões em que o estilo de uma descrição de um caso de uso pode variar. Elas podem ser visualizadas na figura 1.

 

 

18  

  Figura 1 – Independência entre formato, grau de abstração e detalhamento de um caso de uso (BEZERRA, 2007)

O formato de uma descrição de caso de uso se relaciona com a estrutura utilizada para organizar a narrativa. Os formatos comumente utilizados são: •

Contínuo: Neste formato, é utilizada uma narrativa, em texto livre, que descreve como aconteceria algum caso de uso.

•

Numerado: Acontece por uma série de passos numerados, onde os atores envolvidos executam pequenos “passos”, e para cada passo, pode ou não haver uma resposta específica.

•

Tabular: Neste caso, as interações entre ator e sistema são divididas em duas colunas, onde uma delas representa as ações do ator e outra representa como o sistema reage a tal estímulo.

O grau de detalhamento, outra dimensão de estilo de caso de uso, varia desde o mais sucinto até a descrição detalhada (estendida). A ideia é que, quanto mais detalhada é a descrição, mais informações sobre a interação entre os atores serão escritas. O grau de abstração, a dimensão restante, diz respeito a existência ou não de aspectos relativos a uma tecnologia específica durante a descrição dos casos de uso. Quanto ao grau de abstração, as descrições podem ser dividas em dois grupos:

 

 

19   •

Caso de Uso Essencial: descreve a interação entre os atores de forma genérica, sem, em nenhum momento, especificar detalhes de tecnologia;

•

Caso de Uso Real: descreve a interação entre os atores citando detalhes e aspectos referentes a uma tecnologia em questão, e, de certa forma, amarrando o caso de uso a uma solução tecnológica específica; De forma geral e independente de qual fluxo de trabalho adotado, a

descrição de caso de uso é uma parte muito importante da modelagem de casos de uso, pois define o fluxo de ações que um ator deverá executar para que ele possa executar uma funcionalidade do sistema. A escolha de qual modelo será usado pode variar de projeto a projeto, dependendo das necessidades do cliente e do fornecedor.

Além própria da descrição do caso de uso, o documento gerado pode conter outras informações relevantes. São comumente adicionados no documento as seguintes informações: •

Código da Descrição: Uma forma de identificar aquele artefato unicamente dentro de um projeto;

•

Sumário: Representa o por que da criação da descrição, que visa atender a um requisito do sistema;

•

Atores

Envolvidos:

Os

atores

que

participam,

direta

ou

indiretamente nos casos de uso descritos; •

Questões em Aberto: Pontos que ainda não foram definidos, e que devem ser levados em consideração antes que a descrição seja liberada para desenvolvimento;

•

Prioridade: Qual é, para o projeto, a prioridade de entrega do que está descrito no documento;

•

Risco: Qual o nível de risco que aquele documento traz ao projeto, o que pode ser utilizado pela gerência de projetos para definir prioridades;

•

Regras de Negócio: As regras de negocio direta ou indiretamente relacionadas com o artefato;

 

 

20   •

Tipos de Dados: Os dados e informações do negócio que serão mantidos ou exibidos pelos casos de uso descritos;

•

Casos de Uso Relacionados: Outras descrições que possuem forte relacionamento com os casos de uso descritos no documento;

•

Notas de Implementação: Detalhes técnicos, especificando a forma que aqueles casos de uso deverão ser desenvolvidos; Uma das maiores dificuldades na hora de se construir este tipo de

artefato é conseguir refletir as regras pertinentes ao negócio, muitas vezes extremamente complexas, em textos simples e fáceis de serem entendidos. O

artefato

gerado,

além

de

ser

diretamente

utilizado

no

desenvolvimento do sistema, tem se tornado uma espécie de contrato entre cliente e fornecedor. Assim o cliente e o fornecedor, podem, respectivamente, saber o que contrataram e o que devem entregar.

 

 

21  

3 LEVANTAMENTO E ESPECIFICAÇÃO DE REQUISITOS Conforme

foi

comentado

anteriormente,

o

levantamento

e

a

especificação de requisitos são partes de grande importância dentro do processo de construção de um software.

A partir de agora, serão

apresentados os detalhes do sistema e os artefatos gerados durante o processos da construção do software.

3.1

Descrição do Mini Mundo O sistema a ser desenvolvido deverá automatizar e gerenciar a

manutenção de casos de uso do processo de especificação de requisitos de sistemas computacionais. Basicamente, o sistema proverá funcionalidades para criação de descrições estendidas de caso de uso baseado em reuso de cenários. O sistema deverá prover suporte a múltiplos clientes com múltiplos usuários. Para isso, teremos um “Cliente de Portal”. Esse cliente corresponde a grupos de pessoas que terão acesso representando uma mesma empresa ou organização. Os usuários pertencentes a um mesmo cliente de portal poderão compartilhar seus projetos, modificar descrições estendidas, utilizar padrões de fluxos, e irão utilizar uma mesma configuração de descrição estendida. Um cliente de portal poderá personalizar quais campos ele deseja que seus usuários mantenham nas descrições estendidas. Os usuários do sistema deverão registrar seu nome completo, nome curto, e-mail, e terão ainda uma situação (Ativo, Suspenso, Excluído, Pendente Aprovação, Pendente Ativação E-mail). Os clientes de projeto são os clientes de uma organização ou empresa, para os quais serão construídas as descrições estendidas. Eles só podem ser visíveis aos usuários de uma mesma organização. Um cliente de projeto deve ter nome, observações, e deve ter registro de contatos. Um projeto pertence a um cliente de projeto e a um cliente de portal. Um projeto terá datas de inicio e fim(previstas e reais), código, nome e

 

 

22  

situação. Um projeto pode ter vários artefatos. Artefatos são conjuntos de documentos, fotos, textos, enfim, registros diversos que servirão de apoio aos usuários na hora de criar e manter as descrições estendidas. Os artefatos podem ser anexos ou ser incluídos na própria aplicação, caso sejam textos. Além disso, é necessário saber qual usuário cadastrou o artefato. O sistema também permitirá o cadastro de Atores. Estes (principais ou secundários) serão utilizados na construção das descrições estendidas. De uma descrição estendida podemos manter os seguintes atributos: Código, Sumário, Pré-condições, Questões em Aberto, Pós Condições, Risco, Prioridade, Regras de Negócio, Casos de Uso Relacionados, Variações Tecnológicas, Notas de Implementação Dados (Nome na Tela, Atributo de Classe, Regra/Descrição, Tipo de Dado, Tamanho, Editável, Obrigatório) e Cenários (Nome, Ponto de Chamada, Fluxo Alternativo, Fluxos). Um cenário corresponde a um conjunto de ações executadas no sistema, seja pelo sistema ou por outro ator. Cada cenário representa uma funcionalidade de sistema. As funcionalidades implementadas no sistema não devem demorar mais de 5 segundos para ocorrer (Consultas simples, criação e edição de registros, e remoção de registros, navegação entre páginas, etc.). Os relatórios de sistema deverão ser executados em no máximo 15 segundos. O sistema deverá funcionar por meio da internet e ser acessível nos principais web browsers do mercado. A construção do sistema deverá priorizar o uso de softwares e tecnologias de código aberto tais como Linux, Java, PostGreSQL, entre outras.

3.2

Problemas, Causas e Possíveis Soluções

A tabela 1 descreve os problemas encontrados, as causas e as possíveis soluções. Tabela 1 – Problemas, Causas e Possíveis Soluções

Problemas Levantados

 

Causas

Possíveis Soluções

 

23  

Descrições de casos de Grande

quantidade Quanto ao número de

uso com muitos erros de especificações, o especificações não temos nos fluxos.

que

dificulta

manutenção

a muito o que fazer, porém deste pode ser construída uma

tipo de artefato. Qualidade

ferramenta que auxilie no do controle

processo

e

e

manutenção

dos das mesmas

envolvidos Cenários

pouco Trabalho

descritos, deixando os mais

repetitivo, Uma ferramenta que use

propenso

a padrões

fluxos muito abertos, erros. erros

e Esquecer

divergências

entre

o programador

que

o dos

templates

de

não especificação, e que o

que o cliente quer e o sabe o que o cliente analista o

descrição,

automatize a construção

ocasionando

que

de

programador quer.

tenha

trabalho

realmente desenvolveu.

menos

para

ficar

acertando detalhes, e se preocupe com as regras de negócio.

Pouca

documentação Prazos

ou

documentação analistas

incompleta.

apertados, Transferir o processo de não construção de descrições

capacitados,

estendidas

processo

de ferramenta,

para

a

tornando-a

desenvolvimento

mais

padronizada

e

pouco maduro

menos dependente dos próprios analistas.

Atraso

em

projetos Baixo

nível

de Prover uma forma rápida

decorrentes de falhas detalhamento de especificações

de e fácil de criar e manter

especificações, deixando

descrições, que ajude o

muitas analista a gerar artefatos

decisões na mão de mais completos programadores, não

sabem

que a

necessidade real do

 

 

24   cliente.

Extrapolação de custos Devido as falhas na Reduzir a quantidade de envolvidos em projetos especificação, muito erros de especificação, de

sistemas

de do que foi definido minimizando o retrabalho.

software

precisa

ser

modificado, causando retrabalho,

que

impacta diretamente nos

custos

do

projeto.

3.3

Fontes de Informação e Técnicas Utilizadas A tabela 2 informa as fontes de informação bem como as técnicas

utilizadas para colher as informações necessárias no desenvolvimento deste documento.

Tabela 2 – Fontes de Informação e Técnicas Utilizadas

Fonte de Informação

Técnica Utilizada

Descrições de caso de uso FSW- Leitura de Documentos UVV

e

FSW-VIX,

descrições

presentes nos livros de BEZERRA, 2007 e WAZLAVICK, 2004 Processos

de

construção

de Observação

especificações de caso de uso da fábrica

de

Europa

software

do

Grupo

Empreendimentos

Negócios

3.4

 

Diagrama de Pacotes

e

 

25   Diagrama de Pacotes é aquele que descreve os pacotes ou pedaços

do sistema divididos em agrupamentos lógicos mostrando as dependências entre os mesmos. Um pacote representa um grupo de classes e/ou outros elementos que se relacionam com outros pacotes através de uma relação de dependência. É uma visão do sistema como um todo, sob tal perspectiva que se possa observar todos os subsistemas que o compõem. Tem como proposta apresentar a modelagem estrutural do sistema em divisões lógicas e suas interações em alto nível, (WIKIPEDIA, 2012).

  Figura 2 – Diagrama de Pacotes

A figura 2 apresenta o Diagrama de Pacotes do sistema TiEspec. O pacote Cadastro representa e engloba todas as funcionalidades necessárias para que os usuários e clientes possam se cadastrar no sistema, serem aprovados, e efetivamente utilizar o portal. O pacote de Suporte engloba todas as funcionalidades que darão base e proverão dados para que o pacote de Especificações possa ter seus casos de uso efetuados. Entre as funcionalidades aqui presentes podemos citar a manutenção de Clientes de Projeto, Projetos, Artefatos, entre outros. O pacote de Especificação representa as funcionalidades onde o usuário vai realmente construir as especificações de caso de uso, criando atores, cenários base, especificações, e também imprimindo as mesmas.

 

 

26   Por fim, temos o pacote Utilidades, que abrange todas as

funcionalidades que serão necessárias para o bom funcionamento do sistema, como funcionalidades de envio de e-mail, configuração de base de dados, entre outras.

3.5

Modelagem de Caso de Uso O conceito de modelagem de caso de uso já foi apresentado

anteriormente, no capítulo 2, Conceitos. Nas próximas páginas temos os artefatos gerados nesta fase.

3.5.1 Diagrama de Casos de Uso A figura 3 representa o diagrama de casos de uso do pacote de especificação do sistema TiEspec, e suas respectivas funcionalidades.

Figura 3 – Diagrama de Casos de Uso

 

 

27  

 

3.5.2 Descrição de Atores A seguir são descritos os atores do sistema em construção. Os casos de uso que cada ator possui acesso podem ser visualizados na figura 3. •

Administrador do Portal: É o responsável por manter a ferramenta a nível administrativo. Ele representa o dono do portal, mantém o cadastro dos clientes de portal e pode manter todos os usuários do sistema.

•

Administrador do Cliente(Usuário Responsável): É o usuário responsável por algum cliente do portal. Ele têm a tarefa de configurar as descrições, cadastrar clientes de projeto, manter os projetos e os usuários de seu cliente, além também de realizar as mesmas tarefas de um usuário cliente.

•

Usuário Registrado: Podem ser considerados como analistas de sistemas,

que

utilizarão

as

funcionalidades

de

criação

de

especificação do sistema. Eles terão acesso a manutenção de casos de uso, poderão criar cenários, cadastrar dados, manter artefatos em um projeto, entre outros. •

Usuário: É qualquer outro usuário que acesse o sistema e que não esteja logado.

3.5.3 Descrição de Caso de Uso A importância da criação de descrições de caso de uso já foi discutida no capítulo de conceitos, e se reforça ainda mais pela ideia da ferramenta que está sendo construída. A tabela a seguir descreve, sucintamente, as descrições de caso de uso deste sistema. As descrições expandidas podem ser encontradas ao final deste documento, no anexo A.

Tabela 3 – Descrição Sucinta de Casos de Uso do Sistema

Nome

Descrição

ESP00 – Solicitação de Prover uma funcionalidade onde novos clientes

 

 

28  

Cadastro

no

Portal possam se cadastrar no portal e ter acesso as

(Cliente Não Existente)

demais

funcionalidades

de

uma

forma

controlada. ESP00A – Solicitação de Prover Cadastro

no

uma

funcionalidade

onde

usuários

Portal possam se cadastrar no portal, e que o cliente ao

(Cliente Existente)

qual pertence já existe.

ESP01 – Manter Clientes Permitir de Portal

aos

administradores

do

sistema

cadastrar, alterar e remover clientes de portal que terão acesso a aplicação.

ESP01A – Aprovação de Prover Clientes de Portal

uma

funcionalidade

onde

os

administradores possam ver as aprovações de clientes pendentes no portal, e aprova-las de forma rápida.

ESP02

–

Manter Permitir

aos

administradores

do

sistema

Usuários

manterem os usuários de algum cliente do portal,

(Administrador)

alterar e remover registros.

ESP02A

–

Manter Permitir ao usuário responsável de um cliente

Usuários

(Usuário manter os seus usuários, criando, alterando e

Responsável)

removendo registros.

ESP02B – Aprovação de Prover uma funcionalidade onde os usuários Usuários de Cliente de responsáveis de um cliente de portal possam ver Portal

os usuários pendentes de seu cliente, e aprovalos de forma rápida.

ESP03

–

Configurar Permite ao usuário responsável do sistema

Descrição Estendida

configurar os campos que irão aparecer na funcionalidades de manutenção de descrições estendidas.

ESP04

–

Manter Permitir aos clientes de portal e seus usuários

Cenários Base

manterem fluxos padrão de especificação, ou seja, criar fluxos de casos de uso base, para serem ser reutilizados na hora de criar casos de uso em uma especificação.

ESP05 – Manter Atores

 

Permite

que

os

usuários

de

um

cliente

 

29   mantenham os dados dos possíveis Atores que possam ser utilizados na hora se construir especificações técnicas.

ESP06 – Manter Clientes Permitir aos usuários administradores de um de Projeto

cliente de portal cadastrar, alterar e remover dados de seus clientes de projeto.

ESP07

–

Manter Permitir aos usuários de um cliente de portal

Projetos

cadastrar, alterar e remover dados de seus projetos.

ESP08

–

Manter Permitir aos usuários de um cliente de portal

Artefatos de Projeto

cadastrar,

alterar

e

remover

artefatos

e

documentos dentro de um projeto, que serão utilizados para consulta. ESP09

–

Manter Permitir aos usuários de um cliente do portal

Descrições Estendidas

fazerem a manutenções de diversos dados referentes a descrições estendidas.

ESP09 – Impressão De Permitir aos usuários de um cliente do portal Descrições Estendidas

gerar os arquivos de impressão das descrições que foram confeccionadas por meio do sistema.

 

 

30  

4 ESPECIFICAÇÃO DE ANÁLISE Segundo WAZLAWICK, 2004, a especificação de análise enfatiza a investigação do problema proposto. O principal objetivo da fase de análise é levar o analista ao entendimento de como o sistema em questão funciona. Nas próximas páginas serão apresentados os artefatos gerados durante esta fase.

4.1

Diagrama de Classes O Diagrama de Classes é um modelo estático que dá suporte a

visualização do sistema desenvolvido. Ele mostra as classes e os relacionamentos entre as mesmas que permanecem constantes no sistema com o passar do tempo (BEZERRA, 2007). A figura 4 representa o Diagrama Classes do sistema proposto. Foi utilizada uma definição de tipos abstratos para facilitar o entendimento do modelo pelo cliente e/ou leigos para com este tipo de notação. Os tipos utilizados estão listados a seguir: •

Booleano: Representa um valor que aceita uma de duas opções, no caso, Verdadeiro ou Falso;

•

Caracter: São textos de tamanho máximo de 255 caracteres;

•

Data: Representa valores de tempo, que só trabalham apenas com anos, meses e dias, não importando horas, minutos e segundos;

•

DataHora: Representa valores de datas completas, importando anos, meses dias, horas, minutos e segundos;

•

Documento: Representa conteúdos de texto com um limite de 4096 caracteres. Para uma interface web, atributos deste tipo irão ser alterados geralmente por meio de um editor de texto de interface rica, com opções de formatação;

•

Número: Representam conjuntos numéricos diversos, podendo ser inteiros ou números decimais;

 

 

31   •

PK: Utilizada em diagramas de sequência para representar um atributo que identifica unicamente um registro para o sistema;

•

FK: Utilizado no mapeamento objeto relacional para definir chaves estrangeiras, que criam relacionamentos entre objetos do sistema;

•

Texto: Representa conteúdos de texto com tamanho limite de 4000 caracteres.;

 

 

32  

Figura 4 – Diagrama de Classes

 

 

 

33   Assim também foram criadas classes para representar os estados que

um objeto pode assumir durante seu ciclo de vida. Estas classes estão descritas abaixo, e são melhores comentadas na sessão 4.3, Diagramas de Transição de Estados. São elas: •

SituClientePortal;

•

SituClienteProjeto;

•

SituDescricao;

•

SituPerfil;

•

SituProjeto;

 

4.2

Diagramas de Sequência O diagrama de sequência é um diagrama que representa uma

sequência de mensagens passadas entre objetos em um sistema computacional. Ele descreve a maneira em que grupos de objetos colaboram entre si para gerar um comportamento ao longo da execução, (WIKIPEDIA, 2012). Ele é criado principalmente para determinar a sequência global do comportamento dos objetos de uma forma simples e lógica. São componentes de um diagrama de sequência: •

Atores: São entidades externas que interagem com o sistema e que solicitam serviços.

•

Objetos: Representam as instâncias das classes representadas no processo.

•

Gate: Indica um ponto em que a mensagem pode ser transmitida para dentro ou para fora.

•

Fragmento: Fragmentos de interação como: Alt (Alternativa), Opt (Opcional), Break (Parar), Loop (Repetição) e outras.

•

Linha de vida: As linhas de vida compõem a dimensão vertical. A classe denominada Controller, presente nos diagramas de

sequência a seguir, representam o sistema, que irá receber o estímulo vindo do usuário e servirá como interface para as funcionalidades.

 

 

34   As figuras de número 5 à 24 representam os diagramas de sequência

do sistema TiEspec. Não foram gerados os diagramas de sequência para todas as funcionalidades do sistema, pois muitas das funcionalidades utilizam de um mesmo fluxo de troca de mensagens.

Figura 5 – DS – Aprovação de Clientes do Portal

Figura 6 – DS – Aprovação de Clientes do Portal

 

 

 

 

35  

Figura 7 – DS –Aprovação de Usuários

Figura 8 – DS – Atualizar Ator

Figura 9 – DS – Cadastrar Ato

Figura 10 – DS – Excluir Ator

 

 

 

 

 

 

36  

Figura 11 – DS – Listar Atores

Figura 12 – DS –Cadastrar Descrição Estendida

Figura 13 – DS – Cadastrar Projeto

 

 

 

 

 

37  

Figura 14 – DS – Alterar Projeto

Figura 15 – DS – Excluir Projeto

 

Figura 16 – DS – Visualizar Projeto

 

 

 

 

38  

 

Figura 17 – DS – Configurar Descrições Estendidas

Figura 18 – DS – Criar Artefato

Figura 19 – DS – Alterar Artefato

 

 

 

 

 

39  

Figura 20 – DS – Excluir Artefato

Figura 21 – DS – Imprimir Descrição Estendida

 

 

 

 

40  

Figura 22 – DS – Listar Usuários (Administrador)

Figura 23 – DS – Solicitar Cadastro No Portal (Cliente Existente)

 

 

 

 

41  

 

Figura 24 – DS – Solicitar Cadastro no Portal (Cliente Não Existente)

Figura 25 – DS – Visualizar Cliente de Portal

4.3

 

Diagrama de Transição de Estados Um Diagrama de Transição de Estados (DTE) têm como objetivo

demonstrar todos os estados possíveis de um objeto, os eventos que alteram tal estado, as condições que devem ser satisfeitas para que uma transição possa ocorrer e as respectivas ações durante a vida do objeto, (BEZERRA, 2007). •

Estado: É qualquer condição na qual um objeto satisfaz uma condição, executa uma ação ou aguarda por um evento.

•

Evento: É qualquer acontecimento que provoque uma mudança de estados. Pode ser oriundo de um sinal interno ou externo ao sistema.

 

•

Transição: É a mudança de estado de um objeto.

•

Ação: É a resposta de um objeto a mudança de estado.

 

42   A seguir, podemos visualizar todos os diagramas de transição de

estados dos objetos de negócio do sistema proposto.

4.3.1 DTE Cliente de Portal   A figura 26 representa a transição entre estados de objetos da classe Cliente de Portal. Para representar esta troca de estados, foi criado um atributo chamado situação do tipo “SituClientePortal”, que pode assumir os valores dos estados representados no diagrama, e têm como finalidade auxiliar no fluxo de criação, manutenção e remoção de clientes de portal. Clientes com situação “Excluído” não poderão ser reativados por meio da aplicação.

  Figura 26 – DTE – Cliente de Portal

   

4.3.2 DTE Cliente de Projeto A figura 27 representa a transição de estados dos objetos da classe Cliente de Projeto. Para representar estes estados, foi criado um atributo

 

 

43  

chamado situação do tipo “SituClienteProjeto”, que pode assumir os valores descritos no diagrama. Objetos na situação “Excluído” não poderão ser reativados por meio da aplicação.

Figura 27 – DTE – Cliente de Projeto

 

 

4.3.3 DTE Perfil A figura 28 representa a transição de estados dos objetos da classe Perfil. Para representar estes estados, foi criado um atributo chamado situação do tipo “SituPerfil”, que pode assumir os valores descritos no diagrama. Objetos na situação “Excluído” não poderão ser reativados por meio da aplicação.

Figura 28 – DTE – Perfil

 

4.3.4 DTE Projeto A figura 29 representa a transição de estados dos objetos da classe Projeto. Para representar estes estados, foi criado um atributo chamado situação do tipo “SituProjeto”, que pode assumir os valores descritos no diagrama. Parte da transição de estados se dá por uma fórmula envolvendo o atributo “Data de Término Prevista”. Quando restar apenas 5% do intervalo entre a data de início prevista e a data de fim prevista, o objeto deve mudar

 

 

44  

automaticamente para a situação ‘Tempo Crítico. Quando a data atual for maior que a data fim prevista, a situação deve mudar para ‘Atrasado’. O usuário pode, a qualquer momento, cancelar ou concluir o projeto.

  Figura 29 – DTE - Projetos

4.3.5 DTE Usuário A figura 30 representa a transição de estados dos objetos da classe Usuário. Para representar estes estados, foi criado um atributo chamado situação do tipo “SituUsuario”, que pode assumir os valores descritos no diagrama. A criação de tal atributo foi causada pela necessidade de controle do fluxo de criação e manutenção de usuários. Objetos na situação “Excluído” não poderão ser reativados por meio da aplicação.

 

 

45  

Figura 30 – DTE – Usuários

4.4

 

Dicionário de Dados O dicionário de dados compreende os locais onde serão armazenadas

informações dos atributos das classes de negócio. As tabelas numeradas de 4 a 20 descrevem os atributos das classes de negócio que serão utilizadas ou mantidas pelo sistema. A tabela 4 representa atributos que todas as classes de negócio implementarão. O propósito de cada campo está descrito na coluna Regra/Descrição.   Tabela 4 – Dicionário de Dados – Entidade Campo

Edit.

Obr.

Formato

Regra/Descrição Chave primária do registro. Usado como “Id

id

N

S

Número

Burro”, começa em 0 e é incrementado de 1 em 1 para cada novo registro da tabela. Inicia em 0 e é incrementado de 1 em 1 para cada alteração que for feita registro. É

version

S

S

Número

utilizado como mecanismo garantia de integridade de dados para sistemas de acesso compartilhado.

 

 

46  

Tabela 5 – Dicionário de Dados – Anexo Campo

Edit.

Obr.

Formato

Regra/Descrição

nome

S

S

Caracter[128]

Nome que irá identificar o anexo.

content_type

N

S

Caracter[48]

Tipo do anexo.

tamanho

N

S

Número

artefato_id

N

S

FK

Representa o tamanho do anexo. Não pode ser menor ou igual a 0; Aponta para o artefato ao qual o anexo pertence.

Tabela 6 – Dicionário de Dados – Artefato Campo

Edit.

Obr.

Formato

Regra/Descrição

nome

S

S

Caracter[128]

descricao

S

N

Texto[4000]

data_hora_criacao

N

S

DataHora

projeto_id

S

S

FK

responsavel_id

N

S

FK

Nome

de

identificação

do

artefato. Descrição sobre o registro. Momento da criação do artefato. Aponta para o projeto cujo o artefato está relacionado. Aponta para o usuário de criação do registro

Tabela 7 – Dicionário de Dados – Atores Campo

Edit.

Obr.

Formato

Regra/Descrição

nome

S

S

Caracter[128]

cliente_id

N

S

FK

Nome de identificação do ator. Aponta para o cliente de portal do usuário que cadastrou o registro.

Tabela 8 – Dicionário de Dados – Cenário Campo

Edit.

Obr.

nome

S

S

Caracter[255]

ponto_chamada

S

S

Caracter[255]

fluxo_alternativo

S

S

Caracter[255]

descricao_estentida_id

N

S

FK

 

Formato

Regra/Descrição Nome

de

identificação

do

artefato. Informações Sobre o Ponto de Chamada do Cenário Informações sobre o Fluxo Alternativo do Cenário Chave da descrição estendida

 

47   que o cenário pertence

Tabela 9 – Dicionário de Dados - Cliente de Portal Campo

Edit.

Obr.

Formato

nome_completo

S

S

Caracter[255]

nome_curto

S

S

Caracter[64]

observacoes

S

N

Texto[2000]

Regra/Descrição Nome do Completo do Cliente de Portal Nome Curto do Cliente de Portal Informações Relevantes Sobre o Cliente SituClientePortal: 0. Ativo

situacao

S

S

Número

1. Suspenso 2. Excluido 3. PendenteAprovacao 4. PendenteAprovacaoEmail

data_cadastro

N

S

DataHora

Data de Cadastro do Cliente

data_aprovacao

S

N

DataHora

Data de Aprovação do Cliente

logo

S

N

Imagem

Logomarca do Cliente Arquivo

config_descricao_es

N

tentida

S

FK

de

Configuração

de

Descrição Estendida do Cliente de Portal

resposavel_id

N

S

FK

Usuário responsável pela criação do Cliente

Tabela 10 – Dicionário de Dados – Cliente de Projeto Campo

Edit.

Obr.

Formato

nome_completo

S

S

Caracter[255]

nome_curto

S

S

Caracter[128]

observacoes

S

N

Texto[4000]

Regra/Descrição Nome do Completo do Cliente de Projeto Nome Curto do Cliente de Projeto Informações Relevantes Sobre o Cliente SituClienteProjeto:

situacao

S

S

Número

0. Ativo 1. Desativado 2. Excluído

cliente_portal_id

 

N

S

DataHora

Cliente de Portal a qual o Cliente de Projeto Pertence.

 

48  

Tabela 11 – Dicionário de Dados – Configuração de Descrição Estendida Campo

Edit.

Obr.

Formato

codigo

N

S

Booleano

sumario

N

S

Booleano

atores

S

S

Booleano

pre_condicoes

S

S

Booleano

prioridade

N

S

Booleano

pos_condicoes

S

S

Booleano

risco

N

S

Booleano

regras_negocio

S

S

Booleano

questoes_aberto

S

S

Booleano

caso_uso_relacionados

S

S

Booleano

variacoes_tecnologicas

S

S

Booleano

notas_implementacao

S

S

Booleano

Regra/Descrição Se o código será mantido na aplicação Se o sumário será mantido pela aplicação Se os atores serão mantidos pela aplicação Se

as

pré-condições

serão

mantidas pela aplicação Se a prioridade será mantida pela aplicação Se

as

pós-condições

serão

mantidas pela aplicação Se o risco será mantido pela aplicação Se as regras de negócio serão mantidas pela aplicação Se as questões em aberto serão mantidas pela aplicação Se os casos de uso relacionados serão mantidos pela aplicação Se as variações tecnológicas serão mantidas pela aplicação Se as notas de implementação serão mantidas pela aplicação

Tabela 12 – Dicionário de Dados – Contatos Campo

Edit.

Obr.

nome_contato

S

S

Caracter[128]

telefones

S

N

Caracter[128]

email

S

N

Caracter[128]

observacoes

S

N

Texto[2000]

cliente_projeto_id

N

S

FK

 

Formato

Regra/Descrição Nome do Contato de Um cliente de Projeto Os Telefones que o contato ode ser encontrado E-mail do Contato Observações Sobre o Contato Relacionamento Com Cliente de Projeto

 

49  

Tabela 13 – Dicionário de Dados – Dados Campo

Edit.

Obr.

Formato

nome_tela

S

S

Caracter[128]

atributo_classe

S

S

Caracter[128]

regra_descricao

S

N

Caracter[255]

tipo_dado

S

S

Caracter[32]

tamanho

S

N

Número

editavel

S

S

Booleano

obrigatorio

S

S

Booleano

descricao_estendida_id

N

S

FK

Regra/Descrição Nome do Atributo na Tela Atributo que o campo será na classe Regra ou Descrição sobre o Atributo Tipo de Dado do Atributo Tamanho do Campo Se o campo é editável ou não Se o campo é obrigatório ou não Relacionamento

com

a

Descrição Estendida

Tabela 14 – Dicionário de Dados – Descrição Estendida Campo

Edit.

Obr.

Formato

codigo

S

S

Caracter[10]

sumario

S

S

Texto[4000]

riscos

S

S

TipoRisco

prioridade

S

S

TipoPrioridade

Regra/Descrição O

código

da

Estendida Sumário da DE Os Riscos do Conjunto de Funcionalidades A prioridade desta DE Pré-condições

pre_condicoes

S

N

Texto[1000]

Descrição

para

execução

a das

funcionalidades questoes_aberto

S

N

Texto[1000]

pos_condicoes

S

N

Texto[1000]

regras_negocio

S

N

Texto[1000]

casos_uso_relacionados

S

N

Caracter[255]

variacoes_tecnologicas

S

N

Texto[1000]

notas_implementacao

S

N

Texto[1000]

 

Questões em aberto das funcionalidades Pós-condições

das

funcionalidades Regras

de

negócio

envolvidas nesta DE Casos de Uso que estão relacionados com esta DE Variações

tecnológicas

relacionadas Notas

sobre

implementação

a das

 

50   funcionalidades Chave

projeto_id

N

S

FK

Estrangeira

apontando para o projeto o qual a descrição pertence

Tabela 15 – Dicionário de Dados – Documento Campo

Edit.

Obr.

Formato

nome

S

S

Caracter[128]

conteudo

S

S

Texto[4000]

Regra/Descrição Nome do Documento Conteúdo do Documento Chave Estrangeira apontando para

artefato_id

N

S

FK

o artefato ao qual este documento pertence

Tabela 16 – Dicionário de Dados – Fluxo Campo

Edit.

Obr.

Formato

cod_fluxo

N

S

Caracter[32]

descricao

S

S

Caracter[255]

Regra/Descrição Índice

N

S

FK

para

ordenação.

Mantido pela própria aplicação Texto de um respectivo fluxo Chave

cenario_id

usado

estrangeira

que

aponta

para o cenário que possui o respectivo fluxo

Tabela 17 – Dicionário de Dados – Fluxo Base Campo

Edit.

Obr.

Formato

cod_fluxo

N

S

Caracter[32]

acao

S

S

Caracter[255]

Regra/Descrição Índice

N

S

FK

para

Texto de um respectivo fluxo estrangeira

Tabela 18 – Dicionário de Dados – Perfil Edit.

Obr.

nome

N

S

Caracter[128]

situacao

N

S

SituPerfil

 

Formato

que

aponta

para o cenário base que possui o respectivo fluxo

Campo

ordenação.

Mantido pela própria aplicação

Chave cenario_base_id

usado

Regra/Descrição Nome do Perfil SituPortal: 0. Ativo

 

51   1. Suspenso 2. Excluído

Tabela 19 – Dicionário de Dados – Projeto Campo

Edit.

Obr.

Formato

Regra/Descrição

codigo

N

S

Caracter[16]

Código do projeto

nome

N

S

Caracter[255]

Nome Completo do Projeto

descricao

S

S

Texto[4000]

data_inicio_prevista

S

S

Data

data_inicio_real

S

N

Data

Data de Início Real do Projeto

data_fim_prevista

S

N

Data

Data Prevista do Fim do Projeto

data_fim_real

S

N

Data

Data de Fim Real do Projeto

Descrição sobre o projeto Data

Prevista

de

Início

do

Projeto

SituProjeto: 0. AIniciar situacao

S

S

1. Ativo

SituProjeto

2. Cancelado 3. Concluído 4. Atrasado Chave Estrangeira que aponta

cliente_projeto

N

S

FK

para o cliente que é dono do projeto.

Tabela 20 – Dicionário de Dados – Usuário Campo

Edit.

Obr.

Formato

Regra/Descrição

nome_completo

S

S

Caracter[255]

Nome Completo do Usuário

nome_curto

S

N

Caracter[128]

Nome Curto do Usuário

email

S

S

Caracter[128]

E-mail do Usuário. Também usado como login. Senha

senha

S

S

Caracter[128]

de

acesso

ao

sistema.

Gravada com aplicação algoritmo de resumo de mensagem.

token

N

N

Caracter[128]

email_enviado

N

N

Booleano

situação

S

S

SituUsuario

 

Identificação

para

WorkFlow

de

Criação de cadastro Flag para confirmação de e-mail de cadastro enviado SituUsuario:

 

52   0. Ativo 1. Suspenso 2. Excluido 3. PendenteAprovacao 4. PendenteAprovacaoEmail Representa

responsavel

N

N

FK

se

o

usuário

é

responsável por algum Cliente de Portal

cliente_id

N

S

FK

perfil_id

N

S

FK

 

Representa o cliente de Portal ao qual o usuário pertence. Perfil do usuário.

 

53  

5 PROPOSTAS TECNOLÓGICAS Para o desenvolvimento deste projeto, será utilizada a plataforma de programação Java, em sua versão 6. Dentro da plataforma, serão utilizados os componentes da Arquitetura Java EE 6, sendo os mais notáveis o EJB, Java Server Faces, Managed Beans, e Java Persistence API. Como servidor de aplicação será utilizado o GlassFish Server e, finalmente, como provedor de serviços de persistência de dados, será utilizado o PostgreSQL, em sua versão 9.1. A escolha das tecnologias se deu pela notoriedade e confiabilidade que cada uma possui em sua área de atuação. Este capítulo tem como objetivo descrever a contagem de pontos de função do sistema aqui proposto, bem como o investimento para a construção do mesmo, o custo operacional, o retorno esperado, entre outros.

5.1

Pontos de Função Segundo VAZQUEZ, SIMÕES e ALBERT, 2010, a análise de pontos de

função é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. Ponto de função é uma unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. A APF (Análise de Pontos de Função) tem como objetivos: •

Medir as funções que o usuário solicita e recebe;

•

Medir o desenvolvimento e manutenção de software independente da tecnologia de implementação;

A técnica define algumas abstrações necessárias à determinação do tamanho funcional do sistema. Estes conceitos representam os componentes do

sistema

que

fornecem

funcionalidades

de

armazenamento

e

processamento de dados aos seus usuários e por eles reconhecidas e solicitadas. Ela também fornece definições de conceitos utilizados como referência na identificação desses componentes.

 

 

54  

5.1.1 Elementos de Contagem de Pontos de Função   Os elementos envolvidos na contagem de pontos de função são separados em dois grandes grupos, conhecidos como funções do tipo dado e funções do tipo transação. As funções do tipo dado representam as funcionalidades fornecidas pelo sistema ao usuário para atender a suas necessidades de armazenamento de dados. São divididas em: •

Arquivo Lógico Interno (ALI): Representa os conjuntos de dados ou informações de controle, logicamente relacionados, identificável pelo usuário e mantidos dentro da fronteira da aplicação. Sua principal intenção é armazenar dados mantidos através de uma ou mais transações.

•

Arquivo de Interface Externa (AIE): Representa os conjuntos de dados ou informações de controle, mantidos fora da aplicação. Tem como objetivo armazenar dados referenciais através de transações da aplicação. As funções do tipo transação representam os requisitos de

processamento fornecidos pelo sistema ao usuário. São classificadas em: •

Entrada Externa (EE): É uma transação que processa dados ou informações de controle originados de fora da aplicação. Seu objetivo é manter arquivos lógicos internos e/ou alterar o comportamento do sistema.

•

Saída Externa (SE): É uma função do tipo transação que envia dados ou informações de controle para fora da fronteira da aplicação. Sua principal intenção é apresentar informações ao usuário através de lógica de processamento que não seja apenas uma simples recuperação

de

dados

ou

informações

de

controle.

Seu

processamento deve conter cálculo, ou criar dados derivados, ou manter um arquivo lógico interno, ou alterar o comportamento do sistema (relatórios com cálculos). •

Consulta Externa (CE): É uma transação que envia dados ou informações de controle para fora da aplicação. Sua principal intenção

 

 

55   é apresentar informações ao usuário pela simples recuperação de dados ou informações de controle de ALIs e/ou AIEs (consultas). Durante a realização o cálculo do tamanho funcional, cada função

possui

um

peso,

determinado

pela

complexidade

da

função.

Tal

complexidade é do tipo é determinada por dois parâmetros: quantidade de tipos de dados (campos) (TD) e quantidade de tipos de registros (TR) (subgrupos de dados dentro do arquivo). As funções do tipo transação têm sua complexidade determinada por outros parâmetros: quantidade de tipos de dados (TD) e quantidade de arquivos referenciados (AR). Para finalizar a contagem dos pontos de função do sistema, é utilizado o fator de ajuste, que tem como propósito medir requisitos gerais da aplicação (não funcionais).

5.1.2 Contagem de Pontos de Função Contagem dos tipos dados estão baseados nos atributos das classes persistentes da aplicação, e na contagem das funções do tipo transação, os TDs são acrescentados 2 (dois) a mais levando em consideração o comando e a mensagem de retorno. O cálculo dos pontos ajustados é dado pela seguinte fórmula: 𝑇𝑜𝑡𝑎𝑙  𝑃𝐹 = 𝑇𝑜𝑡𝑎𝑙  𝑇𝐷   + 𝑇𝑜𝑡𝑎𝑙  𝑇𝑇 ∗ (0,65   +  0,01 ∗ 𝑇𝑜𝑡𝑎𝑙  𝐴𝑗𝑢𝑠𝑡𝑒) A tabela a seguir foi utilizada como base para a contagem dos pontos de função.

 

 

56  

Figura 31 – Tabelas de Complexidade Funcional e Contribuição (VAZQUEZ, SIMÕES, ALBERT, 2010)

   

5.1.2.1 Tabela de Pontos de Função A tabela 21 descreve a contagem de pontos de função de funções do tipo dado. A tabela 22, descreve a contagem de funções do tipo transação. A tabela 23 descreve a contagem de fator de ajuste por fim, a figura 32 mostra o cálculo da dos pontos de função do sistema TiEspec.

Tabela 21 – PF – Contagem de Tipos de Dados

Arquivo

Tipo

TD

TR

Complexidade

Peso

Usuários

ALI

13

1

Baixa

7

Perfis

ALI

3

1

Baixa

7

Clientes de Portal

ALI

8

1

Baixa

7

Clientes de Projeto

ALI

Contatos

ALI

11

2

Baixa

7

Projetos

ALI

10

1

Baixa

7

ALI

12

3

Baixa

7

Artefatos Anexos Documentos

 

  Cenários Base Fluxos Base Ator Configuração de Descrição Estendida Planos

57  

ALI

5

2

Baixa

7

ALI

4

1

Baixa

7

ALI

14

1

Baixa

7

ALI

7

1

Baixa

7

ALI

29

4

Média

10

Descrições Estendidas Dados Cenários Fluxos Total TD

80

Tabela 22 – PF – Contagem de Tipo Transação

Função

Tipo

TD

AR

Complexidade

Peso

EE

8

2

Média

4

2 – Buscar Cliente de Portal

CE

4

1

Baixa

3

3 – Visualizar Cliente de Portal

CE

12

2

Média

4

4 – Cadastrar Cliente de Portal

EE

12

2

Média

4

5 – Editar Cliente de Portal

EE

12

2

Média

4

6 – Remover Cliente de Portal

EE

3

1

Baixa

3

EE

4

1

Baixa

3

CE

2

1

Baixa

3

9 – Filtrar Clientes de Portal

CE

6

1

Baixa

3

10 – Detalhar Cliente

CE

6

1

Baixa

3

11 – Aprovar Cliente de Portal

EE

3

1

Baixa

3

12 – Visualizar Usuário

CE

8

1

Baixa

3

13 – Cadastrar Usuário

EE

8

1

Baixa

3

14 – Combo Box Perfil

CE

2

1

Baixa

3

15 – Buscar Usuário

CE

6

1

Baixa

3

1 – Solicitar Cadastro Como Cliente No Portal

7 – Alterar Situação de Cliente de Portal 8 – Listar Clientes de Portal Pendente Aprovação

 

 

58  

16 – Editar Usuário

EE

8

1

Baixa

3

17 – Remover Usuário

EE

3

1

Baixa

3

18 – Alterar Situação de Usuário

EE

4

1

Baixa

3

19 – Listar Usuários Pendentes

CE

2

1

Baixa

3

20 – Filtrar Usuários

CE

6

1

Baixa

3

21 – Ativar Usuário

EE

3

1

Baixa

3

CE

18

3

Média

4

EE

18

3

Alta

6

24 – Cadastrar Cenário Base

EE

3

2

Baixa

3

25 – Buscar Cenário Base

CE

2

2

Baixa

3

26 – Visualizar Cenário Base

CE

2

2

Baixa

3

27 – Editar Cenário Base

EE

3

2

Baixa

3

28 – Remover Cenário Base

EE

3

2

Baixa

3

29 – Listar Ator

CE

2

1

Baixa

3

30 – Cadastrar Ator

EE

4

1

Baixa

3

31 – Filtrar Ator

CE

3

1

Baixa

3

32 – Editar Ator

EE

4

1

Baixa

3

33 – Remover Ator

EE

3

1

Baixa

3

34 – Cadastrar Cliente de Projeto

EE

9

2

Baixa

3

35 – Visualizar Cliente de Projeto

CE

9

2

Baixa

3

36 – Buscar Cliente de Projeto

EE

3

1

Baixa

3

37 – Editar Cliente de Projeto

EE

9

2

Baixa

3

38 – Remover Cliente de Projeto

EE

3

2

Baixa

3

EE

3

1

Baixa

3

40 – Cadastrar Projeto

EE

9

2

Baixa

3

41 – Buscar Projeto

CE

5

1

Baixa

3

42 – Editar Projeto

EE

9

2

Baixa

3

43 – Alterar Situação de Projeto

EE

4

1

Baixa

3

44 – Visualizar Artefatos do

CE

4

3

Baixa

3

22 – Visualizar Configuração de Descrições Estendidas 23 – Editar Configuração de Descrições Estendidas

39 – Alterar Situação de Cliente de Projeto

 

 

59  

Projeto 45 – Visualizar Descrições

CE

3

1

Baixa

3

46 – Cadastrar Artefato de Projeto

EE

13

3

Alta

6

47 – Buscar Artefato de Projeto

EE

3

3

Média

4

48 – Visualizar Artefato de Projeto

CE

11

3

Média

4

49 – Editar Artefato de Projeto

EE

13

3

Alta

6

50 – Excluir Artefato de Projeto

EE

3

3

Média

4

CE

30

6

Alta

6

CE

5

2

Baixa

3

EE

30

6

Alta

6

54 – Editar Descrição Estendida

EE

30

6

Alta

6

55 – Imprimir Descrição Estendida

SE

25

6

Alta

6

Estendidas do Projeto

51 – Visualizar Descrição Estendida 52 – Buscar Descrição Estendida 53 – Cadastrar Descrição Estendida

Total TT

190

Tabela 23 – PF – Fator de Ajuste

Fator de Ajuste

 

Pontuação

Comunicação de Dados

5

Funções Distribuídas

4

Desempenho

5

Utilização do Equipamento

1

Volume de Transações

3

Entrada de Dados On-Line

5

Interface com Usuário

5

Atualizações On-Line

3

Processamento Complexo

3

Reusabilidade

5

Facilidade de Implantação

4

Facilidade Operacional

4

Múltiplos Locais

4

 

60   Facilidade de Mudanças

4

Total Ajuste

55

  𝑇𝑜𝑡𝑎𝑙  𝑃𝐹 = 𝑇𝑜𝑡𝑎𝑙  𝑇𝐷 +  𝑇𝑜𝑡𝑎𝑙  𝑇 ∗ +(0,65 + 0,01 ∗ (𝑇𝑜𝑡𝑎𝑙  𝐴𝑗𝑢𝑠𝑡𝑒))   𝑇𝑜𝑡𝑎𝑙  𝑃𝐹 = 80 + 190 ∗ (0,65 + 0,01 ∗ 55  )   𝑇𝑜𝑡𝑎𝑙  𝑃𝐹 = 270 ∗ (0,65 + 0,55)   𝑇𝑜𝑡𝑎𝑙  𝑃𝐹 = 324   Figura 32 – Cálculo de Pontos de Função

5.1.3 Composição da Equipe de Desenvolvimento Será necessário a montagem de uma equipe de desenvolvimento para o projeto. A tabela a seguir, gerada a partir de informações providas por Susiléa Abreu dos Santos, gerente de projetos do Grupo Europa Empreendimentos e Negócios, mostra a produtividade e o custo de cada profissional envolvido no desenvolvimento.   Tabela 24 – Tabela de Produtividade de Profissionais de TI

Profissional

Quantidade

Produtividade

Custo

Gerente

1

-----

R$ 50,00 / h

Analista

1

4h / PF

R$ 35,00 / h

Desenvolvedor

1

2h / PF

R$ 25,00 / PF

Tester

1

1h / PF

R$ 15,00 / h

5.1.4 Mão de obra para o Desenvolvimento do Sistema Será adotada uma carga horária de trabalho de 8 horas por dia, 20 dias ao mês. O gerente é um caso a parte, pois irá trabalhar completo na primeira semana, e após isto apenas 20h/mês acompanhando o projeto. Para o cálculo do custo do projeto, será estimado um esforço de 55% para a fase de Análise, 35% para a fase de Desenvolvimento e 10% para a  

 

61  

fase de testes. O tempo gasto e os custos totais de cada fase estão descritos na tabela 26. Tabela 25 – Tempos e Custo de Desenvolvimento

Atividade

Profissional

Tempo Gasto

Gerência

Gerente

20 Dias

R$ 8.000,00

Analise

Analista

90 Dias

R$ 25.060,00

Desenvolvimento

Desenvolvedor

29 Dias

R$ 2.825,00

Testes

Tester

5 Dias

R$ 525,00

Total

Custo

R$ 36.410,00

5.1.5 Plano de Venda de Serviço Este software será disponibilizado como um serviço que poderá ser contratado por outras empresas. A ideia central é cobrar uma mensalidade sobre o uso do software. Esta forma de disponibilização de software é baseada no conceito de SaaS (Software As A Service). O SaaS é uma forma de distribuição e comercialização de software onde o fornecedor se responsabiliza por toda a estrutura necessária para a disponibilização do sistema (servidores, conectividade, cuidados com segurança da informação) e o cliente utiliza o software via internet, pagando um valor recorrente pelo uso. As características principais são a não aquisição das licenças (mas sim pagar pelo uso como um serviço) e a responsabilidade do fornecedor pela disponibilização do sistema em produção. O software a ser desenvolvido será disponibilizado nas modalidades descritas na tabela 27. Abaixo temos a legenda do significado e das diferenças entre planos: •

Número de Projetos Ativos: É a quantidade de projetos que poderão ser desenvolvidos ao mesmo tempo pela equipe.

•

Número de Usuários Ativos: Corresponde a quantidade de usuários que poderão estar ativos na ferramenta, podendo logar e disfrutar das funcionalidades.

 

 

62   •

Número de Descrições Por Projeto: É a quantidade máxima de Descrições de Caso de Uso que poderão ser mantidas para cada projeto.

•

Impressão de Descrições Por Projeto: Permite ao usuário realizar a impressão das descrições de caso de uso de todo um projeto com poucos iterações. Caso contrário, o usuário é obrigado a buscar cada funcionalidade e imprimi-las separadamente.

•

Valor: É o preço da mensalidade do uso do respectivo plano da ferramenta.

Tabela 26 – Disponibilização de Planos do Portal

Plano

Plano

Plano

Plano

Pessoal

Básico

Equipe

Empresarial

1

Até 3

Até 10

Até 20

2

Até 3

Até 10

Até 25

Até 5

Até 12

Até 20

Até 50

Não

Sim

Sim

Sim

Gratuito

R$ 45,00/Mês

R$ 80.00/Mês

R$ 200,00/Mês

Número de Projetos Ativos Número de Usuários Ativos Número de Descrições Por Projeto Impressão de Descrições Por Projeto Valor

Como não existe uma definição exata de quanto a ferramenta irá faturar, será utilizada uma situação hipotética de ganhos que está descrita na tabela 28.

Tabela 27 – Simulação de Faturamento do Portal

Período/ Plano Jan/2013

 

Pessoal

Básico

Equipe

2

1

1

Empresarial Faturamento/Mês 0

R$ 125,00

 

63  

Fev/2013

5

2

1

0

R$ 170,00

Mar/2013

10

3

2

0

R$ 295,00

Abr/2013

12

4

2

0

R$ 340,00

Mai/2013

20

6

3

1

R$ 710,00

Jun/2013

30

9

3

1

R$ 845,00

Jul/2013

43

10

4

1

R$ 970,00

Ago/2013

50

13

7

1

R$ 1.345,00

Set/2013

60

14

7

1

R$ 1.390,00

Out/2013

78

15

8

2

R$ 1.715,00

Nov/2013

90

16

9

2

R$ 1.840,00

Dez/2013

100

20

9

3

R$ 2.220,00

5.1.6 Primeira Proposta Tecnológica Trabalha com a aquisição de um servidor local, para instalação de base de dados e servidor web.

Tabela 28 – Descrição do Equipamento da Primeira Proposta Tecnológica (DELL,2012)

Descrição do Equipamento Servidor Dell PowerEdge T110II Processador Intel® Xeon® Quad-Core E3-1220 (3.10GHz, 8M Cache, Turbo/4T (80W) Memória de 2GB, 1333MHz (1X2GB UDIMM) Disco Rígido de 500GB SATA, 7.2K RPM, 3Gbps, cabeado, 3.5" Unidade de DVD Sem Sistema Operacional – A Instalar Distribuição Linux Placa de Rede On-Board Total: R$ 1.999,00

5.1.6.1 Custo Operacional   Os  custos  operacionais  relacionados  com  esta  proposta  estão  descritos  a   seguir:  

 

 

64   •

Registro de domínio público “www.tiespec.com.br” = R$ 30,00 / ano

•

Internet com serviço de IP dedicado: GVT R$ 150,00 / mês

•

Custos Diversos de Manutenção = 200,00 / mês

•

Custo Inicial de Configuração = R$ 150,00 Sendo a assim, o custo mensal é expresso pela seguinte fórmula:

𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 =  Custo Internet + Custo Domínio/12 + Custos Manutenção 𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 = 150,00 + 30,00/12 +  200,00   𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 = 𝑅𝑆  352,50

5.1.6.2 Custo de Investimento (CI)   𝐶𝐼 = 𝑇𝑜𝑡𝑎𝑙  𝐼𝑛𝑣𝑒𝑠𝑡𝑖𝑚𝑒𝑛𝑡𝑜 + 𝑇𝑜𝑡𝑎𝑙  𝑆𝑒𝑟𝑣𝑖𝑑𝑜𝑟 + 𝐶𝑢𝑠𝑡𝑜  𝐶𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑎çã𝑜   𝐶𝐼 = 36.410,00 + 1.999,00 +  150,00   𝐶𝐼 = 𝑅$  38.559,00    

5.1.6.3 Custo Total   𝐶𝑇 = 𝐶𝐼 + 𝐶𝑂 ∗ 𝑁ú𝑚𝑒𝑟𝑜  𝑑𝑒  𝑀𝑒𝑠𝑒𝑠   𝐶𝑇 = 38.559,00 + 352,50 ∗ 𝑁       Com base nos ganhos definidos na situação hipotética definida anteriormente, ao final do ano 2013, o saldo da empresa responsável pelo será de (R$ 30.864,00). É sim um saldo negativo, porém, já pagou parte do investimento inicial de R$ 38.559,00, e caso mantenha a perspectiva de crescimento, tende a se pagar completamente até no máximo, o ano de 2015.

5.1.7 Segunda Proposta Tecnológica Contratação de servidor web por meio de planos de computação nas nuvens.

Tabela 29 – Descrição do Serviço da Segunda Proposta Tecnológica (UNDER, 2012)

 

 

65  

Plano Cloud Under 1 Servidor com 1 Core de 2.4 Ghz 1 GB de RAM Hard Disk com 80 GB Banda Extrema de 3Mbps Transferência de 300 GB Linux CentOS 5.x (64 Bits) Valor: R$ 100,00 / mês

5.1.7.1 Custo Operacional   Os  custos  operacionais  relacionados  com  esta  proposta  estão  descritos  a   seguir:   • Registro de domínio público “www.tiespec.com.br” = R$ 30,00 / ano •

Plano Cloud Under 1 = 100,00 / mês

•

Custos Diversos de Manutenção = 100,00 / mês

•

Custo Configuração Inicial = R$ 150,00 Sendo a assim, o custo mensal é expresso pela seguinte fórmula:

𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 =  Custo Internet + Custo Domínio/12 + Custos Manutenção 𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 = 150,00 + 30,00/12 +  100,00   𝐶𝑂  𝑀𝑒𝑛𝑠𝑎𝑙 = 𝑅𝑆  252,50

5.1.7.2 Custo de Investimento (CI)   𝐶𝐼 = 𝑇𝑜𝑡𝑎𝑙  𝐼𝑛𝑣𝑒𝑠𝑡𝑖𝑚𝑒𝑛𝑡𝑜 + 𝐶𝑢𝑠𝑡𝑜  𝐶𝑜𝑛𝑓𝑖𝑔𝑢𝑟𝑎çã𝑜   𝐶𝐼 = 36.410,00 +  150,00   𝐶𝐼 = 𝑅$  36.560,00      

5.1.7.3 Custo Total  

𝐶𝑇 = 𝐶𝐼 + 𝐶𝑂 ∗ 𝑁ú𝑚𝑒𝑟𝑜  𝑑𝑒  𝑀𝑒𝑠𝑒𝑠   𝐶𝑇 = 36.560,00 + 252,50 ∗ 𝑁   Com base nos ganhos definidos na situação hipotética definida

anteriormente, ao final do ano 2013, o saldo da empresa responsável pelo

 

 

66  

será de (R$ 28.825,00). É sim um saldo negativo, porém, já pagou parte do investimento inicial de R$ 36.560,00, e caso mantenha a perspectiva de crescimento, tende a se pagar completamente até no máximo, o ano de 2015.

5.1.8 Proposta Escolhida   Com base nas propostas apresentadas, a escolha fica pela hospedagem do sistema no plano de computação nas nuvens. Os principais fatores que contribuíram com tal escolha foram: •

O investimento inicial é menor, e não teríamos que nos preocupar com renovação e manutenção da estrutura física dos equipamentos;

•

Segurança oferecida pelo plano de hospedagem, que agrega funcionalidades de gerenciamento e backups inclusas;

•

O nível de disponibilidade de serviço definido no contrato do plano de hospedagem nas nuvens garante que o serviço esteja no ar 99,5% do tempo.

•

Possibilidade de aumentar os recursos computacionais de acordo com a demanda de forma rápida e fácil, sem a necessidade de adquirir novos recursos de hardware.

•

 

Custos de manutenção menores.

 

67  

6 ESPECIFICAÇÃO DE PROJETO A fase de projeto é onde os envolvidos determinam como o sistema irá funcionar para atender aos requisitos levantados nas fases anteriores. Esta fase produz uma descrição computacional do que o software deve fazer e deve ser coerente coma descrição feita na análise (BEZERRA, 2007). Nas próximas páginas iremos definir a tecnologia, padrões de interface, melhorar artefatos gerados na fase de análise, definir a comunicação entre as camadas do software a ser construído, entre outros.

6.1

Escolha da Tecnologia Para o desenvolvimento do sistema será utilizada a linguagem de

programação Java, adotando padrões e tecnologias presentes na Arquitetura Java EE 6. Será adotado o Java Server Faces 2.0, junto com a biblioteca PrimeFaces. O PostgreSQL será o SGDB a ser utilizado. Para a construção e empacotamento do projeto, será utilizado o Maven. Para auxiliar no desenvolvimento, utilizaremos a IDE SpringSource Tool Suite. O servidor de aplicação escolhido para o projeto é o GlassFish. Nas próximas páginas as tecnologias utilizadas serão detalhadas.

6.1.1 Java   Java é uma linguagem de programação e uma plataforma de computação lançada pela primeira vez em 1995 pela Sun Microsystems, recém adquirida pela Oracle. A versatilidade, eficiência, portabilidade da plataforma e segurança da tecnologia Java, a tornam a tecnologia ideal para a computação de rede. De laptops a datacenters, consoles de games a supercomputadores científicos, telefones celulares à Internet, o Java está em todos os lugares (ORACLE, 2012). Alguns dados: •

 

1,1 bilhão de desktops executam Java.

 

68   •

930 milhões de download do Java Runtime Environment a cada ano.

•

3 bilhões de telefones celulares executam Java.

•

Telefones Java são lançados a cada ano em um número 31 vezes maior que a Apple e a Android juntas.

•

100% de Blu-ray players executam Java.

•

1,4 bilhões de Placas Java são fabricadas a cada ano.

•

Decodificadores

Java,

impressoras,

câmeras

Web,

games,

sistemas de navegação automotiva, casas lotéricas, dispositivos médicos, estações de pagamento de estacionamento e mais. Além dos pontos comentados, Java como um todo têm grande aceitação em diversos tamanhos de empresas, e em diversos segmentos. Java prove diversos recursos de

disponibilidade, confiabilidade,

escalabilidade e muitos outros.

6.1.2 Arquitetura Java EE 6 Java EE, ou Java Plataform Enterprise Edition é uma plataforma de programação para servidores na linguagem Java. Suas diferenças mais marcantes se comparada as outras versões do Java são a adição de bibliotecas que fornecem funcionalidades para implementar software Java distribuído, tolerante a falhasse multicamada, baseando-se em componentes modulares, e que executam em um servidor de aplicações (JAVA MAGAZINE, 2012). Esta plataforma contém uma séria de especificações ou containers, que proveem as mais diversas funcionalidades para a mesma. A seguir, na tabela 31, temos todas as tecnologias envolvidas na plataforma Java EE 6. Não faremos uso de todas as tecnológicas mencionadas, porém as que iremos utilizar serão comentadas nas páginas que estão por vir.   Tabela 30 – Lista de tecnologias Java EE 6 (JAVA MAGAZINE, 2012)

Tecnologia Bean Validation  

Versão 1.0

 

69  

Common Annotations for The Java Plataform Context And Dependency Injection for Java EE Plataform (CDI) EJB (Enterprise Java Beans) EL (Expression Language) Interceptors JACC(Java Authorization Service Provider Contract for Containers) JASPIC(Java Authorization Service Provider Interface for Containers) Java EE Deployment API Java EE Management API JavaMail JAX-RPC (Java API for XML based RPC) JAX-RS (Java API for RESTful Web Services) JAX-WS (Java API for XML Web Services) JAXB (Java Architecture for XML Binding) JAXR (Java API for XML Registries) JCA (Java EE Connector Architecture) JMS (Java Messaging Services) JPA (Java Persistence API) JSF (Java Server Faces) JSP (Java Server Pages) JSTL (Standard Tag Library for JavaServer Pages) JTA (Java Transaction API) Managed Beans Servlet Web Services Metadata for the Java Plataform

1.1 1.0 3.1 2.2 1.1 1.4 1.0 1.2 1.1 1.4 1.1 1.1 2.2 2.2 1.0 1.6 1.1 2.0 2.0 2.2 1.2 1.1 1.0 3.0 2.1

 

6.1.2.1 Enterprise JavaBeans (EJB) O EJB é uma plataforma para a construção de aplicações corporativas portável, reutilizável e escalável, que utiliza a linguagem Java. Desde seu inicio ele tem sido considerado um modelo de componente ou framework que permite que se construam aplicações corporativas com Java sem que seja necessário reinventar serviços comumente necessários, como gerenciadores de transação, componentes de segurança, serviços de mensagens, entre outros. (JAVA MAGAZINE, 2012) Do ponto de vista do desenvolvedor, um EJB é um pedaço de código Java que executa em um ambiente de tempo de execução especializado chamado container EJB, que fornece um número de componentes de serviços.

 

 

70   O Enterprise JavaBeans vem se aperfeiçoando nos últimos anos, e

depois de passar por algumas dificuldades e desconfianças, ganhou fôlego novamente e se encontra na versão 3.1.

6.1.2.2 Java Server Faces – JSF O Java Server Faces ou JSF, é um framework que permite a elaboração de interfaces de usuário web colocando componentes em um formulário e ligando-os a objetos Java permitindo a separação entre lógica entre as camadas envolvidas. Seu ponto forte é o grande número de componentes e um design muito flexível o que permitiu que este framework crescesse muito acomodando novas tecnologias (JAVA SERVER FACES, 2012). O JSF possui as seguintes partes: •

Um conjunto de componentes pré-fabricados de IU (interface de usuário)

•

Um modelo de programação orientado a eventos

•

Um modelo de componentes que permite a desenvolvedores independentes fornecerem componentes adicionais O JSF possui componentes simples como input e botões e outros

componentes sofisticados como tabelas de dados e árvores, porem o mais importante talvez seja o fato de integrar o padrão Java EE e estar incluído em cada servidor de aplicação Java EE, podendo facilmente ser adicionado a um container web. Os principais motivos que levaram o JSF ao sucesso provavelmente sejam: •

Ser parte da especificação Java EE desde as versão 5.

•

Ser um framework cuja a API foi pensada no trabalho dos desenvolvedores de IDEs.

•

Implementar o modelo MVC o que facilita o trabalho com outros frameworks encontrados no mercado.

 

•

Fazer parte da certificação OCWCD antiga SCWCD.

•

Possuir comunidades ativas em fóruns.

 

71   •

Exigir pouco conhecimento inicial para criação de interfaces de usuários tradicionais.

•

Possuir

ótimas

bibliotecas

de

componentes

livres

e

pagas

desenvolvidas por terceiros. •

Possuir Ajax nativo em sua versão 2.0.

6.1.2.3 PrimeFaces O PrimeFaces é uma suíte de código aberto de componentes para Java Server Faces que conta com mais de 100 componentes completos e de fácil utilização. Além do grande número de componentes, uma grande vantagem da suíte é que seus componentes utilizam Ajax nativo do JSF, o que permite desenvolver uma interface rica (PRIMEFACES, 2012). Seu uso é simples, feito pela importação de uma biblioteca no projeto Java, não requerendo nenhuma configuração adicional nem outras dependências.

6.1.2.4 JSP/Servlets O JSP é a abreviação de Java Server Pages, que em português seria algo como Páginas de Servidor Java. É uma tecnologia para criar páginas web com programação em Java. As páginas JSP estão compostas de código HTML/XML misturado com etiquetas especiais para programar scripts de servidor em sintaxe Java (ORACLE, 2012). O Servlet é um componente que funciona como um servidor, e que gera dados em HTML/XML. Basicamente, é uma classe Java que processa as requisições e envia respostas.

6.1.2.5 Java Persistence API e Hibernate

 

 

72   O Java Persistence API, comumente chamado de JPA, é uma API

padrão do Java para a persistência, que deve ser implementada por qualquer framework que queira seguir este padrão. Ele é utilizado na camada de persistência da aplicação, e visa abstrair o uso da linguagem SQL, oferecendo métodos que deixem este procedimento mais simples e fácil. Ele define um meio de ORM (Mapeamento Objeto/Relacional) para os objetos POJOs. Atualmente, está em sua versão 2.0. Neste

projeto,

utilizaremos

o

framework

Hibernate

como

implementação do JPA. O Hibernate foi criado em 2001, inicialmente por Gavin King, e, liderados por ele, foi construído pela comunidade de desenvolvedores Java ao redor do mundo, tanto que, atualmente o framework é distribuído sobre a licença de software livre LGPL 2.1 (HIBERNATE, 2012). Algum período após sua criação, a Jboss Inc. (Ramo de desenvolvimento da gigante Red Hat). Atualmente, está em sua versão 4.1.16. Sua principal função é a de diminuir a complexidade entre os programas que precisam trabalhar com um banco de dados do modelo relacional. Com o uso desta tecnologia, não é necessário escrever comando SQL diretamente, pois o framework faz esta transformação para o programador, liberando o trabalho extra de ficar convertendo SQL para objetos e vice-versa.

6.1.3 Servidor de Aplicação Um servidor de aplicação, também chamado de middleware, é uma plataforma sobre a qual é provido um ambiente para a instalação e execução de

outras

aplicações,

dispensando

a

instalação

do

aplicativo

nos

computadores clientes. Seu principal objetivo é prover uma plataforma que separe o desenvolvedor de complexidades desnecessárias e recorrentes, como por exemplo os diversos sistemas operacionais. Além disso, é no servidor de aplicação que geralmente são implementadas questões comuns a diferentes

 

 

73  

aplicações, como segurança, garantia de disponibilidade, balanceamento de carga, tratamento de exceções e outras. Neste projeto, utilizaremos o GlassFish v3. Ele foi criado pela Sum Microsystems (adquirida pela Oracle em meados de 2010), no ano de 2006. Ele foi o primeiro servidor de aplicação a implementar completamente o especificação da Arquitetura Java EE 6, e com este e outros motivos como tempo de inicialização rápido, modularização, suporte de clusterização e balanceamento de carga foi rapidamente adotado pela comunidade (GLASSFISH, 2012) Atualmente, está em sua versão 3.1.2, e é esta que iremos utilizar.

6.1.4 Maven O Apache Maven é uma ferramenta para gerenciamento e automação de projetos em Java e possui um modelo de configuração simples, baseado em XML. Ele foi construído focando em desenvolvimento e configuração em rede. (APACHE MAVEN, 2012) Utiliza um arquivo chamado Project Object Model (POM), que descreve todo o processo de construção do software, suas dependências entre módulos, sequência de construção, entre outros. Grande parte das suas funcionalidades já são pré-definidas e realizam tarefas bastante utilizadas, como compilação de código e empacotamento de projeto. No Maven, existem os chamados repositórios, que podem ser acessados pela internet, intranet, ou serem locais. Um repositório Maven é uma estrutura que armazena outros projetos, também disponibilizados via Maven, de bibliotecas ou módulos que poderão ser utilizados em alguma outra aplicação. Em um processo de construção ou empacotamento de um software, é o Maven que irá se preocupar em buscar as dependências corretas do nosso projeto, colocando-as onde foi definido de forma automática e de fácil manutenção. Podemos definir também que certas bibliotecas serão utilizadas apenas em alguns momentos durante o processo, como por exemplo, apenas na fase de testes.

 

 

74   Para utilizar o Maven em seu projeto, basta criar um projeto Maven

pela sua IDE, e ele já virá com a estrutura base do Maven, além do arquivo de configuração pom.xml. Também podemos criar projetos Maven utilizando a linha de comando dos diversos sistemas operacionais, bastado apenas fazer o download da ferramenta e configurarmos as variáveis de ambiente. O Maven está em sua versão 3.0.4, porém, por motivos de estabilidade, utilizaremos a versão 2.2.1.

6.1.5 PostgreSQL O PostgreSQL é um sistema gerenciador de banco de dados objeto relacional muito poderoso, desenvolvido em código aberto, que possui confiabilidade, exatidão, é altamente escalável e é considerado um dos mais avançados na comunidade de software livre. Possui interfaces nativas de programação para C/C++, Java, .Net, Perl, Python, Ruby, ODBC, entre outros, além de uma documentação bem completa (POSTGRESQL, 2012). Sua versão atual é a 9.2.1. Porém, utilizaremos a versão 9.1.6 por estar mais estável e com menos bugs conhecidos.

6.1.6 Spring Tool Suite Também conhecido como STS, é um ambiente de desenvolvimento integrado (IDE) baseado no conhecido Eclipse. Ele é mantido e disponibilizado pela SpringSource, que é uma divisão de pesquisas e desenvolvimento da VmWare. Seu foco é o desenvolvimento de aplicações empresariais, e já vem com integração com várias tecnologias bastante úteis neste processo, como exploradores de base de dados,

integração com

servidores de aplicação, ferramentas de fatoração e geração de código, integração

com

softwares

(SPRINGSOURCE, 2012).

 

de

controle

de

versão,

entre

outros

 

75   Assim como o Eclipse, ele possui uma infinidade de plug-ins, que

permite ao desenvolvedor, de forma rápida e fácil, adicionar o suporte a outras tecnologias. A versão que será utilizada para o desenvolvimento será 3.1.0, que é baseada no Eclipse Juno (4.2). A escolha de tal tecnologia se dá pura e simplesmente pela familiaridade com a ferramenta.

6.1.7 Controle de Versões Durante o desenvolvimento da aplicação, será importante manter os códigos da aplicação sempre atualizados, garantido que seja possível voltar a versões antigas de um arquivo, fazer junção entre arquivos que foram editados por desenvolvedores diferentes, entre outros. Para prover tais funcionalidades, foi utilizada a ferramenta de controle de versões, chamada SubVersion. O SubVersion, ou SVN, é um projeto gerenciado pela conhecida Apache, desenhado especificamente para ser um substituto moderno do CVS, outro software de gerenciamento de versões (SUBVERSION, 2012). Sua versão estável atual é a 1.7.6. O projeto será hospedado em um serviço gratuito provido pelo Google, chamado de Google Code, que nos permite criar repositórios SVN e acessá-los de qualquer lugar que possui conexão com a Internet. Outra facilidade é a integração com a IDE Spring Tool Suite, a qual iremos utilizar.

6.1.8 Apache HTTP Server Comumente conhecido como Apache, ele é o mais bem sucedido servidor web existente. O servidor é compatível com o protocolo HTTP, e é disponibilizado para diversos sistemas operacionais, com Windows, Linux, MacOS, Unix, entre outros. O apache é um software livre, o que permite a

 

 

76  

qualquer um visualizar, estudar ou alterar seu código fonte gratuitamente. (APACHE, 2012) O servidor Apache será o software responsável por disponibilizar as páginas e os demais recursos que algum cliente acessar por meio de um browser. Assim, quando o cliente acessa um site, requisições são feitas por meio do protocolo HTTP ao servidor Apache, que recebe a requisição e posteriormente envia a resposta.

6.2

Padrões de Projeto e Outras Técnicas Visando aproveitar os benefícios da linguagem de programação

orientada a objetos Java, explicaremos alguns padrões e técnicas que serão utilizados no projeto.

6.2.1 Plain Old Java Object Também conhecido pelo acrônimo POJO, ele se define por ser um objeto na linguagem de programação Java que contém apenas seus atributos, construtores, getters e setters. Outra característica importante dos POJOs é que não implementam ou estendem nenhum tipo de método de outro framework. Seu objetivo principal é ser um objeto leve, sem regras de negócio atreladas, o que o permite transitar por todas as camadas da aplicação sem que seja necessário um grande uso de recursos.

6.2.2 Suporte a Internacionalização O framework Java Server Faces permite a construção de sistemas com internacionalização de idiomas. O sistema a ser desenvolvido deverá prover a possibilidade rápida de se modificar o idioma. Não será necessário

 

 

77  

por enquanto, implementar ou disponibilizar a aplicação em outro idioma. Porém deverão ser tomados todos os cuidados para que, caso seja necessário, o esforço para esta mudança seja pequeno e rápido.

6.3

Arquitetura do Sistema A partir deste ponto, iremos observar como o sistema será subdividido

física e logicamente.

Além disso, poderemos ver como o sistema será

construído e como as camadas que surgiram vão interagir entre si para que as funcionalidades do portal sejam executadas.

6.3.1 Diagrama de Pacotes O diagrama de pacotes mostra a decomposição do próprio modelo em unidades organizacionais e suas dependências (BOOCH, 2005). É no diagrama de pacotes que podemos visualizar os pacotes envolvidos na construção do software como um todo, e a dependência entre eles. A utilização desta divisão visa agrupa-los em conjuntos gerenciáveis, organizados por suas responsabilidades e coerência com o negócio. No sistema em questão, foram separados os seguintes pacotes: •

Utilidades: abrange todas as funcionalidades que serão necessárias para o bom funcionamento do sistema, como funcionalidades de envio de e-mail, configuração de base de dados, entre outras.

•

Suporte: engloba todas as funcionalidades que darão base e proverão dados para que o pacote de Especificações possa ter seus casos de uso executados. Entre as funcionalidades aqui presentes podemos citar a manutenção de Clientes de Projeto, Projetos, Artefatos, entre outros.

•

Cadastro: representa e engloba todas as funcionalidades necessárias para que os usuários e clientes possam se cadastrar no sistema, ser aprovados, e efetivamente utilizar o portal.

 

 

78   •

Especificação: representa as funcionalidades onde o usuário vai realmente construir as especificações de caso de uso, criando atores, cenários base, especificações, e também imprimindo as descrições criadas. Na figura 33 temos a visão do sistema, apresentado através do

diagrama de pacotes.

  Figura 33 – Diagrama de Pacotes Revisado

   

6.3.2 Divisão em Camadas Os subsistemas que serão construídos serão divididos em camadas, cada uma com um conjunto específico de responsabilidades: •

(DP) Camada Domínio do Problema: Nesta camada definidos os objetos de negócio e tratadas as regras de negócio.

•

(GT) Camada Gerência de Tarefas: A camada de GT é a responsável por direcionar o fluxo da aplicação, servindo como intermédio entre a camada de interface ao usuário para com as demais camadas.

 

 

79   •

(GD) Camada Gerência de Dados: Esta é a camada responsável por persistir e recuperar os dados que são manipulados pela aplicação. Todo e qualquer acesso a dados deve passar por esta camada.

•

(IU) Camada Interface ao Usuário: É a camada que engloba as interfaces de iteração Humano x Máquina, e que direciona os dados e eventos enviados a ela para a GT realizar o processamento e encaminhamento das mesmas.

A figura 34 representa a divisão de camadas do subsistema de Especificação, o qual será construído.

  Figura 34 – Divisão de Camadas

  Falando em termos de codificação, a divisão dos pacotes dentro do subsistema de especificação pode ser observada na figura 35. Os pacotes internos a cada camada serão comentados nas próximas páginas, onde iremos falar separadamente de cada uma delas.  

 

 

80  

  Figura 35 – Divisão de Camadas e o Relacionamento com Pacotes de Programação

6.3.3 Camada Domínio do Problema A camada de Domínio do Problema é a responsável pelo tratamento das regras do negócio. Na arquitetura que estamos utilizando, esta camada é composta por 4 pacotes, descritos a seguir: •

Pacote Enum: Abreviação de Enumerable, que é um tipo de classe Java que representa uma estrutura de dados numerada e constante. Engloba as classes de situação que um objeto pode assumir durante seu ciclo de vida.

•

Pacote Modelo: Neste pacote existem os objetos Java que mapeiam as entidades que serão trabalhadas na aplicação. Estas entidades utilizam o conceito de POJO, descrito anteriormente, e são nestas classes que definimos os relacionamentos entre os objetos além de servirem de mapeamento para base de dados. O objetivo de utilizar POJO é montar um objeto leve, que possa transitar entre as camadas da

 

 

81   aplicação

sem

utilizar

grandes

recursos

de

memória

processamento. •

Pacote EJB: Neste pacote estão as classes que implementam as regras do negócio. Este pacote é o único que conhece o pacote DAO. Ele solicita os dados persistentes a esta camada e repassa a camada de GT. As classes de negócio aqui existentes devem, obrigatoriamente, implementar uma interface do pacote EJBInterface.

•

Pacote EJBInterface: Este pacote engloba as interfaces que são implementadas pelo pacote EJB. Uma interface funciona como contrato entre o objeto chamador e o objeto que implementa a interface. O uso de interface é recomendado na plataforma Java EE para diminuir o acoplamento e permitir a rastreabilidade de erros de forma fácil. No caso, o objeto chamador

não

precisa

conhecer

detalhes

do

método

implementado, e faz a chamada para um componente semelhante a uma caixa preta. As imagens a seguir representam os diagramas de classes desta camada. A classe Entidade, presente na figura 37, foi utilizada para centralizar a definição de atributos comuns a todas as classes persistentes. Sendo assim todas as classes persistentes devem estender esta classe, garantindo a criação de atributos como a chave primária e a definição do atributo de controle de versão. As figuras 36 e 37 representam o pacote Modelo, e a figura 38 representa o pacote EJB.

 

 

82  

  Figura 36 – Domínio do Problema – Modelo – Parte I

 

 

83  

  Figura 37 – Domínio do Problema – Modelo – Parte II

 

 

84  

Figura 38 – Domínio do Problema – EJB

 

 

 

85  

 

6.3.4 Camada Gerência de Tarefas A gerência de tarefas é a camada responsável por controlar o fluxo de dados da aplicação, recebendo os dados vindos da camada de interface ao usuário e direcionando o fluxo da aplicação para que as funções possam ser executadas. Esta camada é composta por um único pacote, descrito a seguir: •

Pacote ManagedBean: É neste pacote que estarão presentes as classes que irão receber os estímulos da interface ao usuário direcionar o fluxo para as demais camadas da aplicação.

  Figura 39 – Gerência de Tarefas – Managed Bean

A classe ContextoBean, que pode ser observada na figura 39, representa a classe onde serão armazenados os dados de sessão do usuário. No caso, é nesta classe que serão armazenados o usuário logado, o cliente o qual o usuário pertence, o plano corrente e outros.  

6.3.5 Camada Gerência de Dados

 

 

86   A camada de gerência de dados é a responsável por fazer o

intermédio entre a aplicação e o banco de dados no qual serão persistidas as informações de negócio. A camada de negócio (Domínio do Problema), sempre que precisar criar, alterar ou recuperar dados persistentes, solicitará a esta camada, que será responsável por executar as ações solicitadas. Com a utilização desta camada, a troca de um banco de dados, por exemplo, idealmente não deve causar alterações nas demais camadas da aplicação. As figuras 40 e 41 representam as classes envolvidas na camada de gerência de dados. A classe ‘DAO’, representa uma classe estendida por todas as classes que precisam fazer acesso a dados. Assim, as classes filhas herdam os métodos genéricos que possibilitam a conexão com a base de dados e a execução de métodos de CRUD (criação, alteração, leitura e exclusão) de dados. Os tipos de manipulações que fogem aos padrões CRUD deverão ser implementados em cada classe filha.

 

 

87  

  Figura 40 – Gerência de Dados – Camada DAO – Parte I

 

 

88  

Figura 41 – Gerência de Dados – Camada DAO – Parte II

 

6.3.6 Dicionário de Dados do Diagrama Gerência de Dados As classes e atributos que deveriam estar definidas aqui já foram comentadas no capítulo 4, pois não houve nenhuma alteração com relação a gerência de dados.

6.3.7 Diagrama Relacional O modelo relacional se fundamenta no conceito de ralação. De forma bastante simplista, pode-se pensar em uma relação como uma tabela, composta de linhas e colinas, onde cada relação possui um nome. O diagrama relacional é a representação das tabelas que serão geradas no sistema gerenciador de base de dados (SGDB), os atributos criados, e os  

 

89  

relacionamentos entre estas tabelas (BEZERRA, 2007). A figura 42 representa o diagrama relacional do sistema TiEspec.

Figura 42 – Diagrama Relacional

 

 

 

90  

6.3.8 Dicionário de Dados do Diagrama Relacional A maioria dos atributos que aqui deveriam estar presentes já foram definidos no diagrama de classes e no dicionário de dados, no capítulo 4. A única alteração está descrita na tabela 31. Tabela 31 – Dicionário de Dados – Tabela de Relacionamento Ator x Descrição Estendida Campo

Edit.

Obr.

S

S

ator_id

Formato PK

Regra/Descrição Chave estrangeira apontado para a tabela Ator Chave estrangeira apontado

descricao_id

S

S

PK

para

a

tabela

Descrição

Estendida

6.3.9 Camada de Interface ao Usuário A camada de interface ao usuário representa a fronteira entre a aplicação e o usuário utilizador do portal. Esta camada irá receber os estímulos oriundos desta iteração e irá direcionar as requisições para a gerencia de tarefas, que prosseguirá com o processamento. Esta camada não possui diagramas de classes. Os elementos responsável por prover a interface são arquivos do tipo HTML, Java Script e CSS. As páginas HTML, por meio de formulários, enviam as requisições ao ManagedBean, componente da Gerência de Tarefas. Visando construir uma interface amigável, de fácil aprendizado, foram definidos padrões a serem seguidos.

6.3.9.1 Grids Base Para construir telas que possam ser facilmente redimensionadas, serão utilizados grids base, por meio do uso de CSS, para definir o tamanho dos campos de texto, das áreas da tela e das mensagens. O uso de grid também ajuda ao programador a posicionar dos elementos na tela.

 

 

91   •

Grid 960 (24): Representado pela figura 43, e o grid principal onde serão montadas as telas. Ele deve ter 960 pixels, dividido em 24 colunas de 40 pixels cada.

•

Grid 486 (18): Este grid deverá ser utilizado para criar diálogos de busca, diálogos de operação como criação e edição de objetos. É dividido em 18

colunas de 27 pixels cada. É

visualizado na figura 44. •

Grid 432 (16): Também utilizado em diálogos, servirá como base para diálogos de informação e confirmação de ações, como exclusão, ativação, entre outros. É dividido em 16 colunas de 27 pixels cada. Pode ser visto na figura 45.

•

Classes CSS Width: Deve ser composta por 24 estilos CSS. Cada um deste deve ter 40 pixels de diferença entre seu antecessor. O prefixo para uso do estilo é “grid_”. Assim, caso o programador necessite de definir um campo com 400 pixels, ele irá usar o “grid_10”, se necessitar de um campo com 440 pixels, ele utilizará o “grid_11”, e assim sucessivamente. Está apresentado na figura 46.

•

Classes CSS Dialog_Width: Apresentado na figura 47, funciona de forma análoga ás Classes CSS Width, porém serão utilizadas para montar a interface dos diálogos da aplicação. São compostos por 18 estilos, cada um com 27 pixels a mais que seu anterior.

As imagens a seguir representam os grids e classes de CSS.

Figura 43 – Grid 960 (24)

 

 

 

 

92  

 

Figura 44 – Grid 486 (18)

 

Figura 45 – Grid 432 (16)

Figura 46 – Classe CSS Width

 

 

 

 

 

93  

Figura 47 – Classe CSS Dialog_Width

 

 

6.3.9.2 Ícones, Botões e Mensagens Visando construir um sistema homogêneo, seguindo padrões e telas bem definidas, iremos utilizar um grupo de ícones que ajudem ao usuário a identificar a ação que ele irá executar. A tabela 31 descreve os ícones disponíveis. Tabela 32 – Ícones Utilizados

Função Buscar ou Filtrar Adicionar/Incluir ou Novo Salvar Cancelar ou Desistir Fechar Excluir ou Remover Ajuda Ordenação de Paginação

 

Ícone Ativo

Ícone Desativado

 

94  

Descendente Ordenação de Paginação Ascendente Coluna Não Ordenada Imprimir Início Ativar ou Habilitar Ações

As mensagens que serão exibidas ao usuário também seguirão padrões no que se diz respeito a interface. Na figura 48 podem ser observadas, respectivamente, as mensagens para aviso, erro e sucesso.

  Figura 48 – Exemplo de Mensagens ao Usuário

  Sobre o texto das mensagens sobre status de ações, devem ser montadas conforme o seguinte padrão: •

Mensagens de Sucesso: O registro {0} foi {1} com sucesso! o {0} = Chave Candidata (Campo que identifica o objeto e que seja de fácil entendimento ao usuário. Caso não exista nenhuma possível chave candidata, usar a chave primária do registro). o {1} = Referente a ação (criado, alterado, excluído, etc.).

•

Mensagens de Falha: Ocorreu um erro ao {0} o registro {1}! o {0} = Referente a ação (criar, alterar, excluir, etc.). o {1} = Chave Candidata (Campo que identifica o objeto e que seja de fácil entendimento ao usuário. Caso não exista nenhuma possível chave candidata, usar a chave primária do registro).

 

 

95  

6.3.9.3 Componentes

JSF

e

PrimeFaces

utilizados

na

Interface Os botões a serem utilizados deverão ter, além de seu nome, um ícone para identificar o tipo de ação que está sendo realizada, conforme exemplos na figura 49.     Figura 49 – Exemplo de Botões

O JSF 2.0, juntamente com o PrimeFaces, possui uma grande quantidade de componentes para serem utilizados na construção de interfaces. A tabela 34 descreve os componentes que serão utilizados: Tabela 33 – Componentes do JSF e do PrimeFaces Utilizados

Nome

Descrição

ajax

Componente não visual que adiciona funcionalidades AJAX a um componente que não possui tais funcionalidades. Disponível tanto na biblioteca do JSF quanto na do PrimeFaces

blockUI

Componente que exibe uma sombra que não permite ao usuário executar ações em um determinado espaço na tela.

calendar

Elemento de exibição de um calendário.

column

Elemento

que

criar

colunas

dentro

de

outros

componentes, como é o caso do dataTable. commandButton

É o botão padrão utilizado na aplicação. Pode ser utilizado tanto para abrir diálogos, quanto fazer requisições com ou em Ajax.

contextMenu

É um menu que é exibido por meio do clique com o botão direito do mouse.

dataTable

 

É o componente de exibição de registros mis utilizado.

 

96   Ele suporta carregamento sob demanda, seleção de registros de forma única e múltipla, entre outros.

dialog

Funciona como um diálogo que salta na tela para o usuário. É utilizado para diversos fins, como buscas, operações CRUD, entre outros.

editor

É um componente que permite ao usuário escrever textos com o uso de HTML e CSS, ou seja, um editor de texto que permite formatações diversas

fileUpload

Componente utilizado para que seja possível que o usuário envie arquivos de diversos tipos para o site.

form

É um formulário HTML, que quando acionado envia os valores dos campos de entrada de dados internos a ele ao servidor.

inputText

Uma caixa de inserção de texto com apenas uma linha

inputTextarea

Uma caixa de inserção de texto com várias linhas

inputMask

Uma caixa de inserção de texto que permite que seja configurada máscaras específicas de entrada de dados

menu

Componente de criação de menus na aplicação, podendo ser horizontal ou vertical.

messages

Componente que exibe mensagens de informação, avisos ou erros na tela. Ele como se fosse um banner.

menuButton

Botão semelhante ao commandButton, porém que é utilizado dentro do componente menu

password

Caixa de inserção de texto. Ele exibe os caracteres digitados de forma escondida. É utilizado quando o usuário precisa inserir senhas

radioButton

Botão de seleção única entre duas ou mais opções.

selectOneListBox

É um componente de seleção de um valor entre vários que possam ser exibidos na lista. Possui um botão que ao ser acionado exibe os possíveis valores a serem selecionados

separator

 

É uma linha horizontal que recebe características do

 

97   tema que está sendo utilizado.

splitButton

Botão composto por dois botões, um com função igual ao commandButton e o outro funciona como um menu que é exibido quando o botão é acionado. Este menu contém outras ações que podem ser executadas.

tab

É um componente que integra a tabView. É utilizada para agrupar informações de um mesmo contexto.

tabView

É um componente que permite que sejam construídas páginas que se sobrepõem, e que são exibidas ou não dado o acionamento de uma tab.

6.3.9.4 Exemplos de Telas do Sistema As figuras 50 a 55 representam a interface de algumas das funcionalidades do sistema.

  Figura 50 – Tela de Visualização de Atores Cadastrados

  Figura 51 – Diálogo de Criação de Atores

 

 

98  

  Figura 52 – Diálogo de Busca de Atores

  Figura 53 – Tela de Visualização de Descrição Estendida – Aba Dados Básicos

 

 

99  

  Figura 54 – Tela de Visualização de Descrição Estendida – Aba Tipos de Dados

  Figura 55 – Diálogo de Busca de Clientes de Portal

6.3.10

Diagramas de Sequência Revisados

  Foi necessário, durante a fase de projeto, refinar os diagramas de sequência para que pudessem incorporar e exibir corretamente a troca de mensagens entre as camadas da aplicação, durante a execução de alguma funcionalidade de software. A seguir, nas figuras de 56 a 62, temos os diagramas de sequência do pacote que fora prototipado, englobando as

 

 

100  

funcionalidades de Manutenção de Atores, Manutenção de Cenários Base, Manutenção de Descrições Estendidas e, por fim, a Impressão de Descrições Estendidas.

  Figura 56 – DS Revisado – Cadastrar Ator

  Figura 57 – DS Revisado – Atualizar Ator

  Figura 58 – DS Revisado – Listar Atores

  Figura 59 – DS Revisado – Excluir Ator

 

 

 

101  

Figura 60 – DS Revisado – Buscar Projeto Pré-Impressão

 

 

Figura 61 – DS Revisado – Imprimir Descrição Estendida

 

 

Figura 62 – DS Revisado – Cadastrar Dado

   

6.3.11

Estrutura do Projeto

  A organização física do código fonte e como os projetos irão se comunicar pode ser observada na figura 63. 1. Projeto EAR: Este é efetivamente o projeto que irá gerar o arquivo final para implantação no servidor de aplicação. Ele é o responsável por juntar os outros projetos e prover ao sistema as bibliotecas compartilhadas. O arquivo empacotado por este projeto é gerado com a extensão ‘.ear’. 2. Projeto Web: Este projeto engloba o que representaria a camada de interface ao usuário e a gerência de tarefas. Ele que irá receber as  

 

 

102   requisições, e irá fazer chamadas ao projeto EJB para que as regras de negócio sejam processadas. Neste projeto estarão presentes tecnologias como o Java Server Faces, PrimeFaces, JSPs, Servlets, e os Managed Beans. 3. Projeto EJB: O projeto EJB é onde serão tratadas efetivamente as regras de negócio. Cada classe presente neste projeto terá. É neste projeto que teremos a implementação da camada DAO. 4. Projeto Model: Este projeto possui o pacote de modelo de dados, que descreve as classes de negócio implementadas como POJO.

 

Figura 63 – Organização dos Módulos de Empacotamento na Visão de Codificação

   

6.3.12

Diagrama de Implantação

Segundo

a

UML,

o

diagrama

de

implantação

representa

a

configuração e a arquitetura do sistema em que estarão ligados os respectivos componentes. As figuras 64 e 65 representam o diagrama de implantação do sistema TiEspec.

 

 

103  

  Figura 64 – Diagrama de Implantação

 

  Figura 65 – Diagrama de Implantação com UML

 

 

104  

7 POLÍTICAS DE SEGURANÇA Nos sistemas atuais, principalmente aqueles que são disponibilizados por meio da internet, é imprescindível que sejam implementadas soluções que garantam a segurança dos dados manipulados. Assim também, não deve se focar apenas na segurança, mas também na confiabilidade, integridade e disponibilidade dos dados. Visando garantir que tais requisitos sejam atendidos, foram definidas as seguintes estratégias, políticas e mecanismos: •

Autenticação de Usuários e Controle de Acesso: Algumas funcionalidades do sistema só poderão ser acessadas por usuários registrados, logados na aplicação e que possuam acesso a mesma. Assim, deverá ser implementado um mecanismo de login e de controle de acesso as funcionalidades presentes. A definição de quem acessa o que está definida no Diagrama de Casos de Uso e nas Descrições Estendidas.

•

Uso

de

Algoritmos

de

Resumo

de

Mensagem

Para

Armazenamento de Senhas do Usuário: Visando a segurança dos dados dos usuários que utilizam a aplicação, as senhas do usuário deverão ser persistidas apenas depois que passarem por um mecanismo de resumo de mensagens. Este mecanismo gera um texto baseado na senha do usuário. Para uma mesma senha o mecanismo sempre gera um mesmo resumo (Hash). Assim a aplicação não precisará persistir a senha em texto plano. •

Politicas de Backup: Os backups de dados são de extrema importância caso ocorram incidentes de segurança que prejudiquem os dados da aplicação. Por isso, será necessária a configuração e execução de rotinas de backup dos dados. Iremos trabalhar com dois tipos de procedimentos. Um deles deverá ocorrer diariamente, sempre ás 03:00 (3 Horas) e deverá salvar uma cópia do banco de dados da aplicação no próprio servidor onde se encontra a base de dados, se limitando a salvar 35 backups diários. Quando atingir este número, o backup diário de data mais antigo deverá ser excluído. O

 

 

105   outro procedimento é um backup mensal, que ocorrerá no primeiro dia de cada mês, ás 04:00 (4 Horas) e deverá ser mantido, limitandose a guardar informações de até 24 meses. Todos os backups deverão ser guardados no próprio servidor e ainda em um local físico, que será na sede da empresa. Quando um backup é efetuado no servidor, uma cópia dele deve, em no máximo 2 dias, ser movido para o arquivo de backups na sede da empresa. •

Mascarar URL de acesso a aplicação: Muitos dos ataques a sistemas que ocorrem na internet utilizam da URL do sistema para conseguir dados e/ou deixar o sistema indisponível. Para minimizar esta tipo de ataque, será utilizado um elemento da linguagem HTML, o IFrame. Ele é capaz de fazer com que determinada página seja aberta dentro de outra página. Assim, o usuário verá sempre em seu navegador, o caminho www.tiespec.com.br, enquanto isso vai estar na verdade navegando pelos diversos caminhos da aplicação. É importante lembrar que esta técnica é facilmente burlada, porém, em conjunto com outras tecnologias e técnicas se torna um recurso de segurança a mais.

•

Controle de limites de utilização conforme os planos de um cliente: Conforme foi discutido, a aplicação deve limitar as ações e limites de uso de acordo com o plano associado ao usuário por meio do relacionamento com Cliente de Portal. Este bloqueio será feito de forma HardCoded, ou seja, o bloqueio será feito na própria programação das funcionalidades. Esta abordagem é considerada um anti-padrão de programação, porém, no momento, é a solução mais viável para o desenvolvimento do projeto.

 

 

106  

8 CONCLUSÃO O crescimento ocasionado pelo avanço da tecnologia está gerando demandas de construção de novos e modernos sistemas de informação. Esta grande demanda, juntamente com o aumento da complexidade dos sistemas a serem criados, nos inspira a buscar melhorias nos processos de construção de software. O TiEspec se insere neste ambiente, com o objetivo de melhorar o processo de especificação de descrições de caso de uso, provendo aos profissionais responsáveis por esta demanda, meios realizar o processo de forma fácil. Ao fim do período do projeto, não foi possível atingir todos os objetivos que eram esperados. O objetivo principal, de automatizar a criação e manutenção de descrições de caso de uso de software foi concluído com sucesso. O TiEspec também pode ser acessado por meio da internet, e possui funcionalidades implementadas que permitem ao usuário reutilizar cenários de caso de uso. Infelizmente, não foi possível coletar o feedback dos usuários, pois a ferramenta não entrou em produção por completo. Como trabalhos futuros, serão desenvolvidos os demais pacotes do projeto, para que a ferramenta esteja concluída e possa, enfim, entrar em produção. Além disso, já existem propostas de melhorias que podem agregar valor ao sistema: •

Prover funcionalidades de gerência para controlar os prazos, produtividade e situação das demandas que são geradas no portal;

•

Adicionar o módulo de segurança que permita ao administrador do portal gerenciar com granularidade baixa o que cada perfil de usuário pode fazer na aplicação, de forma dinâmica, confiável e segura.

•

Integrar a ferramenta com outras soluções existentes. Um caso é a integração da funcionalidade de manutenção de artefatos do projeto com ferramentas como DropBox, Google Drive e Microsoft SkyDrive.

•

Permitir a impressão dos relatórios em templates personalizados e que cada cliente pode personalizar na própria aplicação.

 

 

107  

9 REFERÊNCIAS BIBLIOGRÁFICAS     APACHE. Servidor Apache, 2012. Disponivel em: . Acesso em: 29 out. 2012. BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro: Editora Campus, 2007. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: Guia do Usuário. Rio de Janeiro: Trad. Fabio Freitas, 2005. BRAGA, A. Análise de Ponto de Função. Rio de Janeiro: Editora IPBI Press, 1996. APACHE MAVEN, Maven, 2012. Disponível em . Acesso em 01 nov. 2012. GLASSFISH,

Glassfish

Application

Server,

2012.

Disponível

em

. Acesso em 01 nov 2012. ORACLE, Java , 2012. Disponível em <   http://www.java.com/ >. Acesso em 01 nov 2012. JAVA

MAGAZINE,

Java

Magazine

ed

106,

2012.

Disponível

em

. Acesso em 15 out 2012. SUBVERSION,

Apache

SubVersion,

2012.

Disponível

em

<  

http://subversion.apache.org/>. Acesso em 01 nov. 2012. JBOSS. Hibernate, 2012. Disponivel em: . Acesso em: 29 out. 2012.

 

  JSF.

108   Java

Server

Faces,

2012.

Disponível

em:

. Acesso em: 29 out. 2012. POSTGRESQL.

Postgres,

2012.

Disponivel

em:

. Acesso em: 29 out. 2012. PRESSMAN, R. S. Engenharia de Software. São Paulo: Pearson Makron Books, 2011. PRIMEFACES.

PrimeFaces,

2012.

Disponivel

em:

. Acesso em: 26 out. SILVA, R. P. UML2 em Modelagem Orientada a Objetos. Santa Catarina: Editora Visual Books, 2007. SPRINGSOURCE.

Springsource,

Disponivel

em:

. Acesso em: 29 out. 2012. VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de Ponto de Função – Medição, Estimativa e Gerenciamento de Projetos de Software. São Paulo: Editora Érica, 2010. WAZLAWICK, R. S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. Rio de Janeiro: Editora Campus, 2004. MARINESCU, F. Padrões de Projeto EJB - Padrões Avançados, Processos e Idiomas. São Paulo: Editora Bookman, 2002. PANDA, D; RAHMAN, R; LANE, D. EJB 3 Em Ação. Rio de Janeiro: Editora Alta Books , 2009. LUCKOW, D; MELO, A. Programação Java para a Web. São Paulo, Novatec Editora, 2010.

 

  WIKIPEDIA,

109   2012,

Diagrama

de

Pacotes,

Disponível

em:

. Acesso em 05 out. 2012 WIKIPEDIA,

2012,

Diagrama

de

Sequência,

Disponível

em:

. Acesso em 05 out. 2012

 

 

ANEXO A – DESCRIÇÕES ESTENDIDAS  

 

110  

 

111  

 

 

 

 

112  

ESP00 – Solicitação de Cadastro no Portal (Cliente Não Existente) Prover uma funcionalidade onde novos clientes possam se cadastrar no portal, e ter acesso as demais funcionalidades de uma forma controlada. Atores: Usuário Pré-condição: Que o usuário não esteja logado. Fluxo Principal – Solicitação de Cadastro no Portal (Cliente Não Existente) 1. O caso de uso se inicia quando o ator decide por se cadastrar no portal, e clica no botão de “Registrar”. 2. O sistema exibe uma tela com duas opções, uma para cliente já existente, e outra para cliente não existente; 3. O usuário seleciona a opção de cliente não existente. 4. O sistema exibe um formulário de cadastro, com campos a preencher do novo cliente e do usuário responsável. 5. O usuário preenche os dados do formulário e clica no botão ‘Salvar’. 5.1. Alternativamente ele pode clicar no botão ‘Cancelar’ e o caso de uso se encerra, voltando a tela inicial do portal. 6. O sistema faz a validação dos dados do formulário. (#E1) (#E2) 7. O sistema persiste os dados, envia um e-mail de confirmação para o email cadastrado e exibe uma mensagem de sucesso ao usuário. Os registros de Cliente de Portal e Usuário são criados com a situação de “Pendente Ativação E-mail”. 7.1. Alternativamente, caso ocorra algum erro neste processo, uma mensagem de falha é apresentada ao usuário, com o(s) respectivo(s) motivo. 8. O caso de uso se encerra. Fluxos Alternativos (#A1): Confirmação de E-mail 1. O usuário acessa o e-mail com o qual se cadastrou e clica no link de confirmação. 2. O link irá apontar para o sistema, este que ao receber a solicitação irá alterar a situação do Cliente de Portal e do Usuário para “Pendente Aprovação”.

 

 

113  

Fluxo de Exceção (#E1): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem “O campo ‘NomeCampo’ é obrigatório!”. 2. O caso de uso retorna ao passo 5 do fluxo principal. (#E2): E-mail Inválido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!”. 2. O caso de uso retorna ao passo 5 do fluxo principal. Protótipos de Tela

 

 

   

 

114  

 

 

 

 

 

 

115  

ESP00A – Solicitação de Cadastro no Portal (Cliente Existente) Prover uma funcionalidade onde usuários possam se cadastrar no portal, e que o cliente ao qual pertencem já existe. Atores: Usuário Pré-condição: Que o usuário não esteja logado. Fluxo Principal – Solicitação de Cadastro no Portal (Cliente Existente) 1. O caso de uso se inicia quando o ator decide por se cadastrar no portal, e clica no botão de “Registrar”. 2. O sistema exibe uma tela com duas opções, uma com cliente já existente, e outra com cliente não existente; 3. O usuário seleciona a opção de cliente existente. 4. O sistema exibe um formulário de cadastro, com campos a preencher do novo do usuário e com os dados do cliente para visualização. 5. O cliente executa o fluxo (#A1). 6. O usuário preenche os dados do formulário e clica no botão ‘Salvar’. 6.1. Alternativamente ele pode clicar no botão ‘Cancelar’ e o caso de uso se encerra, voltando a tela inicial do portal. 7. O sistema faz a validação dos dados do formulário. (#E1) (#E2) 8. O sistema persiste os dados, envia um e-mail de confirmação para o email cadastrado e exibe uma mensagem de sucesso ao usuário. Os registros de Cliente de Portal e Usuário são criados com a situação de “Pendente Ativação E-mail”. 8.1. Alternativamente, caso ocorra algum erro neste processo, uma mensagem de falha é apresentada ao usuário, com o(s) respectivo(s) motivo. 9. O caso de uso se encerra. Fluxos Alternativos (#A1): Buscar Cliente de Portal 1. O sistema exibe um dialogo de busca de clientes de portal. 2. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3. O sistema executa a busca com os filtros passado pelo usuário e trás os resultados que batem com os mesmos. 4. O usuário seleciona o cliente na lista e clica no botão ‘Selecionar’.

 

 

116   4.1. Alternativamente, o usuário pode voltar ao passo 2 e refazer sua busca. 4.2. Alternativamente, o usuário pode clicar no botão cancelar e nenhuma ação é executada.

5. O sistema então mostra os dados básicos do cliente de portal selecionado na aba de Cliente. (#A2): Confirmação de E-mail 1. O usuário acessa o e-mail com o qual se cadastrou e clica no link de confirmação. 2. O link irá apontar para o sistema, este que ao receber a solicitação irá alterar a situação do Usuário para “Pendente Aprovação”. Fluxo de Exceção (#E1): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem “O campo ‘NomeCampo’ é obrigatório!”. 2. O caso de uso retorna ao passo 6 do fluxo principal. (#E2): E-mail Inválido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!”. 2. O caso de uso retorna ao passo 6 do fluxo principal. Interface

 

 

 

117  

 

 

118  

 

119  

ESP01 – Manter Clientes de Portal Permitir aos administradores do sistema cadastrar, alterar e remover clientes de portal que terão acesso a aplicação. Atores: Administrador do Portal Pré-condição: Que o usuário esteja logado e seja um administrador do portal Fluxo Principal – Manter Clientes de Portal 1. O caso de uso se inicia quando o usuário decide manter o os dados de clientes de portal. 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Cliente de Portal 3. O administrador do sistema quer cadastrar algum cliente no portal e clica no botão “Menu/Novo”. 4. O sistema exibe o formulário de cadastro usuários. 1. O usuário preenche os campos e clica no botão “Salvar”.(#A6) (#A7) (#A8) (#A9) 5. O sistema faz as validações necessárias. (#E2) 5.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 6. O sistema persiste os dados e exibe uma mensagem de sucesso. 6.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 7. O caso de uso retorna ao passo 3 do fluxo principal, com o registro criado selecionado e com os fluxos (#A3) (#A4) (#A5) habilitados. (#A2): Buscar Cliente de Portal

 

 

120  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de clientes de portal 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que “batem” com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o fluxo volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Cliente de Portal 2. O usuário clica no botão “Menu/Editar”. 3. O sistema exibe um formulário com os dados para a edição. 4. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) (#A7) (#A8) (#A9) 5. O sistema faz as validações necessárias. (#E2) 5.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 6. O sistema persiste os dados e exibe uma mensagem de sucesso. 6.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 7. O caso de uso retorna ao passo 3 do fluxo principal. (#A4): Remover Cliente de Portal

 

 

121  

1. O usuário decide por remover um cliente e clica no botão “Menu/Excluir“. 2. O sistema exibe um dialogo de confirmação de exclusão. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e o caso de uso se encerra. 4. O sistema altera a situação do cliente para “Excluído”,

persiste as

alterações na base de dados e exibe uma mensagem de sucesso. Agora os usuários do cliente não podem mais logar no sistema. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A5): Alterar Situação de Cliente de Portal 1. O ator decide alterar a situação de um cliente de portal e clica no botão “Menu/Alterar Situação”. 2. O sistema exibe um dialogo com as opções de situações disponíveis. 3. O ator escolhe a situação desejada e clica no botão “Confirmar”. 3.1. Alternativamente o ator clica no botão “Cancelar” e o caso de uso retorna para o passo 3 do fluxo principal. 4. O sistema altera a situação do cliente, persiste a alteração na base de dados e exibe uma mensagem de sucesso. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem “O campo ‘Nome Campo’ é obrigatório!” e volta ao preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca de clientes de portal não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”.

 

 

122  

(#E4): Resultado de filtro vazio 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!” e volta ao preenchimento das informações. Protótipos de tela

 

 

 

123  

 

 

124  

 

 

125  

 

126  

ESP01A – Aprovação de Clientes de Portal Prover uma funcionalidade onde os administradores possam ver as aprovações de clientes pendentes no portal, e aprova-las de forma rápida. Atores: Administrador do Portal Pré-condição: Que o usuário esteja logado e tenha perfil de administrador do portal. Fluxo Principal – Aprovação de Clientes de Portal 1. O caso de uso se inicia quando o ator decide visualizar as aprovações de clientes de portal pendentes. 2. O sistema exibe uma lista de clientes de portal com o status “Pendente Aprovação”, ordenados pela data de criação mais antiga. (#E1) 3. O ator escolhe uma das opções disponíveis. (#A1) (#A2) (#A3) 4. O ator pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra. Fluxos Alternativos (#A1): Filtrar Clientes de Portal 1. O ator deseja filtrar os clientes pendentes e clica no botão “Filtrar”. 2. O sistema exibe um dialogo com os campos de busca a serem preenchidos. 3. O ator preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o ator clica no botão “Todos”, e o sistema realiza a busca ignorando os filtros passados. 3.2. Alternativamente o ator clica no botão “Cancelar”, e o caso de uso se encerra. 4. O sistema realiza a busca na base de dados, atualizando a lista de clientes com os registros que combinam com os filtros passados. (#E1) (#A2): Detalhar Cliente 1. O usuário clica no botão “Menu Ações/Detalhar” do registro que ele deseja visualizar os dados. 2. O sistema exibe um dialogo com os dados do cliente de portal. 3. O usuário clica no botão “Fechar” e o dialogo é fechado. (#A3): Aprovar Cliente de Portal

 

 

127  

1. O ator clica no botão “Menu Ações/Ativar” do registro que ele deseja alterar. 2. O sistema exibe um dialogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e este fluxo se encerra. 4. O sistema então muda a situação do Cliente de Portal para “Ativo”, juntamente com a situação de seu usuário responsável, persistindo as alterações na base de dados. 5. O sistema envia um e-mail ao usuário ativado, avisando que ele já pode acessar o sistema. 6. O sistema exibe uma mensagem de sucesso. Fluxo de Exceção (#E1): Resultado de filtro vazio 1. Sistema emite a mensagem “Nenhum registro encontrado” dentro da lista de registros. Pós-condição: N/A Protótipos de Tela

 

 

 

128  

 

129  

ESP02 – Manter Usuários (Administrador) Permitir aos administradores do sistema manter os usuários de algum cliente de portal, alterar e remover registros. Atores: Administrador do Portal Pré-condição: Que o usuário esteja logado e seja um administrador do portal Fluxo Principal – Manter Usuários 1. O caso de uso se inicia quando o usuário decide manter o usuários 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Usuário 1. O administrador do sistema quer cadastrar usuário para algum cliente e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro usuários. 3. O usuário preenche os campos e clica no botão “Salvar. (#A6) 4. O sistema faz as validações necessárias. (#E2) (#E4) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar Usuário

 

 

130  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de usuários 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que “batem” com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o fluxo volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Usuário 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados para a edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) 4. O sistema faz as validações necessárias. (#E2) (#E4) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A4): Remover Usuário

 

 

131  

1. O usuário decide por remover um usuário e clica no botão “Menu/Excluir“. 2. O sistema exibe um dialogo de confirmação de exclusão. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e o caso de uso se encerra. 4. O sistema altera a situação do usuário para “Excluído”,

persiste as

alterações na base de dados e exibe uma mensagem de sucesso. Agora os usuário não pode mais logar o sistema nem aparece nas buscas para o cliente. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A5): Alterar Situação de Usuário 1. O ator decide alterar a situação de um usuário. 2. O sistema exibe um dialogo com as opções de situações disponíveis. 3. O ator escolhe a situação desejada e clica no botão “Confirmar”. 3.1. Alternativamente o ator clica no botão “Cancelar” e o caso de uso retorna para o passo 3 do fluxo principal. 4. O sistema altera a situação do usuário, persiste a alteração na base de dados e exibe uma mensagem de sucesso. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A6): Buscar Cliente de Portal

 

 

132  

1. O ator deseja selecionar o cliente de portal a qual o usuário pertence e clica no botão de “Buscar Cliente de Portal”. 2. O sistema exibe um dialogo de busca de clientes de portal. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que “batem” com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o fluxo volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o usuário é relacionado como usuário deste cliente. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. (#E4): E-mail Inválido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!” e volta ao preenchimento das informações. Pós-condição: N/A Protótipos de Tela

 

 

 

133  

 

 

134  

 

135  

ESP02A – Manter Usuários (Usuário Responsável) Permitir aos usuário responsável de um cliente manter os seus usuários, criando, alterando e removendo registros. Atores: Usuário Responsável Pré-condição: Que o usuário esteja logado e seja um o usuário responsável de um cliente de portal. Fluxo Principal – Manter Usuários 1. O caso de uso se inicia quando o usuário decide manter o usuários. 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra. Fluxos Alternativos (#A1): Cadastrar Usuário 1. O administrador do cliente quer cadastrar usuário e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro usuários. 3. O usuário preenche os campos e clica no botão “Salvar. 4. O sistema faz as validações necessárias. (#E2) (#E4) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar Usuário

 

 

136  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de usuários. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que “batem” com os filtros passados. Esta busca será filtrada e trará resultados apenas do cliente de portal ao qual o usuário logado pertence. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o fluxo volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Usuário 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados para a edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. 4. O sistema faz as validações necessárias. (#E2) (#E4) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A4): Remover Usuário

 

 

137  

1. O usuário decide por remover um usuário e clica no botão “Menu/Excluir“. 2. O sistema exibe um dialogo de confirmação de exclusão. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e o caso de uso se encerra. 4. O sistema altera a situação do usuário para “Excluído”,

persiste as

alterações na base de dados e exibe uma mensagem de sucesso. Agora os usuário não pode mais logar o sistema nem aparece nas buscas para o cliente. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A5): Alterar Situação de Usuário 1. O ator decide alterar a situação de um usuário. 2. O sistema exibe um dialogo com as opções de situações disponíveis. 3. O ator escolhe a situação desejada e clica no botão “Confirmar”. 3.1. Alternativamente o ator clica no botão “Cancelar” e o caso de uso retorna para o passo 3 do fluxo principal. 4. O sistema altera a situação do usuário, persiste a alteração na base de dados e exibe uma mensagem de sucesso. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”.

 

 

138  

(#E4): E-mail Inválido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!” e volta ao preenchimento das informações. Pós-condição: N/A Protótipos de Tela

 

 

 

139  

 

140  

ESP02B – Aprovação de Usuários de Cliente Prover uma funcionalidade onde os usuários responsáveis de um cliente de portal possam ver as os usuários pendentes de seu cliente, e aprova-los de forma rápida. Atores: Usuário Responsável Pré-condição: Que o usuário esteja logado e seja um usuário responsável do cliente de portal. Fluxo Principal – Aprovação de Usuários de Cliente 1. O caso de uso se inicia quando o ator decide visualizar as aprovações de usuário pendentes. 2. O sistema exibe uma lista de usuários com a situação “Pendente Aprovação”, ordenados pela data de criação mais antiga e pertencentes ao cliente de portal do usuário que está logado. 3. O ator escolhe uma das opções disponíveis. (#A1) (#A2) 4. O ator pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra. Fluxos Alternativos (#A1): Filtrar Usuários 1. O ator deseja filtrar os usuários pendentes e clica no botão “Filtrar”. 2. O sistema exibe um dialogo com os campos de busca a serem preenchidos. 3. O ator preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o ator clica no botão “Todos”, e o sistema realiza a busca ignorando os filtros passados. 3.2. Alternativamente o ator clica no botão “Cancelar”, e o caso de uso se encerra. 4. O sistema realiza a busca na base de dados, atualizando a lista de usuários com os registros que combinam com os filtros passados. (#A2): Ativar Usuário

 

 

141  

1. O ator clica no botão “Menu Ações/Ativar” do registro que ele deseja alterar. 2. O sistema exibe um dialogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e este fluxo se encerra. 4. O sistema então muda a situação do Usuário para “Ativo”, persistindo as alterações na base de dados. 5. O sistema envia um e-mail ao usuário ativado, avisando que ele já pode acessar o sistema. 6. O sistema exibe uma mensagem de sucesso. Fluxo de Exceção (#E1): Resultado de filtro vazio 1. Sistema emite a mensagem “Nenhum registro encontrado” dentro da lista de registros. Pós-condição: N/A Protótipos de Tela

 

 

 

 

142  

 

 

143  

ESP03 – Configuração de Descrição Estendida Permite ao usuário responsável do sistema configurar os campos que irão aparecer na funcionalidades de manutenção de descrições estendidas. Atores: Usuário Responsável Pré-condição: Que o usuário esteja logado e seja o usuário responsável do cliente. Fluxo Principal – Configuração de Descrição Estendida 1. O caso de uso se inicia quando o ator decide configurar o arquivo de descrições estendidas. 2. O sistema exibe uma tela com os dados do cliente e com as opções de dados que a descrição estendida irá manter. 3. O usuário clica no botão “Editar”. 4. O sistema exibe a mesma tela de visualização, porém com os campos habilitados para a edição. 5. O usuário altera as opções que desejar e clica no botão “Salvar”. 5.1. Alternativamente o usuário clica no botão “Cancelar” e o sistema o redireciona para a tela de visualização. 6. O sistema então persiste a alteração e exibe uma mensagem de sucesso ao usuário. 6.1. Caso ocorra algum erro, o sistema exibe uma mensagem de erro. 7. Agora, na funcionalidade Manutenção de Descrições Estendidas, apenas os dados marcados nesta UF serão apresentados na tela do usuário para a visualização e manutenção. Pós-condição: O arquivo de demanda foi devidamente mantido. Protótipos de Tela

 

 

   

 

144  

 

 

145  

ESP04 – Manter Cenários Base Permitir aos clientes de portal e seus usuários manterem fluxos padrão de especificação, ou seja, criar fluxos de casos de uso base, para poderem ser reutilizados na hora de criar casos de uso em uma especificação. Atores: Usuários de Cliente de Portal Regras de Negócio Associadas: Um cenário precisa possuir no mínimo dois passos para poder ser salvo. Pré-condição: Que o usuário esteja logado. Fluxo Principal – Manter Cenários Base 1. O caso de uso se inicia quando o ator decide manter os cenários base do cliente. 2. O sistema habilita as opções de manutenção de cenários base. (#A1) (#A2) (#A3) (#A4) (#A5) (#A6) (#E1) 3. O ator escolhe uma das opções disponíveis. 4. O ator pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Cenário Base 1. O ator decide cadastrar um cenário base e clica no botão “Novo”. 2. O sistema exibe um dialogo para o cadastro do cenário. 3. O ator preenche todos os campos obrigatórios e opcionais que desejar. (#A5) 4. O ator decide salvar o cadastro. 4.1. Alternativamente o ator desiste da operação e o caso de uso retorno para o passo 3 do fluxo principal. 5. O sistema valida os dados inseridos (#E2) (#E4) 6. O sistema persiste o novo fluxo. 7. O caso de uso retorna ao ponto de chamada. (#A2): Procurar Cenário Base

 

 

146  

1. O ator deseja buscar algum cenário já cadastrado na aplicação e clica no botão Filtrar. 2. O sistema exibe um dialogo de busca de cenários. 3. O ator preenche os filtros ou parte deles e clica no botão filtrar. 4. O ator clica em filtrar e o sistema exibe o resultado da busca (#E3) 4.1. O ator pode retornar ao passo 3 quantas vezes achar necessário 5. O ator navega pela lista e escolhe o registro desejado 5.1. Alternativamente o ator desiste da operação e o caso de uso retorna para o passo 3 do fluxo principal 6. O sistema habilita os fluxos (#A3) (#A4) (#A5) (#A6) 7. O sistema retorna ao passo 3 do fluxo principal (#A4): Editar Cenários Base 1. O ator decide editar algum cenário base e clica no botão “Ações/Editar”. 2. O sistema exibe o formulário de alteração de cenários. 3. O ator altera todos os campos que desejar e clica no botão “Salvar”. 3.1. Alternativamente o ator desiste da operação e o caso de uso retorno para o passo 3 do fluxo principal 4. O sistema valida os dados inseridos (#E2) 5. O sistema armazena os novos dados no arquivo de demandas na base de dados 6. O caso de uso retorna para o passo 3 do fluxo principal (#A5): Remover Cenário Base 1. O usuário seleciona o(s) cenário(s) que deseja remover e clica no botão “Excluir”. 2. O sistema exibe um diálogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente ele clica em “Cancelar” e o caso de uso se encerra. 4. Os cenários são removidos da base de dados e a lista de cenários é atualizada. 5. O sistema retorna ao ponto de chamada. (#A6): Visualização Rápida de Cenário

 

 

147  

1. O ator clica no botão “Ações/Visualizar”. 2. O sistema exibe um dialogo com os dados do cenário selecionado. 3. O ator clica no botão “Fechar”. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#A6). (#E2): Dados inseridos inválidos 1. Sistema emite a mensagem informando os campos cujo valores são inválidos. 2. O sistema volta ao ponto de chamada. (#E3): Resultado de filtro vazio 1. Sistema emite a mensagem “Nenhum registro encontrado” dentro da lista de busca de registros. (#E4): Restrições de integridade Protótipos de Tela

 

 

 

148  

 

149  

ESP05 – Manter Atores Permite que os usuários de um cliente mantenham os dados dos possíveis Atores que podem ser utilizados na hora se construir especificações técnicas. Atores: Usuários de Cliente de Portal Pré-condição: O Usuário precisa estar logado. Fluxo Principal – Manter Atores 1. O caso de uso se inicia quando usuário opta por manter atores. 2. O sistema exibe uma tela com uma lista de atores cadastrados, habilitando os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#E2) 3. O ator escolhe uma das opções disponíveis. 4. O ator pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Ator 1. O usuário deseja criar um novo Ator e clica no botão “Novo”. 2. O sistema exibe um dialogo com os dados do novo ator a serem preenchidos. 3. O usuário preenche os campos e clica no botão “Salvar”. 4. O sistema faz as validações necessárias. (#E1) 5. O sistema então persiste os dados do novo Ator e envia uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema envia uma mensagem de erro. 6. A lista de atores é atualizada, agora com o novo ator incluído. 7. O caso de uso retorna para o passo 3 do fluxo principal (#A2): Filtrar Atores

 

 

150  

1. O usuário clica no botão “Filtrar”. 2. O sistema exibe um dialogo com campos de filtro a serem preenchidos. 3. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o usuário clica no botão “Todos”. 3.2. O sistema realiza o filtro de atores ignorando os filtros passados pelo usuário. 3.3. Alternativamente o usuário clica no botão “Cancelar” o dialogo é fechado e nenhuma filtro é executado. 4. O sistema realiza o filtro de atores de acordo com os parâmetros passados pelo usuário, e atualiza a lista de atores na tela. (#E2) (#A4): Editar Ator 1. O usuário deseja editar um ator existente e clica no botão “Menu Ações/Editar”. 2. O sistema exibe um dialogo com os dados do ator para serem editados. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. 4. O sistema faz as validações necessárias. (#E1) 5. O sistema então persiste os dados e envia uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema envia uma mensagem de erro. 6. A lista de atores é atualizada, agora com o os dados do ator atualizados. 7. O caso de uso retorna para o passo 3 do fluxo principal (#A5): Remover Ator 1. O usuário seleciona o(s) ator(es) que deseja remover e clica no botão “Excluir”. 2. O sistema exibe um diálogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente ele clica em “Cancelar” e o caso de uso se encerra. 4. Os atores são removidos da base de dados e a lista de atores é atualizada. 5. O sistema retorna ao ponto de chamada. Fluxo de Exceção (#E1): Dados Obrigatórios

 

 

151  

1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E2): Resultado de filtro vazio 1. Sistema emite a mensagem “Nenhum registro encontrado” dentro da lista de registros. (#E3): Restrição de Integridade 1. Se o ator estiver atrelado a alguma especificação ele não pode ser excluído. Pós-condição: O arquivo de demanda foi devidamente mantido. Protótipos de Tela

 

 

 

152  

 

153  

ESP06 – Manter Clientes de Projeto Permitir aos usuários administradores de um cliente de portal cadastrar, alterar e remover dados de seus clientes de projeto. Atores: Administrador Cliente Pré-condição: Que o usuário esteja logado e seja um administrador cliente. Fluxo Principal – Manter Clientes de Projeto 1. O caso de uso se inicia quando o usuário decide manter o os dados de clientes de projeto. 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Cliente de Projeto 1. O ator deseja cadastrar algum cliente de projeto e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro com os campos a serem preenchidos. 3. O usuário preenche os campos e clica no botão “Salvar”.(#A6) (#A7) (#A8) (#A9) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar Cliente de Projeto

 

 

154  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de clientes de projeto. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Cliente de Projeto 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados preenchidos em modo de edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) (#A7) (#A8) (#A9) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A4): Remover Cliente de Projeto

 

 

155  

1. O usuário decide por remover um cliente e clica no botão “Menu/Excluir“. 2. O sistema exibe um dialogo de confirmação de exclusão. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente o usuário clica no botão “Cancelar” e o caso de uso se encerra. 4. O sistema altera a situação do cliente para “Excluído”,

persiste as

alterações na base de dados e exibe uma mensagem de sucesso. Agora, o cliente de projeto não aparece mais nas buscas. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A5): Alterar Situação de Cliente de Projeto 1. O ator decide alterar a situação de um cliente de projeto. 2. O sistema exibe um dialogo com as opções de situações disponíveis. 3. O ator escolhe a situação desejada e clica no botão “Confirmar”. 3.1. Alternativamente o ator clica no botão “Cancelar” e o caso de uso retorna para o passo 3 do fluxo principal. 4. O sistema altera a situação do cliente, persiste a alteração na base de dados e exibe uma mensagem de sucesso. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A6): Novo Contato 1. O usuário decide cadastrar um novo contato para o cliente de projeto e clica no botão “Menu Contato/Novo”. 2. O sistema exibe um diálogo com os dados do novo contato a preencher. 3. O ator preenche os campos e clica no botão “Salvar” 3.1. Alternativamente o ator desiste da operação e o caso de uso retorna ao ponto de chamada. 4. O sistema faz a validação dos campos. (#E2) (#E4) 5. O usuário é adicionado na lista de contatos do cliente. 6. O sistema retorna ao ponto de chamada. (#A7): Filtrar Contatos

 

 

156  

1. O usuário clica no botão “Menu Contato/Filtrar”. 2. O sistema exibe um dialogo com campos de filtro a serem preenchidos. 3. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o usuário clica no botão “Todos”. 3.2. O sistema realiza o filtro de contatos ignorando os filtros passados pelo usuário. 3.3. Alternativamente o usuário clica no botão “Cancelar” o dialogo é fechado e nenhuma filtro é executado. 4. O sistema realiza o filtro de contatos de acordo com os parâmetros passados pelo usuário, e atualiza a lista de contatos na tela. (#E3) (#A8): Editar Contato 1. O usuário decide editar um usuário e clica no botão “Menu Ações/Editar”. 2. O sistema exibe um diálogo com os dados do contato a alterar. 3. O ator altera os campos que deseja e clica no botão “Salvar”. 3.1. Alternativamente o ator desiste da operação e o caso de uso retorna ao ponto de chamada. 4. O sistema faz a validação de campos. (#E2) (#E4) 5. O usuário é atualizado na lista de contatos do cliente. 6. O sistema retorna ao ponto de chamada. (#A9): Excluir Contatos 1. O ator seleciona o(s) contato(s) que deseja remover e clica no botão “Menu Contato/Excluir”. 2. O sistema exibe um diálogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente ele clica em “Cancelar” e o caso de uso se encerra. 4. Os contatos selecionados são removidos da lista de contatos do cliente. 5. O sistema retorna ao ponto de chamada. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios

 

 

157  

1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. (#E4): E-mail Válido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!” e volta ao preenchimento das informações. Protótipos de Tela

 

 

 

158  

 

 

159  

 

 

160  

 

161  

ESP07 – Manter Projetos Permitir aos usuários de um cliente de portal cadastrar, alterar e remover dados de seus projetos. Atores: Administrador Cliente Pré-condição: Que o usuário esteja logado e seja um administrador cliente. Fluxo Principal – Manter Projetos 1. O caso de uso se inicia quando o usuário decide manter o os dados e um projeto. 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Projetos 1. O ator deseja cadastrar algum projeto e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro com os campos a serem preenchidos. 3. O usuário preenche os campos e clica no botão “Salvar”.(#A6) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar Projeto

 

 

162  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de projetos. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Projeto 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados preenchidos em modo de edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A5): Alterar Situação de Projeto

 

 

163  

1. O ator decide alterar a situação de um projeto. 2. O sistema exibe um dialogo com as opções de situações disponíveis. 3. O ator escolhe a situação desejada e clica no botão “Confirmar”. 3.1. Alternativamente o ator clica no botão “Cancelar” e o caso de uso retorna para o passo 3 do fluxo principal. 4. O sistema altera a situação do projeto, persiste a alteração na base de dados e exibe uma mensagem de sucesso. 4.1. Alternativamente, caso ocorra algum erro no passo 4, o sistema exibe uma mensagem de erro. 5. O caso de uso retorna para o passo 3 do fluxo principal. (#A6): Buscar Cliente Projeto 1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de clientes de projeto. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 5.2. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A7): Visualizar Artefatos do Projeto 1. Ao se selecionar algum projeto, é exibida uma lista com todos os artefatos cadastrados no mesmo, sendo possível a navegação para eles a partir da mesma tela. (#A8): Visualizar Descrições do Projeto 1. Ao se selecionar algum projeto, é exibida uma lista com todas as descrições estendidas do projeto, permitindo que seja feita a navegação para a funcionalidade de visualizar descrição. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5)

 

 

164  

(#E2): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. Protótipos de Tela

 

 

 

165  

 

 

166  

 

 

167  

 

168  

ESP08 – Manter Artefatos de Projeto Permitir aos usuários de um cliente de portal cadastrar, alterar e remover artefatos e documentos dentro de um projeto, que serão utilizados para consulta. Atores: Usuário Pré-condição: Que o usuário esteja logado. Fluxo Principal – Manter Artefatos de Projeto 1. O caso de uso se inicia quando o usuário decide manter os artefatos de algum projeto 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5) (#A7) (#A8) (#A9) (#A10) (#A11) (#A12) (#A13) (#A14) 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 5. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar Artefato de Projeto 1. O ator deseja cadastrar algum artefato e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro com os campos a serem preenchidos. 3. O usuário preenche os campos e clica no botão “Salvar”.(#A6) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar Artefato de Projeto

 

 

169  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de artefatos de projetos. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) (#A3): Editar Artefato de Projeto 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados preenchidos em modo de edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A6): Buscar Projeto

 

 

170  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de projetos. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 5.2. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A7): Novo Anexo 1. O usuário decide cadastrar um novo anexo e clica no botão “Menu Anexo/Novo”. 2. O sistema exibe um diálogo com o componente de file upload. 3. O ator clica no botão selecione, e seleciona o(s) arquivo(s) que deseja anexar. 3.1. Alternativamente o ator desiste da operação e o caso de uso retorna ao ponto de chamada. 4. O anexo é atrelado ao artefato. 5. O sistema retorna ao ponto de chamada. (#A8): Filtrar Anexos 1. O usuário clica no botão “Menu Anexo/Filtrar”. 2. O sistema exibe um dialogo com campos de filtro a serem preenchidos. 3. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o usuário clica no botão “Todos”. 3.2. O sistema realiza o filtro de anexos ignorando os filtros passados pelo usuário. 3.3. Alternativamente o usuário clica no botão “Cancelar” o dialogo é fechado e nenhum filtro é executado. 4. O sistema realiza o filtro de anexos de acordo com os parâmetros passados pelo usuário, e atualiza a lista de contatos na tela. (#E3) (#A10): Excluir Anexo

 

 

171  

1. O ator seleciona o(s) anexo(s) que deseja remover e clica no botão “Menu Anexo/Excluir”. 2. O sistema exibe um diálogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente ele clica em “Cancelar” e o caso de uso se encerra. 4. Os anexos selecionados são removidos da lista de contatos do cliente. 5. O sistema retorna ao ponto de chamada. (#A11): Novo Documento 1. O usuário decide cadastrar um novo documento e clica no botão “Menu Documentos/Novo”. 2. O sistema exibe um diálogo com os campos de documento a serem preenchidos 3. O ator preenche os dados e clica no botão “Salvar”. 4. O sistema faz a validação dos campos. (#E2) 4.1. Alternativamente o ator desiste da operação e o caso de uso retorna ao ponto de chamada. 5. O novo documento é atrelado ao artefato. 6. O sistema retorna ao ponto de chamada. (#A12): Filtrar Documentos 1. O usuário clica no botão “Menu Documentos/Filtrar”. 2. O sistema exibe um dialogo com campos de filtro a serem preenchidos. 3. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3.1. Alternativamente o usuário clica no botão “Todos”. 3.2. O sistema realiza o filtro de documentos ignorando os filtros passados pelo usuário. 3.3. Alternativamente o usuário clica no botão “Cancelar” o dialogo é fechado e nenhum filtro é executado. 4. O sistema realiza o filtro de documentos de acordo com os parâmetros passados pelo usuário, e atualiza a lista de contatos na tela. (#E3) (#A13): Editar Documentos

 

 

172  

1. O usuário decide editar um documento existente e clica no botão “Menu Ações/Editar”. 2. O sistema exibe um diálogo com os campos de documento a serem editados. 3. O ator altera os dados que deseja e clica no botão “Salvar”. 4. O sistema faz a validação dos campos. (#E2) 4.1. Alternativamente o ator desiste da operação e o caso de uso retorna ao ponto de chamada. 5. O novo documento é atrelado ao artefato. 6. O sistema retorna ao ponto de chamada. (#A14): Excluir Documento 1. O ator seleciona o(s) documentos(s) que deseja remover e clica no botão “Menu Documento/Excluir”. 2. O sistema exibe um diálogo de confirmação. 3. O usuário clica no botão “Confirmar”. 3.1. Alternativamente ele clica em “Cancelar” e o caso de uso se encerra. 4. Os documentos selecionados são removidos da lista de contatos do cliente. 5. O sistema retorna ao ponto de chamada. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. Protótipos de Tela

 

 

 

173  

 

 

174  

 

 

175  

 

 

176  

 

177  

ESP09 – Manter Descrições Estendidas Permitir aos usuários de um cliente de portal fazer a manutenções diversos dados referentes a descrições estendidas. Atores: Usuário Pré-condição: Que o usuário esteja logado Fluxo Principal – Manter Descrições Estendidas 1. O caso de uso se inicia quando o usuário decide manter o os dados de uma descrição estendida. 2. O sistema habilita os botões para os fluxos alternativos. (#A1) (#A2) (#A3) (#A4) (#A5). 3. O usuário seleciona a opção que deseja executar. 4. O usuário pode retornar ao passo 3 quando vezes desejar. 6. Este caso de uso se encerra Fluxos Alternativos (#A1): Cadastrar DE 1. O ator deseja cadastrar alguma nova descrição e clica no botão “Menu/Novo”. 2. O sistema exibe o formulário de cadastro com os campos a serem preenchidos, porém apenas as abas de Dados Básicos e Outras Informações estão com os dados para a edição, enquanto os outros serão apenas visualizados. 3. O usuário preenche os campos e clica no botão “Salvar”. 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A2): Buscar DE

 

 

178  

1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de descrições estendidas. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela e o sistema habilita os fluxos (#A3) (#A4) (#A5) ALTERAR (#A3): Editar DE 1. O usuário clica no botão “Menu/Editar”. 2. O sistema exibe um formulário com os dados preenchidos em modo de edição. 3. O usuário altera os campos que deseja e clica no botão “Salvar”. (#A6) 4. O sistema faz as validações necessárias. (#E2) 4.1. Alternativamente o usuário clica no botão “Cancelar” o sistema volta ao passo 3 do fluxo principal. 5. O sistema persiste os dados e exibe uma mensagem de sucesso. 5.1. Alternativamente, caso ocorra algum erro, o sistema exibe uma mensagem de erro. 6. O caso de uso retorna ao passo 3 do fluxo principal. (#A5): Manter Cenários

 

 

179  

1. O ator decide buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de descrições estendidas. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E3) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela; (#A6): Manter Tipos de Dados 1. O usuário deseja manter algum tipo de dado e acessa a aba de Tipos de dados. 2. O usuário pode deseja cadastrar um novo Dado e clica no botão ‘Novo’; 3. O sistema exibe o diálogo de criação de tipos de dados; 4. O usuário preenche os dados e clica no botão ‘Salvar’; 5. O novo registro é criado e a lista de dados atualizada; 5.1. Alternativamente, o usuário deseja alterar algum dado existente e clica no botão ‘Editar’ do registro selecionado; 5.2. O sistema exibe um diálogo com os dados para alteração; 5.3. O usuário altera os dados que desejar e clica no botão ‘Salvar’ 5.4. O sistema atualiza o registro editado e atualiza a lista de dados; (#A7): Visualizar Descrições do Projeto 1. Ao se selecionar algum projeto, é exibida uma lista com todas as descrições estendidas do projeto, permitindo que seja feita a navegação para a funcionalidade de visualizar descrição. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A3) (#A4) (#A5) (#E2): Dados obrigatórios

 

 

180  

1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem

“O

campo

‘NomeCampo’

é

obrigatório!”

e

volta

ao

preenchimento das informações. (#E3): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. Protótipos de Tela

 

 

 

181  

 

 

182  

 

 

183  

 

184  

ESP09A – Impressão de Descrições Estendidas Permitir aos usuários de um cliente de portal gerar os arquivos de impressão das descrições que foram confeccionadas por meio do sistema. Atores: Usuário Pré-condição: Que o usuário esteja Fluxo Principal – Impressão de Descrições Estendidas 1. O caso de uso se inicia quando o usuário por imprimir alguma descrição estendida de um projeto. 2. O sistema exibe uma tela de impressão de descriçõ 3. O usuário executa o fluxo (#A1). 4. O usuário seleciona a opção que deseja executar. (#A2) (#A3) 5. O usuário pode retornar ao passo 3 quando vezes desejar. 6. Este caso de uso se encerra Fluxos Alternativos (#A1): Buscar Projeto 1. O ator deseja buscar um registro já existente e clica no botão “Buscar”. 2. O sistema exibe um dialogo de busca de projetos. 3. O ator preenche os filtros ou parte deles e clica no botão “Filtrar”. 4. O sistema realiza a busca na base de dados e trás os registros que conferem com os filtros passados. (#E2) 4.1. Alternativamente, o usuário pode retornar ao passo 3 e refazer sua busca. 5. O usuário seleciona o registro que deseja e clica no botão “Selecionar”. 5.1. Alternativamente o ator desiste da operação, clica no botão “Cancelar” e o sistema volta ao passo 3 do fluxo principal. 6. O registro selecionado é exibido na tela, e a lista de descrições estendidas é atualizada, listando todas as descrições do projeto selecionado. (#A2): Imprimir Descrição Estendida

 

 

185  

1. O ator seleciona a(s) descrição(s) que deseja imprimir e clica no botão “Menu Descrição/Imprimir”. 2. O sistema então gera a descrição no formato PDF e disponibiliza para download. 3. O sistema retorna ao ponto de chamada. (#A3): Visualizar Descrição Estendida 1. O usuário clica no botão “Menu Ações/Detalhar” e o sistema o redireciona para a tela de manutenção de DE, com o registro escolhido selecionado. Fluxo de Exceção (#E1): Não existe registro selecionado 1. O sistema desabilita a opções (#A2) (#A3) (#E2): Resultado de filtro vazio 1. Caso a busca não retorne nenhum registro, será exibida a mensagem “Nenhum registro foi encontrado”. Protótipos de Interface

 

 

 

186  

 

 

187  

 

188  

ANEXO B – MODELOS DE DESCRIÇÃO DE CASOS DE USO DE SOFTWARE Este modelo foi retirado do livro de Eduardo Bezerra. Princípios de Análise e Projeto de Sistemas com UML. Rio de Janeiro. Ed. Campus.

2003. Ele

apresenta a descrição de dois casos de uso: Realizar Inscrição de Aluno e Manter informações sobre Disciplinas. Realizar Inscrição de Aluno (CSU01) Sumário: Aluno usa o sistema para realizar inscrição em disciplina Ator Primário: Aluno Ator Secundário: Sistema de Faturamento Pré-condições: O aluno está identificado pelo sistema Fluxo Principal 1. O caso de uso inicia quando o aluno solicita a realização de inscrição. 2. O sistema apresenta as disciplinas disponíveis para o semestre corrente e para as quais o aluno tem pré-requisitos. 3. O aluno seleciona as disciplinas desejadas e as submete para inscrição. 4. Para cada disciplina selecionada, o sistema aloca o aluno em uma turma que apresente uma oferta para tal disciplina. 5. O sistema informa as turmas nas quais o aluno foi alocado. Para cada alocação, o sistema informa o professor, os horários e os respectivos locais das aulas de cada disciplina. 6. O aluno confere as informações fornecidas. 7. O sistema envia os dados sobre a inscrição do aluno para o Sistema de Faturamento e o caso de uso termina. Fluxo Alternativo (4): Inclusão em lista de espera a. Se não há oferta disponível para alguma disciplina selecionada pelo aluno, o sistema reporta o fato e fornece a possibilidade de inserir o aluno em uma lista de espera.

 

 

189   b. Se o aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o aluno foi inserido na lista. O caso de uso retorna ao passo 4. c. Se o aluno não aceitar, o caso de uso prossegue a partir do passo 4.

Fluxo de Exceção (4): Aluno atinge a quantidade máxima de inscrições a. Se o aluno atingiu a quantidade máxima de inscrições, o sistema informa ao aluno a quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2. Pós-condições: O aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi adicionado a uma ou mais lista de espera.

Tabela 34 – Template utilizado na Fábrica de Software do Grupo Europa Empreendimentos e Negócios

XXXNNX - Objetivos Protótipo da Interface

Interface com: Usuário

Tipo de Formulário

Comando

Funcionalidade

Posição

HOME

VIEW

Transição

Diagrama Funcional



Arquivos C R U D Restrições na camada de persistência X Campo da tela Obr RO Formato Atributo Arquivo Restrições Outras Camadas

Gatilho da Mensagem

Cod Mensagem

   

Tipo

Botões

 

190  

Objetivo Pré-req Restrições Pós-req Notas

Demanda e requisitos Tabela 35 – Modelo De Descrição utilizado para descrever o sistema TiEspec

ESP00A – Solicitação de Cadastro no Portal (Cliente Existente) Prover uma funcionalidade onde usuários possam se cadastrar no portal, e que o cliente ao qual pertencem já existe. Atores: Usuário Pré-condição: Que o usuário não esteja logado. Fluxo Principal – Solicitação de Cadastro no Portal (Cliente Existente) 1. O caso de uso se inicia quando o ator decide por se cadastrar no portal, e clica no botão de “Registrar”. 2. O sistema exibe uma tela com duas opções, uma com cliente já existente, e outra com cliente não existente; 3. O usuário seleciona a opção de cliente existente. 4. O sistema exibe um formulário de cadastro, com campos a preencher do novo do usuário e com os dados do cliente para visualização. 5. O cliente executa o fluxo (#A1). 6. O usuário preenche os dados do formulário e clica no botão ‘Salvar’. 6.1. Alternativamente ele pode clicar no botão ‘Cancelar’ e o caso de uso se encerra, voltando a tela inicial do portal. 7. O sistema faz a validação dos dados do formulário. (#E1) (#E2) 8. O sistema persiste os dados, envia um e-mail de confirmação para o email cadastrado e exibe uma mensagem de sucesso ao usuário. Os registros de Cliente de Portal e Usuário são criados com a situação de “Pendente Ativação E-mail”. 8.1. Alternativamente, caso ocorra algum erro neste processo, uma mensagem de falha é apresentada ao usuário, com o(s) respectivo(s) motivo. 10. O caso de uso se encerra.

 

 

191  

Fluxos Alternativos (#A1): Buscar Cliente de Portal 1. O sistema exibe um dialogo de busca de clientes de portal. 2. O usuário preenche os campos ou parte deles e clica no botão “Filtrar”. 3. O sistema executa a busca com os filtros passado pelo usuário e trás os resultados que batem com os mesmos. 4. O usuário seleciona o cliente na lista e clica no botão ‘Selecionar’. 4.1. Alternativamente, o usuário pode voltar ao passo 2 e refazer sua busca. 4.2. Alternativamente, o usuário pode clicar no botão cancelar e nenhuma ação é executada. 5. O sistema então mostra os dados básicos do cliente de portal selecionado na aba de Cliente. (#A2): Confirmação de E-mail 1. O usuário acessa o e-mail com o qual se cadastrou e clica no link de confirmação. 2. O link irá apontar para o sistema, este que ao receber a solicitação irá alterar a situação do Usuário para “Pendente Aprovação”. Fluxo de Exceção (#E1): Dados obrigatórios 1. Caso algum dado obrigatório não seja preenchido, o sistema exibe a mensagem “O campo ‘NomeCampo’ é obrigatório!”. 3. O caso de uso retorna ao passo 6 do fluxo principal. (#E2): E-mail Inválido 1. Se o e-mail informado pelo usuário não respeitar sua máscara, o sistema exibe a mensagem “O e-mail informado é inválido!”. 2. O caso de uso retorna ao passo 6 do fluxo principal. Interface