DESENVOLVENDO O SISTEMA

Transcrição

1 DESENVOLVENDO O SISTEMA Declaração da Necessidade O primeiro passo do processo de análise de sistema envolve a identificação da necessidade [Pressman-95]. Normalmente o analista reúne-se com o usuário final e juntos definem as metas do sistema assim como as principais funcionalidades a serem contempladas. A definição inicial das necessidades norteará o desenvolvimento do sistema, e posteriormente as informações contidas nesta declaração serão refinadas para oferecer mais detalhes para a especificação dos requisitos. Não é preciso que esta definição seja exata e completa, apenas deve expressar claramente o problema a ser resolvido. As necessidades inicialmente identificadas para o Sistema Comercial compreendem as atividades relacionadas com compras e vendas realizadas em uma loja. Para tanto, deve compreender: registro das vendas de produtos; controle de vendas a prazo; emissão de notas fiscais; cálculo das comissões dos vendedores; fornecimento de informações sobre o estoque para a realização das compras; acompanhamento dos pagamentos relativos às compras; atualização do estoque. São usuários diretos do sistema o setor de vendas, o setor de compras, o setor financeiro, o setor de estoque e o gerente da loja.

2 Especificação de Requisitos Funcionais A análise de requisitos consiste na definição clara dos objetivos a serem alcançados, e culmina com a produção de um documento denominado Especificação de Requisitos. Como definido em [Davis-96], requisito é uma capacidade ou característica necessária para que determinado usuário solucione um problema ou alcance um objetivo. Esta seção trata dos requisitos funcionais, sendo que os demais tipos de requisitos (desempenho, confiabilidade, segurança, etc.) são também importantes, porém não serão discutidos neste trabalho. A especificação de requisitos funcionais é feita através de casos de uso (use cases), conforme definidos em [UML-97]. Um conjunto de casos de uso é importante para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade a ser oferecida pelo sistema, ou seja, um serviço prestado ao usuário. Casos de Uso A idéia para a identificação dos casos de uso é analisar o negócio sob o ponto de vista dos objetivos do usuário. Não se deve buscar funções do negócio ou simplesmente tratar os casos de uso como funções do sistema. No Sistema Comercial, a determinação dos casos de uso foi feita a partir da elaboração de roteiros que descrevem os principais eventos de negócio. Cada roteiro foi analisado em busca de tarefas que o sistema poderia dar suporte, gerando assim os casos de uso. A denominação utilizada para os casos de uso é iniciada com um verbo no infinitivo que expressa a tarefa do usuário que o sistema irá apoiar. Ex.: Autorizar Crédito - este caso de uso apoiará a tomada de decisão do funcionário do setor financeiro para que ele cumpra sua tarefa de autorizar crédito, fornecendo informações sobre a situação do cliente e, também, registrando a autorização.

3 Os quadros a seguir mostram o roteiro de evento para venda à vista e os casos de uso identificados: Roteiro: Venda à Vista 1. Cliente entra na loja e solicita produto. 2. Vendedor informa a existência do produto na loja. 3. Cliente solicita informações sobre produto à venda (ex.: cor, tamanho, fabricante, preço,...). 4. Vendedor mostra todas as opções disponíveis. 5. Cliente informa o(s) produto(s) desejado(s). 6. Vendedor registra venda. 7. Caixa informa valor a pagar para o cliente. 8. Cliente efetua o pagamento. 9. Caixa registra o pagamento e fornece a nota fiscal. 10. Almoxarife realiza a baixa no estoque. 11. Cliente leva o produto com a nota fiscal. 12. Ao final do mês o funcionário do Setor Financeiro calcula as comissões dos vendedores sobre as vendas à vista. Caso de Uso Passos do Roteiro Pesquisar Produto Registrar Venda * Registrar Pagamento Calcular Comissão de Vendedor 12 * A baixa no estoque será automática após a confirmação da venda.

4 Os quadros a seguir mostram o roteiro de evento para venda a prazo e os casos de uso identificados: Roteiro: Venda a Prazo 1. Cliente informa o(s) produto(s) desejado(s). 2. Vendedor registra venda. 3. Cliente escolhe plano de pagamento (quantidade de prestações). 4. Vendedor informa o valor das prestações. 5. Funcionário do Setor Financeiro verifica se cliente está com situação financeira regular em relação a empresa. 6. Funcionário do Setor Financeiro autoriza o crédito e emite o carnê de pagamento. 7. Caixa informa valor a pagar para o cliente. 8. Cliente paga a primeira prestação no guichê do caixa. 9. Caixa registra o pagamento e fornece a nota fiscal. 10. Almoxarife realiza a baixa no estoque. 11. Cliente leva o produto com a nota fiscal. 12. Ao final do mês o funcionário do Setor Financeiro calcula as comissões dos vendedores sobre as prestações quitadas. Caso de Uso Passos do Roteiro Registrar Venda 2 10 Definir Prestações 3 4 Autorizar Crédito 5 6 Registrar Pagamento Calcular Comissão de Vendedor 12

5 Os quadros a seguir mostram o roteiro de evento para pagamento e os casos de uso identificados: Roteiro: Pagamento 1. Cliente entrega boleto da prestação para o caixa. 2. Caixa verifica vencimento e calcula valor a pagar (multa, juros, desconto). 3. Cliente efetua pagamento da prestação. 4. Caixa autentica valor pago no boleto. 5. Cliente recebe boleto com registro de pagamento. 6. Funcionário do Setor Financeiro atualiza situação do cliente. Caso de Uso Passos do Roteiro Calcular Valor da Prestação 2 Registrar Pagamento * * A atualização da situação do cliente será automática após o registro do pagamento.

6 Os quadros a seguir mostram o roteiro de evento para acompanhamento dos vencimentos e os casos de uso identificados: Roteiro: Acompanhamento dos Vencimentos 1. Funcionário do Setor Financeiro verifica prestações em atraso. 2. Registra clientes com situação irregular, ou seja, com prestações em atraso há mais de 30 dias. 3. Prepara relação de clientes com prestações em atraso há mais de 60 dias para cobrança bancária. Caso de Uso Passos do Roteiro Acompanhar Vencimento de Prestações 1 2 3

7 Os quadros a seguir mostram o roteiro de evento para negociação de dívida e os casos de uso identificados: Roteiro: Negociação de Dívida 1. Cliente negocia a dívida com a gerência. 2. Gerente verifica situação do cliente. 3. Gerente autoriza desconto na prestação. 4. Cliente paga prestação com o desconto concedido no guichê do caixa. Caso de Uso Passos do Roteiro Consultar Situação do Cliente 2 Determinar Desconto em Prestação 3 4

8 Os quadros a seguir mostram o roteiro de evento para compra de produtos e os casos de uso identificados: Roteiro: Compra de Produtos 1. Almoxarife verifica produtos abaixo do estoque mínimo. 2. Determina quantidade necessária para reposição do estoque, verificando consumo médio destes produtos. 3. Funcionário do Setor de Compras elabora pedido de compra para determinado fornecedor, indicando a quantidade dos produtos desejados. 4. Fornecedor entrega os produtos solicitados. 5. Almoxarife recebe produtos e confere com o pedido de compra. 6. Comunica recebimento ao Setor Financeiro. 7. Atualiza estoque dos produtos recebidos. 8. Funcionário do Setor Financeiro recebe duplicata do fornecedor e programa o pagamento. 9. Funcionário do Setor de Compras verifica periodicamente a situação dos pedidos de compra e entra em contato com os fornecedores cujas entregas estão atrasadas. Caso de Uso Passos do Roteiro Acompanhar Estoque 1 2, almoxarife Elaborar Pedido de Compra 3 Registrar Recebimento de Produtos 7, almoxarife Agendar Pagamento de Duplicata 8, setor financeiro Acompanhar Pedido de Compra 9, setor de compra

9 Os quadros a seguir mostram o roteiro de evento para pagamento de duplicatas e os casos de uso identificados: Roteiro: Pagamento de Duplicatas 1. Funcionário do Setor Financeiro verifica vencimento de duplicatas. 2. Providencia pagamento de duplicatas a vencer. Caso de Uso Passos do Roteiro Acompanhar Duplicatas a Pagar 1 Registrar Pagamento de Duplicata 2

10 Modelo de Casos de Uso O Modelo de Casos de Uso estabelece os requisitos funcionais definindo o comportamento esperado para o sistema sem revelar sua estrutura interna. Cada caso de uso representa uma série de ações que os usuários podem executar interagindo com o sistema, a fim de desempenharem determinada tarefa. Os casos de uso são agrupados em diagramas para serem apresentados graficamente. Os diagramas de casos de uso, juntamente com suas definições, compõem o Modelo como um todo. Os roteiros de eventos não fazem parte da especificação dos requisitos funcionais, sendo apenas um meio para se identificar os casos de uso. Portanto não precisam ser mantidos após a elaboração do Modelo de Casos de Uso. A construção dos diagramas ocorreu à medida que os casos de uso foram surgindo, juntamente com a identificação dos atores - usuários que interagem diretamente com cada caso de uso - e dos relacionamentos.

11 Durante a construção dos diagramas, os casos de uso foram organizados em subsistemas de negócio, de acordo com a afinidade entre eles. Assim, foram estabelecidos dois subsistemas: Subsistema Vendas e Subsistema Compras. Figura 1: Subsistemas de negócio Sistema Comercial Subsistema Vendas Subsistema Compras A Figura 2 apresenta os casos de uso para o Subsistema Vendas, cujas definições estão listadas a seguir. Figura 2: Diagrama de casos de uso para o Subsistema Vendas. <Vendedor> Pesquisar Produto Subsistema Vendas Registrar Pagamento <Caixa> <<extends>> Registrar Venda Calcular Valor da Prestação <<extends>> Definir Prestações <Funcionário Setor Financeiro> Autorizar Crédito Determinar Desconto Prestação <Gerente> <<uses>> <<uses>> Acomp. Vencimento Prestações Consultar Situação do Cliente Calcular Comissão de Vendedor Acompanhar Vencimento de Prestações verificar prestações em atraso há mais de 30 dias, atribuindo situação irregular ao cliente. Emitir relação

12 de clientes para cobrança bancária (com prestações em atraso há mais de 60 dias). Autorizar Crédito verificar as condições de venda a prazo e consultar a situação do cliente. Registrar a liberação do crédito. Calcular Comissão de Vendedor verificar as vendas realizadas por cada vendedor no mês, calculando a comissão sobre as vendas a vista. Verificar prestações quitadas no mês, calculando comissão para os vendedores. Calcular Valor da Prestação verificar a data de vencimento da prestação e calcular, quando for o caso, multa e juros devidos. Quando existir, aplicar o desconto determinado pelo gerente. Calcular o valor final a pagar. Consultar Situação do Cliente informar as vendas realizadas para determinado cliente, indicando a situação das prestações quando for venda a prazo. Informar se cliente está em situação irregular. Definir Prestações registrar o número de prestações que o cliente deseja, calcular e informar o valor das prestações. Determinar Desconto em Prestação consultar situação do cliente e, caso aprovado, registrar o desconto concedido. Pesquisar Produto permite ao vendedor a busca de informações sobre os produtos que estão a venda, como cor, tamanho, fabricante, preço, etc. Registrar Pagamento informar o valor da venda ao caixa e registrar o valor pago pelo cliente. Emitir a nota fiscal. No caso de venda a prazo, informar o valor da prestação a pagar. No caso de quitação de prestação atrasada, atualizar a situação do cliente. Registrar Venda cadastrar a venda realizada, informando produtos vendidos e dados do cliente. Registra também o vendedor que efetuou a venda. Ao confirmar a venda, realizar a baixa no estoque. Caso uma venda seja cancelada, deverá ser cancelada a baixa no estoque.

13 A Figura 3 apresenta os casos de uso para o Subsistema Compras, cujas definições estão listadas a seguir. Figura 3: Diagrama de casos de uso para o Subsistema Compras <Almoxarife> Subsistema Compras Acompanhar Estoque Registrar Recebimento Produtos Agendar Pagamento de Duplicata <Funcionário Setor Financeiro> <Funcionário Setor de Compras> Acompanhar Duplicatas a Pagar Elaborar Pedido de Compra Registrar Pagamento Duplicata Acompanhar Pedido de Compra Acompanhar Duplicatas a Pagar verificar duplicatas com vencimento próximo, e informar valor devido. Acompanhar Estoque verificar produtos com estoque abaixo do mínimo, calcular o consumo médio e determinar a quantidade necessária para reposição. Acompanhar Pedido de Compra verificar os pedidos de compra ainda não atendidos, e informar dados para contato com o fornecedor. Agendar Pagamento de Duplicata cadastrar duplicata, indicando a data de vencimento e qual a compra correspondente. Elaborar Pedido de Compra informar a lista de produtos, indicando os que estão marcados para reposição. Escolher os produtos a serem adquiridos, registrando a quantidade e o fornecedor. Emitir o pedido de compra para cada fornecedor. Registrar Pagamento de Duplicata após a quitação de duplicata, registrar a data de pagamento. Registrar Recebimento de Produtos verificar determinado pedido de compra, registrar o recebimento e atualizar o estoque. Para a elaboração do modelo, foram necessárias várias iterações de conferência entre os roteiros de eventos e os casos de uso. Em uma primeira análise dos

14 roteiros, foram determinados alguns casos de uso, que por sua vez geraram dúvidas sobre os roteiros. Assim, os roteiros foram revisados, acrescentando-se passos que faltavam. Estes novos passos acabavam por determinar novos casos de uso possíveis. O processo continuou até torná-los completos e coerentes entre si. Atores Ator não é o mesmo que usuário. Ator é um papel que um usuário desempenha em relação ao sistema. Por exemplo, existem vários vendedores na loja, mas a partir do momento que o sistema foi concebido, todos eles desempenharão o mesmo papel ( <Vendedor>) diante do sistema. Um usuário pode, inclusive, desempenhar mais de um papel. Considere que o controle do estoque é feito por um funcionário do setor de compras; diante do sistema, ele desempenhará tanto o papel de <Funcionário do Setor de Compras> quanto o de <Almoxarife>. Existem dois benefícios indiretos da identificação dos atores. O primeiro é que facilita o conhecimento sobre quem está envolvido em cada caso de uso. No momento de estudar a fundo determinado caso de uso, estará claro quem são as pessoas que podem contribuir com informações sobre as tarefas relacionadas. O outro benefício ocorre se o sistema tem casos de uso que correspondem a funções de alto nível. As ligações entre casos de uso e atores poderiam ser usadas para a criação dos perfis de usuários. Cada usuário seria associado a uma lista de nomes de atores, os quais seriam utilizados para determinar as funções que aquele usuário pode executar. Às vezes é interessante perceber a hierarquia existente entre as definições dos atores. Utilizando o conceito de generalização de classes, poderia ser elaborado um diagrama como o mostrado a seguir. Este tipo de visualização é possível de acordo com [UML-97], já que o conceito de ator é definido como uma classe com estereótipo de ator (). Estereótipo é um mecanismo de extensão dos recursos de modelagem, sendo que, quando aplicado a uma classe, cria um novo tipo de classe que mantém o conceito original, porém estabelece uma distinção na sua utilização. Por exemplo, ator é um tipo de classe usada apenas para modelar os papéis que um usuário desempenha quanto interage com o sistema. Por causa da aplicação do estereótipo de ator, o símbolo da classe muda para o desenho de um homenzinho.

15 Figura 4: Hierarquia das definições de atores <Gerente> <Vendedor> <Usuário> <Funcionário Setor Financeiro> <Caixa> <Funcionário Setor de Compras> <Almoxarife> As setas indicam o sentido da generalização. O ator ligado à extremidade da ponta da seta é a definição genérica, e os atores ligados à outra extremidade são as definições mais específicas. Assim, <Gerente>, <Vendedor>, <Funcionário do Setor de Financeiro> e <Funcionário do Setor de Compras> são tipos de <Usuário>. Por sua vez, <Caixa> é um tipo de <Funcionário do Setor Financeiro>, e <Almoxarife> é um tipo de <Funcionário do Setor de Compras>. Observe que um usuário que é <Almoxarife> é também <Funcionário do Setor de Compras>. Para o estudo de caso apresentado não há muita necessidade de se preocupar com esses aspectos, todavia existem sistemas grandes e complexos que exigem a definição de dezenas de atores. Nestes casos a hierarquia da definição de atores é muito importante, podendo até mesmo ser imprescindível. Relacionamentos A linha que liga um ator a um caso de uso significa que há uma comunicação entre eles, ou seja, o ator participa daquele caso de uso. Por exemplo, no

16 Subsistema Vendas, o Gerente participa de Determinar Desconto de Prestação, interagindo com o sistema. Entre casos de uso são possíveis dois tipos de relacionamento: extensão (<<extends>>) e utilização (<<uses>>). A extensão é utilizada quando se tem um caso de uso que é similar a outro já modelado mas que faz um pouco mais. Aproveita-se o caso de uso existente, e define-se o novo apenas com a variação do comportamento original. No Subsistema Vendas (Figura 2), existe Registrar Venda, que define o cadastramento de uma venda à vista. Em vez de criar um caso de uso totalmente novo chamado Venda a Prazo, optou-se por definir apenas a diferença entre os dois casos, ou seja, Definir Prestações. Assim, quando a venda for a prazo, Registrar Venda será estendida pela definição de Definir Prestações. O outro tipo de relacionamento entre casos de uso, chamado de utilização, pode ser empregado quando se tem uma parte da definição que é idêntica em mais de um caso de uso. Essa parte idêntica é definida separadamente transformando-se em um novo caso de uso e pode ser utilizada por outros casos de uso. Por exemplo, tanto em Autorizar Crédito quanto em Determinar Desconto de Prestação ocorre a definição de uma consulta aos dados do cliente. Esta definição comum foi separada em um novo caso de uso, com o nome de Consultar Situação do Cliente, de forma que pudesse ser reutilizada. Por Que Utilizar Casos de Uso A análise de requisitos a partir de casos de uso provê os meios para se fazer o gerenciamento do sistema, que engloba a administração do escopo, a análise de impacto de mudanças e o controle destas mudanças. Logo, é importante durante o desenvolvimento do sistema - quando deve ser mantido o domínio sobre o que tem de ser desenvolvido e também após a sua completa implantação - quando surgem as manutenções evolutivas. Durante a fase de desenvolvimento, os casos de uso constituem um bom instrumento para o planejamento do projeto, pois criam condições para a aplicação de um processo evolutivo de desenvolvimento de sistemas (ver seção Erro! Fonte de referência não encontrada.). Casos de uso servem ainda como ponto de comparação para certificar que o sistema atendeu aos requisitos planejados, pois fornecem pontos de controle bem definidos e facilmente mensuráveis. Ex.: um ponto de controle poderia ser Implantação do caso de uso Autorizar Crédito concluída. Em termos de comunicação, casos de uso constituem uma técnica muito valiosa, visto que fornecem feedback regular para os usuários sobre o que o sistema compreende e o quanto já foi concluído. Considerações Importantes A utilização do Modelo de Casos de Uso não significa que o desenvolvedor deva construir o software transformando cada caso de uso em uma unidade de código procedural. Para a orientação a objetos, os casos de uso expressam a visão externa do

17 sistema, sendo que a codificação dos programas será estruturada de uma forma completamente diferente. Um software baseado em objetos é construído a partir da implementação das classes de objetos (com seus atributos e operações) e não de estruturas procedurais. O Modelo de Casos de Uso do sistema compreende somente a especificação de requisitos funcionais. A base para a construção do software é o Modelo do Sistema que contém as definições das classes de objetos. (ver seção Erro! Fonte de referência não encontrada.).

18