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 Morales

Luí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 Figuras
Figura 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 Quadros
Tabela 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
 Instituto de Informática

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-
 Instituto de Informática

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-
 Instituto de Informática

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 05 de junho

Casos de Uso ou Colaboração)

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-
 Instituto de Informática

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

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-
 Instituto de Informática

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.

Figura 2: Atores do sistema

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 Caixa

Atores: Colaborador
Finalidade: Habilitar movimentações financeiras no sistema, conferindo, ajustando e
registrando a quantidade de dinheiro em caixa.

-5-
 Instituto de Informática

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 Caixa

Atores: Colaborador
Finalidade: 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 Itens

Atores: 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-
 Instituto de Informática

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: Inicializar

Atores: Colaborador
Finalidade: 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 Pessoas

Atores: Administrador
Finalidade: Controlar dados de colaboradores e associados.

-7-
 Instituto de Informática

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 Produtos

Atores: Colaborador
Finalidade: 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 Encomenda

Atores: Cliente, Colaborador
Finalidade: 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 essencial
Referê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 Pedido

Atores: Colaborador, Associado
Finalidade: Implementar o processo de efetivação de um pedido de fornecimento de
produto, a partir do registro de uma encomenda.

-8-
 Instituto de Informática

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 essencial
Referê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ção

Atores: Colaborador, Associado
Finalidade: 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 Associado

Atores: Colaborador, Associado
Finalidade: 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-
 Instituto de Informática

Referências: 1.2, 3.2

7.2.11 Caso de Uso: Rodar Folha de Pagamento

Atores: Administrador, Colaborador
Finalidade: 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órios

Atores: Colaborador
Finalidade: 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 -
 Instituto de Informática

Figura 3: Diagrama de Casos de Uso

- 11 -
 Instituto de Informática

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.

Figura 4: Modelo Conceitual do sistema

- 12 -
 Instituto de Informática

9 Diagramas de Interação
9.1 Diagrama de Seqüência – Caso de Uso Abrir o Caixa

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

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

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

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

- 13 -
 Instituto de Informática

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

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

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

- 14 -
 Instituto de Informática

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

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

- 15 -
 Instituto de Informática

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

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

10

11 Diagrama de Classes

- 16 -
 Instituto de Informática

Figura 11: Diagrama de classes

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 -
 Instituto de Informática

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 – UAW

Analisando 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 – UUCW

Para 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 -
 Instituto de Informática

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 - UUCP

Segundo 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 – Tfactor

Para 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 1 1 1
especial
TFactor 28

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

12.1.5 Cálculo do Fator de Complexidade Técnica - TCF

Segundo o método, temos que TCF = 0,6 + (0,01 * Tfactor). Logo, para nosso
projeto temos que:

- 19 -
 Instituto de Informática

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

12.1.6 Cálculo do Fator de Ajuste de Ambiente – Efactor

Para 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 1,5 5 7,5
outro processo formal
E2 Experiência com a 0,5 0 0
aplicação em
desenvolvimento
E3 Experiência em Orientação 1 3 3
a Objetos
E4 Presença de analista 0,5 4 2
experiente
E5 Motivação 1 5 5
E6 Requisitos estáveis 2 5 10
E7 Desenvolvedores em -1 5 -5
meio-expediente
E8 Linguagem de programação 2 2 4
difícil
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 – ECF

Pelo 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 – UCP

Pelo 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 estimado

Seguindo 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 custo

De 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 -
 Instituto de Informática

12.1.11 Estimativa de prazo

Considerando 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 -
 Instituto de Informática

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 -
 Instituto de Informática

Figura 13: Ferramenta CASE Visual Paradigm UML

- 23 -
 Instituto de Informática

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 -
 Instituto de Informática

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

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

Wikepedia – Categoria Engenharia de Software

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

Grupo de Pesquisa de Economia Solidária – UNISINOS, acessado em Junho/2008

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

Rede EcoSoLivre, acessado em Junho/2008

http://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/2008
http://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 -
 Instituto de Informática

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 -
 Instituto de Informática

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 -