Especificacao Sistema de Controle Financeiro

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMÁTICA

INF01127 – Engenharia de Software N

Professor Sérgio Felipe Zirbes

Especificação de um sistema de controle

financeiro para lojas de Economia Solidária

Diego Francisco de Gastal MoralesLuís Fernando Heckler

Porto Alegre, junho de 2008

Sumário 1 Introdução....................................................................................................1

2 Metodologia..................................................................................................1

3 Participantes.................................................................................................2

3.1 Cliente....................................................................................................2

3.2 Analistas.................................................................................................2

3.3 Patrocinador............................................................................................2

4 Glossário......................................................................................................2

5 Cronograma..................................................................................................3

6 Escopo do sistema........................................................................................3

6.1 Diagrama Hierárquico de Funções – DHF.....................................................3

7 Casos de Uso................................................................................................5

7.1 Atores....................................................................................................5

7.2 Descrição................................................................................................5

7.2.1 Caso de Uso: Abrir o Caixa..................................................................5

7.2.2 Caso de Uso: Fechar o Caixa................................................................6

7.2.3 Caso de Uso: Comprar Itens................................................................6

7.2.4 Caso de Uso: Inicializar.......................................................................7

7.2.5 Caso de Uso: Gerenciar Cadastro de Pessoas..........................................7

7.2.6 Caso de Uso: Gerenciar Cadastro de Produtos........................................8

7.2.7 Caso de Uso: Realizar Encomenda........................................................8

7.2.8 Caso de Uso: Realizar Pedido...............................................................8

7.2.9 Caso de Uso: Realizar devolução..........................................................9

7.2.10 Caso de Uso: Pagar Associado............................................................9

7.2.11 Caso de Uso: Rodar Folha de Pagamento............................................10

7.2.12 Caso de Uso: Emitir relatórios...........................................................10

7.3 Diagrama de Casos de Uso......................................................................10

8 Modelo conceitual........................................................................................12

9 Diagramas de Interação................................................................................13

9.1 Diagrama de Seqüência – Caso de Uso Abrir o Caixa...................................13

9.2 Diagrama de Seqüência – Caso de Uso Fechar o Caixa................................13

9.3 Diagrama de Seqüência – Caso de Uso Inicializar.......................................13

Instituto de Informática

9.4 Diagrama de Seqüência – Caso de Uso Realizar Encomenda.........................14

9.5 Diagrama de Seqüência – Caso de Uso Realizar Pedido................................15

9.6 Diagrama de Seqüência – Caso de Uso Comprar Itens.................................15

10 Diagrama de Classes..................................................................................16

11 Gerência de Projetos..................................................................................16

11.1 Estimativas de esforço, prazo e custo......................................................17

11.1.1 Cálculo do peso não-ajustado dos atores – UAW..................................17

11.1.2 Cálculo do peso não-ajustado dos Casos de Uso – UUCW......................17

11.1.3 Cálculo dos pontos não-ajustados dos Casos de Uso - UUCP.................18

11.1.4 Cálculo do fator de ajuste técnico – Tfactor........................................18

11.1.5 Cálculo do Fator de Complexidade Técnica - TCF.................................19

11.1.6 Cálculo do Fator de Ajuste de Ambiente – Efactor................................19

11.1.7 Cálculo do Fator de Complexidade de Ambiente – ECF..........................19

11.1.8 Cálculo dos Pontos por Caso de Uso – UCP.........................................19

11.1.9 Cálculo do tempo de trabalho estimado..............................................19

11.1.10 Estimativa de custo.......................................................................20

11.1.11 Estimativa de prazo.......................................................................20

12 Ferramentas utilizadas................................................................................20

13 Conclusão.................................................................................................23

14 Referências...............................................................................................24

15 Anexos.....................................................................................................25

15.1 Anexo A – Ata de reunião de início do projeto...........................................25

- 3 -

Lista de FigurasFigura 1: Diagrama Hierárquico de Funções..........................................................4

Figura 2: Atores do sistema................................................................................5

Figura 3: Diagrama de Casos de Uso..................................................................11

Figura 4: Modelo Conceitual do sistema..............................................................12

Figura 5: Diagrama de Seqüência – UC Abrir o Caixa............................................13

Figura 6: Diagrama de Seqüência – UC Fechar o Caixa.........................................13

Figura 7: Diagrama de Seqüência – UC Inicializar................................................14

Figura 8: Diagrama de Seqüência – UC Realizar Encomenda..................................14

Figura 9: Diagrama de Seqüência – UC Realizar Pedido.........................................15

Figura 10: Diagrama de Seqüência – UC Comprar Itens........................................15

Figura 11: Diagrama de classes.........................................................................16

Figura 12: Ferramenta CASE Umbrello................................................................21

Figura 13: Ferramenta CASE Visual Paradigm UML...............................................22

Lista de Tabelas e QuadrosTabela 1: Cronograma da etapa de análise do projeto............................................3

Tabela 2: Diagrama Hierárquico de Funções - DHF.................................................4

Tabela 3: Cálculo do peso não-ajustado dos atores...............................................17

Tabela 4:Classificação dos Casos de Uso do sistema.............................................18

Tabela 5:Cálculo do peso não-ajustado dos casos de uso - UUCW...........................18

Tabela 6: Cálculo do Fator de Ajuste Técnico - TFactor..........................................18

Tabela 7: Cálculo do Fator de Ajuste de Ambiente – Efactor...................................19


1 Introdução

Como trabalho prático da presente disciplina, apresentamos a especificação completa de um sistema financeiro destinado à automação comercial para lojas que trabalham no conceito de Economia Solidária. O objetivo principal é o exercício da prática de todas as etapas envolvidas na especificação de sistemas computacionais, balizado pelos conhecimentos adquiridos ao longo desta disciplina. Para tanto, o sistema envolvido não deve ser complexo a ponto de confundir-se com a complexidade intrínseca do processo de aprendizado inerente à prática desta nova atividade.

Desta forma, nossa escolha de tema fundamenta-se no fato de que sistemas de automação comercial são sistemas já tradicionais, geralmente com requisitos bem definidos, o que torna o assunto mais fácil de ser aplicado para fins didáticos. Ao mesmo tempo, a escolha pela busca da adaptação para o segmento de Economia Solidária traz a necessidade de identificação de novos parâmetros do sistema, extrapolando a dimensão do teórico. O tema é atual, cada vez mais presente na realidade brasileira, e merece atenção por parte da área de informática, podendo-se constituir uma oportunidade de mercado.

Sobre o tema Economia Solidária, da enciclopédia eletrônica Wikipedia temos que:

a economia solidária é um modo específico de organização de atividades econômicas, que se caracteriza pela autogestão, ou seja, pela autonomia de cada unidade ou empreendimento e pela igualdade entre os seus membros.

Esta é apenas uma descrição breve, o conceito é muito mais amplo e sua discussão não é foco deste trabalho. Maiores informações sobre o tema podem ser obtidas nos sítios eletrônicos listados na seção de referências deste trabalho.

2 Metodologia

A área de Engenharia de Software tem sido desenvolvida amplamente nos últimas anos, instigada pela crescente necessidade de buscar-se uma melhor otimização dos recursos envolvidos e uma maior clareza dos artefatos de documentação dos sistemas. As demandas de mercado requerem cronogramas de desenvolvimento com prazos cada vez mais exíguos, custos enxutos, flexibilidade e agilidade de atendimento, além de alto índice de qualidade do produto entregue, não havendo, portanto, espaço para retrabalho ou atrasos. Desta forma fica latente a necessidade de utilizar-se técnicas que desonerem as empresas de desenvolvimento de software, possibilitem ciclos de desenvolvimento mais curtos e retirem o conhecimento das pessoas, trazendo-o para a organização.

Assim, neste trabalho abordaremos a metodologia de Análise e Projeto Orientados a Objetos, com ênfase no uso da Linguagem de Modelagem Unificada (UML em inglês).

Conforme indicado nas aulas e referências da disciplina, procederemos com a análise dos requisitos, identificação e redação dos casos de uso do sistema, e seu posterior detalhamento por meio dos demais diagramas da UML. Note-se porém que neste trabalho serão implementadas apenas as atividades de análise do sistema, não sendo portanto executadas nenhuma das etapas de desenvolvimento e testes previstas no processo de desenvolvimento iterativo.

- 1 -


3 Participantes

Nesta seção indicamos os principais papéis participantes do projeto, nomeando claramente seus representantes, tanto por parte do cliente interessado como por parte da equipe de desenvolvimento.

3.1 Cliente

A cliente e fornecedora de requisitos é Fabiana Thomé da Cruz, engenheira de alimentos, mestre em Agroecossistemas, colaboradora do Núcleo de Economia Alternativa desta universidade (NEA/UFRGS). Este núcleo trabalha diretamente com as questões da Economia Solidária em Porto Alegre e no Brasil de um modo geral.

3.2 Analistas

Os analistas do sistema são os graduandos em Ciência da Computação Diego Francisco de Gastal Morales e Luís Fernando Heckler.

3.3 Patrocinador

O patrocinador do projeto é o professor Dr. Sérgio Felipe Zirbes, professor ministrante desta disciplina de Engenharia de Software, não no sentido de subsidiador financeiro mas tecnológico e como principal incentivador do projeto.

4 Glossário

De forma a unificar os conceitos inerentes ao domínio da aplicação, é importante definir um glossário comum ao projeto, conforme segue.

● colaborador: representa um funcionário da loja;

● associado: representa um fornecedor de um ou mais produtos, sejam estes sob consignação ou venda;

● produto: representa um bem comercializado na loja, perecível ou não;

- 2 -


5 Cronograma

Como cronograma de trabalho para esta etapa de análise temos:

Marco Data

Definição do assunto e usuário cliente 18 de março

Definição do escopo (DHF) 01 de abril

Diagramas de Caso de Uso 29 de abril

Modelo Conceitual 06 de maio

Diagramas de Interação (Seqüência de Casos de Uso ou Colaboração)

05 de junho

Modelo de Classes/Objetos 19 de junho

Apresentação do trabalho 24 de junho

Entrega da especificação completa 26 de junho

Tabela 1: Cronograma da etapa de análise do projeto

6 Escopo do sistema

Conforme mencionado anteriormente, o escopo deste trabalho compreenderá a especificação de um sistema de controle financeiro para lojas que trabalhem com o conceito de Economia Solidária. O presente documento de especificação é o artefato de saída previsto para este trabalho de análise e modelagem.

O sistema deverá prever as seguintes funcionalidades, conforme descrito no diagrama hierárquico de funções a seguir.

6.1 Diagrama Hierárquico de Funções – DHF

Neste diagrama, apresentamos as funcionalidades básicas que especificamos para o sistema, e suas interdependências. É preciso notar no entanto, que esta hierarquia apresentada não tem necessariamente um mapeamento direto para os menus, classes ou quaisquer componentes da aplicação. Neste diagrama estamos efetivamente analisando em nível funcional o sistema, em um nível mais alto de abstração, distante do nível de detalhes da implementação.

A primeira versão do DHF elaborada pelos analistas é exibida na figura 1 a seguir. Esta versão foi apresentada para o cliente em reunião, quando foi refinada, originando uma segunda versão do diagrama, que apresentamos sob a forma de estrutura de tópicos logo a seguir.

- 3 -


Após a primeira reunião com o cliente, refinamos o diagrama e podemos agora estender esta visão das funções planejadas para o sistema, numerando-as segundo sua posição hierárquica e apresentando-as de forma a facilitar a sua referência nos diagramas e descrições do sistema que seguirão mais adiante. O quadro a seguir apresenta o Diagrama Hierárquico de Funções em um formato mais detalhado.

Ref. Função Prioridade

1 Controle financeiro Alta

1.1 Caixa Alta

1.2 Pagamentos Alta

1.3 Folha de pagamento Baixa

2 Controle de Estoque Alta

2.1 Entrada / Saída Alta

3 Cadastros gerais Alta

3.1 Colaboradores Média

3.2 Associados Alta

3.3 Produtos Alta

4 Relatórios Média

4.1 Fluxo de caixa Média

4.2 Agenda financeira Média

4.3 Balanço Baixa

4.4 Retorno FAURGS Baixa

4.5 Encomendas Baixa

5 Encomendas Baixa

5.1 Controle Baixa

Tabela 2: Diagrama Hierárquico de Funções - DHF

- 4 -

Figura 1: Diagrama Hierárquico de Funções


7 Casos de Uso

7.1 Atores

Segundo Craig Larman,

um ator é uma entidade externa ao sistema que, de alguma maneira, participa da história do caso de uso (Larman, 2004).

Um ator integra-se ao caso de uso, estimulando o sistema com eventos de entrada ou recebendo eventos de saída. No caso deste sistema, como não há integração com outros sistemas computacionais, os atores identificados representam perfis de usuários do mesmo, mas deve-se ressaltar que os atores devem ser vistos como papéis do sistema, não necessariamente vinculados a pessoas reais.

Os atores identificados no sistema são mostrados na figura abaixo.

Conforme podemos observar na figura, para fins de maior clareza no diagrama de casos de uso, temos o ator 'Colaborador' que representa a generalização de um usuário do sistema, e que por sua vez especializa-se nos atores 'Administrador' e 'Operador', representando respectivamente o usuário administrador do sistema e o usuário com privilégios de acesso normais.

7.2 Descrição

A partir da definição do escopo do sistema por meio do diagrama hierárquico de funções, procedemos com o levantamento dos requisitos do sistema e de seu refino, por meio da identificação dos seus Casos de Uso.

Os Casos de Uso mais simples são descritos no formato de alto nível, enquanto que os mais complexos são descritos em seu formato expandido. (Note que as referências de cada Caso de Uso são relativas ao DHF apresentado anteriormente neste documento.)

7.2.1 Caso de Uso: Abrir o CaixaAtores: ColaboradorFinalidade: Habilitar movimentações financeiras no sistema, conferindo, ajustando e

registrando a quantidade de dinheiro em caixa.

- 5 -

Figura 2: Atores do sistema


Descrição: Colaborador abre o caixa no início do dia, conferindo dinheiro presente no caixa, e opcionalmente adicionando mais dinheiro (caixa pode estar vazio). Sistema fica pronto para registrar compras.

Tipo: Primário e essencial.Referências: 1.1, 4.1

Seqüência Típica de Eventos:1.Colaborador indica ao sistema a abertura do caixa.2.Sistema exibe o valor que deve estar presente no caixa conforme o que foi armazenado no último fechamento.3.Colaborador confere o valor, contando o dinheiro no caixa.4.Colaborador informa o valor que será adicionado ao caixa e confirma abertura.5.Sistema calcula o novo valor total em caixa, armazena o valor para ser usado no próximo fechamento, e apresenta o valor na tela. Todas operações do sistema que envolvam movimentação de dinheiro no caixa são habilitadas.

7.2.2 Caso de Uso: Fechar o CaixaAtores: ColaboradorFinalidade: Encerrar movimentações no caixa ao final do dia, conferindo o valor e

recolhendo parte ou todo o valor presente no caixa.Descrição: Colaborador fecha o caixa no final do dia, conferindo o dinheiro presente

no caixa, e removendo parte ou todo o dinheiro do caixa. Sistema não aceita qualquer transação financeira até a reabertura do caixa.

Tipo: Primário e essencial.Referências: 1.1, 4.1

Seqüência Típica de Eventos:1.Colaborador indica ao sistema o fechamento do caixa.2.Sistema calcula valor que deve estar em caixa de acordo com o valor da abertura do caixa e transações efetuadas durante o dia. Apresenta o valor na tela.3.Colaborador confere o valor, contando o dinheiro no caixa.4.Colaborador informa o valor que será recolhido do caixa e confirma fechamento.5.Sistema calcula valor restante no caixa, armazena o valor para ser usado na próxima abertura, e apresenta o valor na tela. Todas operações do sistema que envolvam movimentação de dinheiro no caixa são desabilitadas.

7.2.3 Caso de Uso: Comprar ItensAtores: Colaborador, Cliente (iniciador)Finalidade: Registra a compra e auxiliar atores durante o processo, fazendo

cálculos, exibindo informações e gerando os registros necessários.Descrição: Cliente deseja comprar itens da loja. Este itens foram recolhidos pelo

próprio cliente das estantes da loja e/ou selecionados com a ajuda de um colaborador. Por simplicidade, é considerado possível apenas o pagamento em dinheiro.

Tipo: Primário e essencial.Referências: 1.1, 2.1, 4.1, 4.3

Seqüência Típica de Eventos:1.Após selecionar itens (com ou sem ajuda de um colaborador), Cliente se dirige a um colaborador para realizar a compra.2.Colaborador inicia uma nova compra no sistema.

- 6 -


3.Colaborador digita código do item, e sua quantidade (caso maior que 1) no sistema.4.Sistema adiciona a descrição do item, quantidade, preço unitário e total, à lista de itens na compra, e exibe soma parcial da compra.Colaborador repete passo 3 e 4 para todos os itens selecionados pelo cliente.5.Colaborador fecha a compra no sistema, informa ao cliente o valor total. Sistema aguarda indicação de pagamento.6.Cliente entrega dinheiro para o colaborador.7.Colaborador informa valor fornecido pelo Cliente, sistema calcula o troco, e aguarda confirmação para emitir recibo e registrar a compra.8.Colaborador recolhe o troco, confirma para o sistema, que emite recibo e registra compra no histórico. Colaborador entrega troco, recibo e itens ao cliente.

Seqüências Alternativas de Eventos:*a. A qualquer momento antes do passo 8, cliente muda de idéia sobre a seleção de itens.

*a.1. Colaborador corrige a lista de itens de compra conforme necessário.*b. A qualquer momento antes do passo 8, cliente informa que deseja cancelar a compra.

*b.1. Colaborador cancela a compra no sistema, caso esta tenha sido iniciada.3a. Colaborador não sabe qual o código do item.

3a.1. Colaborador inicia pesquisa no catálogo de produtos, por palavras na descrição do item.

3a.2. Sistema apresenta lista de itens que têm na descrição as palavras informadas.3a.3. Colaborador escolhe item da lista, ou refaz a pesquisa com outras palavras.3a.4. Sistema retorna código e insere item na lista de compra, permitindo que

Colaborador defina a quantidade.4a. Código não existe.

4a.1. Sistema informa o erro, e espera por novo código.4b. Código foi digitado errado, descrição apresentada não é a o do item selecionado.

4b.1. Colaborador remove o item errado.4c. Quantidade de itens foi digitada errada.

4c.1. Colaborador corrige a quantidade do item na lista de compras.6a. Cliente informa que não tem dinheiro suficiente.

6a.1. Colaborador pergunta se cliente quer retirar algum item ou cancelar a compra, corrigindo a lista (passo *a.1) ou cancelando a compra (passo *b.1) conforme a resposta.7a. Colaborador informa para o sistema um valor menor que o total da compra.

7a.1. Sistema exibe um alerta indicando o problema, e aguarda nova indicação de pagamento.

7.2.4 Caso de Uso: InicializarAtores: ColaboradorFinalidade: Deixar sistema pronto para uso e identificar utilizador.Descrição: Colaborador lança o sistema a partir do SO, e identifica-se usando

usuário e senha (faz login no sistema).Tipo: Secundário e essencial.Referências:

7.2.5 Caso de Uso: Gerenciar Cadastro de PessoasAtores: AdministradorFinalidade: Controlar dados de colaboradores e associados.

- 7 -


Descrição: Administrador necessita criar, alterar ou remover Colaboradores ou Associados no cadastro do sistema (CRUD).

Tipo: Secundário e essencial.Referências: 3.1, 3.2

7.2.6 Caso de Uso: Gerenciar Cadastro de ProdutosAtores: ColaboradorFinalidade: Controlar informações de produtos.Descrição: Colaborador necessita criar, alterar ou remover Produtos no cadastro do

sistema, incluindo-se aqui o ajuste manual de quantidades em estoque (CRUD).

Tipo: Secundário e essencial.Referências: 2.1, 3.3, 5.1

7.2.7 Caso de Uso: Realizar EncomendaAtores: Cliente, ColaboradorFinalidade: Implementar o processo de registro de uma encomenda feito pelo

cliente.Descrição: Um cliente informa ao colaborador da loja que deseja realizar uma

encomenda de um produto. Estando autenticado no sistema, o colaborador verifica se a loja trabalha com o referido produto. Caso sim, verifica o cadastro do cliente, verifica se o produto não encontra-se disponível na quantidade e características solicitadas e registra a encomenda.

Tipo: Secundário e essencialReferências: 3.3, 5.1

Seqüência Típica de Eventos:1.Cliente informa que produtos deseja encomendar;2.Colaborador acessa o sistema e verifica no cadastro de produtos se a loja trabalha com cada um dos produtos solicitados;3.Para cada produto, Colaborador verifica que não está disponível em estoque na quantidade e características desejadas;4.Colaborador registra no sistema o pedido de encomenda do produto, na quantidade e características desejadas, associando-o ao cadastro do cliente;

Seqüências alternativas de eventos:2a. Colaborador verifica que existe em estoque o produto em quantidade e características desejadas;

2a.1. Colaborador informa ao Cliente que pode realizar a compra do produto;2a.2. Cliente aceita comprar o produto;2a.3. Colaborador dá início ao Caso de Uso Comprar Itens;

7.2.8 Caso de Uso: Realizar PedidoAtores: Colaborador, AssociadoFinalidade: Implementar o processo de efetivação de um pedido de fornecimento de

produto, a partir do registro de uma encomenda.

- 8 -


Descrição: Estando autenticado no sistema, o Colaborador, a partir do registro de uma encomenda, confirma a quantidade e características de cada produto encomendado, escolhendo qual fornecedor deverá fornecer qual produto e em que quantidade, dentre os fornecedores registrados para cada produto. Ao final, é emitido um relatório na tela com a agenda de contatos que o que Colaborador deve realizar junto aos associados para encomendar o pedido.

Tipo: Primário e essencialReferências: 3.3, 5.1

Seqüência Típica de Eventos:1.Colaborador acessa o sistema e verifica as encomendas registradas;2.Para cada encomenda, confirma as quantidades e características, e registra a escolha de um dentre os associados fornecedores possíveis;3.Sistema emite um relatório informando cada associado que deve ser contatado e para este, quais produtos, quantidades e características que devem ser encomendados;4.Após contatar cada associado, Colaborador atualiza o registro da encomenda com a data prevista de entrega informada pelo fornecedor.

7.2.9 Caso de Uso: Realizar devoluçãoAtores: Colaborador, AssociadoFinalidade: Implementar o processo de devolução de produtos para um dado

associado.Descrição: O Colaborador verifica que existem na loja produtos perecíveis,

adquiridos em consignação, que estão com o prazo de validade por vencer em poucos dias. O Colaborador recolhe os produtos e, estando autenticado no sistema, registra o pedido de devolução no sistema, inserindo os códigos de registro dos produtos. Ao final, é emitido um relatório na tela com a agenda de contatos que o Colaborador deve realizar junto aos associados responsáveis pelos produtos em questão.

Tipo: Secundário e opcional.Referências: 2.1

7.2.10 Caso de Uso: Pagar AssociadoAtores: Colaborador, AssociadoFinalidade: Implementar o processo de pagamento de valores devidos a associados,

de acordo com as encomendas recebidas e produtos consignados que foram vendidos.

Descrição: Estando autenticado no sistema, o Colaborador escolhe um associado no módulo de pagamentos, e o sistema informa quais os valores devidos àquela associado em função das vendas de produtos consignados ou do vencimento de encomendas recebidas. O Colaborador marca e confirma os pagamentos que deseja efetivar, e o sistema atualiza o balanço financeiro. Caso o pagamento seja realizado por via bancária, é solicitado ao Colaborador que informe os dados da transação bancária realizada. Ao final, é emitido recibo com a discriminação do pagamento, a ser impresso e assinado pelo associado.

Tipo: Secundário e essencial.

- 9 -


Referências: 1.2, 3.2

7.2.11 Caso de Uso: Rodar Folha de PagamentoAtores: Administrador, ColaboradorFinalidade: Implementar o processo de pagamento a colaboradores.Descrição: Estando autenticado no sistema, o Administrador seleciona o módulo de

pagamento de colaboradores. O sistema calcula os valores e emite recibos a serem impressos e assinados por cada colaborador. Ao final, o sistema gera um relatório com os valores pagos a cada colaborador, com a discriminação dos tributos a serem recolhidos.

Tipo: Secundário e essencial.Referências: 1.3, 3.1

7.2.12 Caso de Uso: Emitir relatóriosAtores: ColaboradorFinalidade: Implementar a emissão de relatórios diversos pelo sistema.Descrição: Estando autenticado no sistema, o Colaborador acessa o módulo de

relatórios e seleciona um dentre os relatórios disponíveis. O sistema processa o relatório escolhido e o exibe na tela.

Tipo: Secundário e opcional.Referências: 4.1, 4.2, 4.3, 4.4, 4.5

7.3 Diagrama de Casos de Uso

A partir da identificação e descrição dos Casos de Uso do sistema, como forma de aumentar o poder de expressão e compreensão, apresentamos a seguir o relacionamentos entre os Casos, na forma do Diagrama de Casos de Uso.

- 10 -


- 11 -

Figura 3: Diagrama de Casos de Uso


8 Modelo conceitual

Neste diagrama apresentamos um esboço dos principais conceitos do sistema, agora descritos como classes candidatas, já traçando os seus relacionamentos e descrevendo alguns de seus atributos.

- 12 -

Figura 4: Modelo Conceitual do sistema


9 Diagramas de Interação

9.1 Diagrama de Seqüência – Caso de Uso Abrir o Caixa

9.2 Diagrama de Seqüência – Caso de Uso Fechar o Caixa

9.3 Diagrama de Seqüência – Caso de Uso Inicializar

- 13 -

Figura 5: Diagrama de Seqüência – UC Abrir o Caixa

Figura 6: Diagrama de Seqüência – UC Fechar o Caixa


9.4 Diagrama de Seqüência – Caso de Uso Realizar Encomenda

- 14 -

Figura 7: Diagrama de Seqüência – UC Inicializar

Figura 8: Diagrama de Seqüência – UC Realizar Encomenda


9.5 Diagrama de Seqüência – Caso de Uso Realizar Pedido

- 15 -

Figura 9: Diagrama de Seqüência – UC Realizar Pedido


9.6 Diagrama de Seqüência – Caso de Uso Comprar Itens

10

11 Diagrama de Classes

- 16 -

Figura 10: Diagrama de Seqüência – UC Comprar Itens


12 Gerência de Projetos

Entramos agora numa etapa não técnica do projeto, mas não menos importante, que são os aspectos de gerência do projeto. Segundo o professor Zirbes,

projeto é um empreendimento não repetitivo, caracterizado por uma seqüência lógica e clara de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.

Desta forma apresentamos os tópicos mínimos de gerência deste projeto, no que tange os aspectos de estimativa de esforço, prazo e custo.

É preciso ressaltar, porém, que não é foco deste trabalho apresentar minúcias, portanto, não substituindo a necessidade de elaborar-se o Plano de Projeto, que é o

- 17 -

Figura 11: Diagrama de classes


documento completo de definição do projeto e de todos os aspectos de gerência envolvidos.

12.1 Estimativas de esforço, prazo e custo

Existem diversos métodos propostos para buscar maior precisão nas estimativas de um projeto, uma vez que o sucesso de um projeto depende também da correta noção de tamanho e custo envolvidos. Neste trabalho aplicaremos o método de estimativas de Pontos por Casos de Uso.

Este método foi proposto por Gustav Karner em 1993, com base em outro método muito conhecido: a Análise por Pontos de Função. Consiste, basicamente, em estimar o tamanho do sistema de acordo com o modo como será utilizado, a complexidade das ações requeridas por cada tipo de usuário e de acordo com a complexidade dos passos necessários para realizar cada tarefa. Utilizando este método é possível estimar o tamanho do sistema já na fase de levantamento de Casos de Uso (Zirbes, 2008).

12.1.1 Cálculo do peso não-ajustado dos atores – UAWAnalisando os atores identificados no sistema, temos a seguinte classificação de

complexidade, conforme exibido na tabela a seguir.

Tipo de Ator Peso Nº de Atores Resultado

Ator simples 1 0 0

Ator Médio 2 0 0

Ator Complexo 3 2 6

TOTAL UAW 6

Tabela 3: Cálculo do peso não-ajustado dos atores

12.1.2 Cálculo do peso não-ajustado dos Casos de Uso – UUCWPara procedermos com o cálculo do UUCW, primeiramente é preciso classificar os

casos de uso segundo sua complexidade, conforme segue.

Caso de Uso Complexidade

Abrir o caixa Simples

Fechar o caixa Simples

Comprar itens Complexo

Inicializar Simples

Gerenciar Cadastro de Pessoas Simples

Gerenciar Cadastro de Produtos Simples

Realizar Encomenda Médio

Realizar Pedido Simples

Realizar devolução Simples

Pagar Associado Simples

Rodar Folha de Pagamento Simples

Emitir relatórios Simples

- 18 -


Tabela 4:Classificação dos Casos de Uso do sistema

A partir da análise dos casos de uso, procedemos com a aplicação dos pesos, segundo recomendado pelo método.

Tipo Peso Nº de Casos de Uso Resultado

Simples 5 10 50

Médio 10 1 10

Complexo 15 1 15

TOTAL UUCW 75

Tabela 5:Cálculo do peso não-ajustado dos casos de uso - UUCW

12.1.3 Cálculo dos pontos não-ajustados dos Casos de Uso - UUCPSegundo o método, UUCP = UAW + UUCW. Logo, para nosso projeto temos:

UUCP = 6 + 75 = 81

12.1.4 Cálculo do fator de ajuste técnico – TfactorPara cada requisito listado na tabela, é atribuído um valor que representa a nossa

visão da influência do requisito no sistema, variando de 0 a 5, conforme segue.

Fator Requisito Peso Influência Resultado

T1 Sistema distribuído 2 0 0

T2 Tempo de resposta 2 3 6

T3 Eficiência 1 3 3

T4 Processamento complexo 1 1 1

T5 Código reusável 1 0 0

T6 Facilidade de instalação 0,5 3 1,5

T7 Facilidade de uso 0,5 5 2,5

T8 Portabilidade 2 0 2

T9 Facilidade de mudança 1 5 5

T10 Concorrência 1 3 3

T11 Recursos de segurança 1 3 3

T12 Acessível por terceiros 1 0 0

T13 Requer treinamento especial

1 1 1

TFactor 28

Tabela 6: Cálculo do Fator de Ajuste Técnico - TFactor

12.1.5 Cálculo do Fator de Complexidade Técnica - TCFSegundo o método, temos que TCF = 0,6 + (0,01 * Tfactor). Logo, para nosso

projeto temos que:

- 19 -


TCF = 0,6 + (0,01 * Tfactor) = 0,6 + (0,01 * 28) = 0,88

12.1.6 Cálculo do Fator de Ajuste de Ambiente – EfactorPara cada requisito listado na tabela, é atribuído um valor que representa a nossa

visão da influência do requisito no sistema, variando de 0 a 5, conforme segue.

Fator Requisito Peso Influência Resultado

E1 Familiaridade com RUP ou outro processo formal

1,5 5 7,5

E2 Experiência com a aplicação em

desenvolvimento

0,5 0 0

E3 Experiência em Orientação a Objetos

1 3 3

E4 Presença de analista experiente

0,5 4 2

E5 Motivação 1 5 5

E6 Requisitos estáveis 2 5 10

E7 Desenvolvedores em meio-expediente

-1 5 -5

E8 Linguagem de programação difícil

2 2 4

EFactor 26,5

Tabela 7: Cálculo do Fator de Ajuste de Ambiente – Efactor

12.1.7 Cálculo do Fator de Complexidade de Ambiente – ECFPelo método temos ECF = 1,4 + (-0,03 * Efactor). Logo, para nosso projeto temos

que:

ECF = 1,4 + (-0,03 * Efactor) = 1,4 + (-0,03 * 26,5) = 0,605

12.1.8 Cálculo dos Pontos por Caso de Uso – UCPPelo método temos UCP = UUCP * TCF * ECF. Logo, para nosso projeto temos que:

UCP = UUCP * TCF * ECF = 81 * 0,88 * 0,605 = 43,12 = 43 UCPs

12.1.9 Cálculo do tempo de trabalho estimadoSeguindo a recomendação da bibliografia, consideraremos uma média de 20 horas

de trabalho por Ponto de Caso de Uso. Logo, para nosso projeto temos que:

Tempo estimado = 43 * 20 = 860 horas de trabalho

12.1.10 Estimativa de custoDe acordo com o mercado, consideraremos uma média de R$50,00 por hora de

desenvolvimento. Adicionalmente vamos aplicar um fator próprio de margem de risco de 10% sobre o custo estimado, tendo por tando a estimativa de custo do projeto em:

860 * R$50 + 10% = R$47.300,00

- 20 -


12.1.11 Estimativa de prazoConsiderando a equipe atual, em que os dois analistas farão também o papel de

desenvolvedores, a estimativa de 860 horas de trabalho divide-se em 430 horas por desenvolvedor, o resulta em aproximadamente 5,3 meses de trabalho (considerando-se uma carga horária de 4 horas diárias).

13 Ferramentas utilizadas

Em um projeto orientado a objetos moderno, onde os tempos de trabalho devem ser maximizados ao máximo, o uso de recursos computacionais adequados mostra-se um diferencial competitivo para a equipe de desenvolvimento. Os projetos sempre enfrentam mudanças no decorrer do desenvolvimento, e nestas horas o apoio de uma ferramenta que auxilie na refatoração dos diagramas de modelagem pode significar um ganho de agilidade crucial para o sucesso do projeto.

Inicialmente para este projeto experimentamos a utilização de duas ferramentas de apoio ao uso de UML:

Umbrello UML Modeler

http://uml.sourceforge.net/

Visual Paradigm for UML – Community Edition

http://www.visual-paradigm.com/

Ambas as ferramentas mostraram-se interessantes. A ferramenta Umbrello tem a vantagem de ser software livre e de ser uma aplicação leve, com os recursos essenciais à modelagem em UML. Já a ferramenta da Visual Paradigm oferece opções mais robustas para o desenvolvimento completo dentro da IDE, porém em alguns momentos mostrando-se por demais “pesada” para as necessidades deste trabalho. Apresenta pontos fortes tais como boa apresentação visual e dinâmica na hora de movimentar e alterar os diagramas; possuir templates para todos os diagramas da UML (com exceção de não possuir template específico para modelagem conceitual); e sincroniza entre diagramas de seqüência e de comunicação (gera um a partir do outro).

Conforme o avanço do trabalho, a necessidade de gerar os diagramas mais complexos fez com que optássemos pela ferramenta Visual Paradigm, por contar com mais recursos que facilitam a elaboração e alteração dos diagramas. Porém, é importante ressaltar que a versão “community” da ferramenta, que é a versão gratuita, restringe a criação de apenas um diagrama de cada tipo, ou coloca marcas d'água nos diagramas caso você opte por criar mais de um do mesmo tipo uma única vez (as marcas são mantidas mesmo que os diagramas extras sejam excluídos). Desta forma, tivemos de nos adaptar e salvar uma nova cópia do arquivo onde modelamos o diagrama conceitual, para poder então transformá-lo no diagrama de classes, uma vez que a ferramenta não apresenta um diagrama exclusivo para a modelagem conceitual. Também a modelagem dos diagramas de comunicação requereu este artifício. O uso deste artifício porém, nos impediu de aproveitar recursos como a geração automática do modelo de classes a partir dos diagramas

- 21 -


anteriores. O “peso” da aplicação também se fez sentir no consumo muito alto de memória (centenas de megabytes) em alguns momentos de trabalho mais intenso na ferramenta.

Nossa recomendação então é de que Visual Paradigm Community Edition seja usado apenas nos casos mais triviais e descartáveis, pois traz bastantes inconveniências mesmo para os projetos mais simples, já que normalmente qualquer projeto exige múltiplos diagramas do mesmo tipo. No entanto, quando for possível investir o dinheiro necessário para aquisição da versão comercial, ela pode se tornar uma alternativa interessante, não esquecendo de que é uma ferramenta bastante complexa e pesada, que exige algum tempo de aprendizado/treinamento para ser utilizada a pleno.

Figura 12: Ferramenta CASE Umbrello

- 22 -


Figura 13: Ferramenta CASE Visual Paradigm UML

- 23 -


14 Conclusão

Nesta disciplina e neste trabalho pudemos compreender como e porque a análise e projeto de sistemas informatizados é um processos tão importante para o desenvolvimento de software. Foi talvez a primeira vez durante o nosso curso que tivemos explicitamente a tarefa de pensar e projetar detalhadamente uma solução, antes de realizá-la, e a nossa inexperiência nessa abordagem nos trouxe dificuldades. Além de nos obrigar a pensar antes de agir, esse processo nos leva a definir soluções mais abstratas e genéricas, independentes da implementação que será utilizada, mas ainda assim suficientemente detalhadas para que nenhum aspecto do problema em questão fique de fora.

Essa necessidade de abstração com atenção a detalhes, somada às dificuldades de compreender e responder aos anseios do cliente, e ainda às dificuldades naturais do projeto em questão e da coordenação de um trabalho em equipe, tornam a análise e projeto de software uma tarefa certamente complexa, onde a experiência é fundamental, mas sem dispensar a necessidade de criatividade.

Por isso é notável a importância desta disciplina para o currículo do nosso curso, permitindo ao aluno iniciar-se nessa área, e adquirir nela uma experiência singela, porém já muito importante.

Dentre as dificuldades que tivemos, destacamos: a busca pelas doses certas de abstração e detalhismo em cada etapa do processo; a comunicação com o cliente, de forma a evitar mal-entendidos e aproveitar ao máximo os encontros; a necessidade de ficar atualizando diagramas e outras documentações conforme nosso entendimento do projeto – e conseqüentemente, o modelo proposto – ia sendo refinado e alterado.

Dificuldades como esta última podem ser bastante dirimidas pelo uso de uma ferramenta adequada de apoio ao processo de modelagem. Nesse ponto, como foi destacado anteriormente, nossa experiência esteve dividida entre extremos, com uma ferramenta muito simples (o Umbrello), e outra muito complexa (o Visual Paradigm for UML Community Edition). Cabe salientar que nossa experiência com a última foi bastante prejudicada pelo uso da licença gratuita, que tem algumas limitações importantes. Ficou muito claro para nós que o uso de uma ferramenta de apoio adequada é indispensável.

- 24 -


15 Referências

Wikipedia – Economia Solidária, acessado em Junho/2008http://pt.wikipedia.org/wiki/Economia_solid%C3%A1ria

Wikipedia - UMLhttp://pt.wikipedia.org/wiki/UML

Wikepedia – Categoria Engenharia de Softwarehttp://pt.wikipedia.org/wiki/Categoria:Engenharia_de_software

Grupo de Pesquisa de Economia Solidária – UNISINOS, acessado em Junho/2008http://www.ecosol.org.br/

Rede EcoSoLivre, acessado em Junho/2008http://twiki.softwarelivre.org/bin/view/EconomiaSolidaria/

INF01127 – Engenharia de Software N - página do professor Dr. Sérgio Felipe Zirbes para disciplina, acessado em Junho/2008http://www.inf.ufrgs.br/~zirbes/EngSoftwareN.htm

Larman, Craig. Utilizando UML e Padrões. Uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. 2ª Edição, 2004.

- 25 -

http://pt.wikipedia.org/wiki/Economia_solid?ria

http://www.inf.ufrgs.br/~zirbes/EngSoftwareN.htm

http://twiki.softwarelivre.org/bin/view/EconomiaSolidaria/

http://www.ecosol.org.br/

http://pt.wikipedia.org/wiki/Categoria:Engenharia_de_software

http://pt.wikipedia.org/wiki/UML


16 Anexos

16.1 Anexo A – Ata de reunião de início do projeto

Ata de Reunião

Data: 27/abril/2008

Participantes: Luís Fernando Heckler (analista), Diego Francisco de Gastal Morales (analista), Fabiana Thomé da Cruz (cliente)

Pauta:

● Apresentação da metodologia de análise que será implementada;● Apresentação da versão preliminar do Diagrama Hierárquico de Funções – DHF;● Refino do DHF junto com o cliente.

Observações:

● Foi apresentado à cliente o objetivo acadêmico deste trabalho, o modo como será levado adiante, e qual deverá ser o produto final obtido, esta tendo concordado com os pontos.

● Foi apresentado o DHF inicial do sistema previsto bem como algumas perguntas de forma a fechar o escopo do sistema:

1. Qual a nomenclatura? (Quais são as entidades?) Existe um nome mais adequado que outro? Exemplo: Funcionário/Fornecedor/Produto, Colaborador/Associado/Bem, etc.Resposta da Cliente: o sistema deverá prever a existência das seguintes entidades:- colaborador: representa os funcionários da loja;- associado: representa os fornecedores de produtos, sob consignação ou venda;- produto: representa os bens comercializados na loja

2. Qual o porte da loja? Tamanho, número de funcionários, fornecedores, variedade de produtos (que produtos?), volume de vendas, etc.Resposta da Cliente: a loja terá quatro colaboradores (dois por turno).

3. Existe alguma prestação de contas específica da modalidade de economia solidária (perante o governo, ou associados...) ?Resposta da Cliente: até o momento não se conhece a necessidade de ter nenhum tipo especial de prestação de conta, a não ser a de fluxo de caixa. Observa-se porém que é preciso controlar que existirá um percentual sobre todo valor agregado (diferença entre o preço de venda e o preço de compra) que deverá ser retornado à FAURGS. Portanto, será adequado ter relatórios desta remessa, bem como dos ganhos por produto.

4. Há necessidade de fazer um controle de ponto dos funcionários?Resposta da Cliente: dado o tamanho reduzido da loja, não será necessário realizar controle de ponto dos colaboradores.

5. Quem são os clientes da loja? A comunidade em geral? Algum tipo de cliente especial? Há necessidade de algum controle de pedidos, encomendas ou algo semelhante?Resposta da Cliente: os clientes da loja deverão ser alunos, professores e funcionários da

- 26 -


comunidade da UFRGS, bem como a comunidade em geral. Será interessante prever um controle de encomendas de produtos consignados, como a confecção de camisetas e mochilas por exemplo. A loja deverá vender produtos não perecíveis, de artesanato e afins, por consignação; bem como alimentos processados, tais como conservas e doces em pasta.

● Com base nas repostas aos questionamentos, o DHF do sistema foi finalizado pelos analistas.

Plano de Ação:

● Fechamento do DHF [até 31/03/2008]● Definição dos Casos de Uso do sistema [até 25/abril/2008];● Definição do Diagrama de casos de uso [até 29/abril/2008].

Esta ata foi redigida no ato da reunião e os presentes concordam com seu conteúdo.

- 27 -

Documents

Especificacao Sistema de Controle Financeiro