Paradigmas de Análise e Desenvolvimento 09

Prévia do material em texto

Paradigmas de Análise e Desenvolvimento
Aula 09
Prática de Análise Orientada a Objeto – Parte I
Nesta aula, você irá: 
1. Entender, na prática, as atividades da fase de Análise de Sistemas, usando a técnica da Análise Orientada a objetos, com UML.
2. Entender, na prática, as dificuldades em modelar sistemas usando a técnica da Análise O.O com UML.
3. Entender a relevância em identificar corretamente os casos de uso de um Sistema
A análise de sistemas O.O na prática com UML
Já usamos a UML nas aulas anteriores, para modelagem de sistemas desenvolvidos sob a técnica de Análise Orientada a Objeto.
Já sabemos que a UML não determina a ordem com que as atividades são realizadas e/ou os diagramas possíveis são modelados. O que determinará essa sequência será a metodologia usada pela empresa.
Porém já vimos na aula 6 que há uma ordem lógica na elaboração dos diagramas UML, embora seja possível qualquer outra combinação.
Vamos assumir aqui como premissa os conceitos apresentados e fixados na Aula 8 (Prática de Análise Essencial).
Vamos tentar explicar, passo a passo, as atividades que antecedem a modelagem do sistema e das atividades, durante a modelagem, que transcendem-nas.
Vamos falar nessa aula de atividades como:
Como a análise começa?
Antes da fase de análise, independente do processo de desenvolvimento, vai existir uma fase, geralmente chamada de concepção onde:
• Será avaliada a viabilidade, tanto técnica, como econômica do sistema.
• São identificados e documentados a empresa e os departamentos envolvidos, os principais objetivos, abrangência e requisitos do sistema.
Todos os dados identificados e as definições da fase de concepção são registradas em um relatório que recebe vários nomes: Documento de Viabilidade, Relatório de Concepção, Mini Mundo, Relatório de Definições do Sistema, Relatório de Requisitos do Sistema e ainda outros que não me vem à mente, nesse momento.
A fase de análise recebe então esse documento inicial, que não necessariamente foi desenvolvido pelo(s) analista(s) de sistema(s) responsável(is) pela fase de análise.
As atividades de análise, passo a passo
O passo a passo que será apresentado aqui e seguido nessa aula não é o único possível e nem o mais eficiente, mas foi a reunião da experiência prática de anos de desenvolvimento de sistemas. Até porque, uma atividade tão complexa e com características tão subjetivas não pode ser resumida a uma passo a passo.
Levantamento de dados. *
Documentos de Requisitos de Análise.
Validação dos requisitos com usuários.
Modelagem de Sistemas, segundo a técnica da Análise O.O, usando UML.*
Validação dos requisitos e modelagem (Aula 10).
*Levantamento de dados - Entender a empresa (muitas vezes vem no documento inicial de concepção).
Entender o sistema em detalhes.
*Modelagem de Sistemas, segundo a técnica da Análise O.O, usando UML – 
A. Opcionalmente: Elaboração da Lista de Eventos que afetam o sistema (Aula 9)
B. Diagrama de Casos de Uso (Aula 9)
C. Especificação dos Casos de Uso (Aula 9)
D. Diagrama de Classe (Aula 9)
E. Diagrama de Sequência (Aula 10)
F. Diagrama de Estados (Aula 10)
G. Diagrama de Atividades (Aula 10)
Estudo de caso e aplicação do passo a passo
O documento recebido pela fase de análise será um Mini mundo, apresentado a seguir.
Usaremos nessa aula o mesmo Estudo de Caso da aula 8, para facilitar a comparação entre as 2 técnicas de modelagem.
A locadora de fitas “Só Filmaço” atua no mercado de aluguel de mídias de DVDs e Bluerays há dois anos e resolveu informatizar a loja. A locadora só aluga mídias (nome do filme, diretor, categoria, valor do aluguel diário) a clientes cadastrados (nome, rua, número, telefone e bairro) e só possui um exemplar de cada filme. O atendente é responsável pelo atendimento aos clientes para o aluguel e devolução das mídias. Toda as mídias devem ser devolvidas em dois dias partir da data do aluguel e, diariamente ao final do expediente, é emitido para o gerente a lista os clientes em atraso para que seja feito um contato telefônico.
Os clientes podem registrar dependentes (nome, grau de parentesco e idade,) que estão autorizados a retirar mídias em seus nomes, bem como excluir os já registrados. Periodicamente, são feitas promoções para atrair novos clientes e também são adquiridas mídias de novos filmes.
Os novos clientes são introduzidos, no sistema, pelo gerente após uma verificação no SPC e as novas mídias são introduzidas, no sistema, pelo comprador da loja.
Por ocasião da devolução é calculada a multa, caso haja, e todos os pagamentos são efetuados à vista ou em cartáo (de crédito ou débito). O sistema deve controlar os recebimentos em cartão. Além do controle de locação, a Vídeo Locadora deseja manter um cadastro dos equipamentos de reprodução de mídias (Tipo de equipamento, que pode ser DVD ou Blue Ray, nome do fabricante e data de fabricação) de seus clientes para futura criação de um setor de reparos eletrônicos. Um cliente pode ter vários destes equipamentos sendo que existem clientes que não possuem nenhum, ou não desejam registra-los.
Sempre que precisa, o gerente emite o relatório de Mídias mais alugadas no período e o relatório de Mídias sem locação há mais de 4 meses.
Dica - Como esse é um exemplo acadêmico, muitos dos conceitos, abaixo apresentados, não poderão ser aplicados.
Em cada item explicado, teremos o título Aplicação do Estudo de Caso, onde serão feitos os comentários pertinente ao assunto.
Levantamento de dados
O objetivo da atividade de levantamento de dados, aqui na fase de análise é entender e detalhar o funcionamento da empresa e definir os requisitos de seus usuários.
As técnicas mais usadas, obviamente que dependendo da situação, são: entrevistas, pesquisa de campo, reuniões, questionários e brainstorm.
No início, quando os analistas de sistemas ainda não tem um conhecimento mais aprofundado do sistema e nem muito contato com os funcionários da empresa, as técnicas que tendem a ser mais usadas são: entrevistas, reuniões e pesquisa de campo.
Observe que essas atividades de levantamento de dados são as mesmas para qualquer técnica de análise que esteja sendo usada (compare com as apresentadas na aula 8 – técnica de análise essencial).
1° Contextualizar a Empresa
Caso o documento inicial ainda não tenha identificado as áreas (departamentos e setores) envolvidas com o sistema, solicite um organograma (apenas médias, grandes ou pequenas empresas bem estruturadas, o terão) e identifique não somente as áreas envolvidas, como também os respectivos usuários pertinentes e ainda os responsáveis pelas áreas envolvidas.
Estudo de caso: Não se aplica, pois não há contextualização. Mas como trata-se de uma pequena e até mesmo micro empresa a estrutura organizacional tende a ser simples e os usuários envolvidos tende a ser o(s) sócio(s), o gerente e o(s) atendente(s). O levantamento de dado deve considerar todos os envolvidos.
2° Identificar o Objetivo Geral do Sistema
A empresa deve saber com clareza o que pretende alcançar ao desenvolver o sistema (seja ele para substituir um processo manual ou um outro sistema) ou seja qual é para ela o objetivo do sistema.
Estudo de caso: pelo texto inicial, fica claro que o sistema deve controlar todas as atividades de locação, passando pela gestão do acervo (inclusão e exclusão de exemplares). Está explícito que o sistema deve gerenciar as receitas em cartão. Mas não está claro quanto a gestão fechamento do caixa (recebimentos em dinheiro e cartão no dia a dia), o que deve ser elicidado na fase de levantamento de dados da análise.
3°Confirmar ou Definir o Escopo do Sistema
O documento inicial, se bem elaborado, já deve definir o escopo do sistema a ser desenvolvido. Todavia se não trouxer, deve ser definido com clareza nesse momento. 
Estudo de caso: observe que o item acima (definição dos objetivos) esta intimamenterelacionado com o escopo, logo após identificar com clareza os objetivos, a delimitação do escopo começa a ser definida, também.
Documento de requisitos de analise
Após o levantamento de dados da fase de análise deve ser elaborado um documento simples, complementando o documento inicial de requisitos (nesse estudo de caso foi um minimundo) que poderá conter:
• Retificações de eventuais dados do levantamento inicial.
• Definições não constantes do documento inicial.
• Complementos de informações.
 Um aspecto relevante que deve ser observado nesse documento são os dados que devem ser tratados pelo sistema, já ajudando na definição dos depósitos de dados, fluxos de dados e no Modelo de Entidade e Relacionamento (MER).
Nesse documento, no caso da Análise OO, pode-se apresentar a lista de eventos que afetam o sistema.
Validação dos requisitos com usuário
Antes de iniciar a modelagem de análise é oportuno que façamos uma revisão dos requisitos, junto aos usuários. Para tal é aconselhável rever com eles, com base no Documento de Requisitos de Análise, cada uma das necessidades que serão traduzidas em funcionalidades no sistema.
Muitas empresas tem por hábito fazer com que a empresa-cliente assine o documento ao final, tomando ciência dos requisitos levantados, com os quais será dada início a modelagem. Tal ação é importante para, futuramente, mostra aos usuários que determinado requisito ou a mudança demandada não estavam no escopo do trabalho. Mas não servirá para muito mais além disso, pois se a mudança for fundamental, não vai importar quem errou, pois o deverá ser incorporada ao projeto.
Mas de toda forma, devemos seguir essa formalização.
Lista de eventos que afetam o sistema
Diagrama de casos de uso
Para afeitos da análise OO, o fato de identificar a lista de eventos, facilita a identificação das funcionalidades (Casos de uso) do sistema. Basta usar a coluna (função). A coluna função de cada evento será um Caso de Uso, numa primeira versão do diagrama.
Cabe ressaltar que o conceito de ATOR (Caso de Uso) é diferente do conceito de ENTIDADE EXTERNA (DFD). A visão de ator é de quem interage com o sistema e não quem troca informações, como no caso de Entidade Externa.
Os Atores são: Atendente, Gerente e Comprador, que são os que interagem (usam) o sistema.
A 1ª. Versão do diagrama de classes foi elaborada associando cada caso de uso a uma função da lista de eventos. Obviamente que, se a quantidade de eventos fosse grande teríamos que usar um dos 2 artifícios abaixo:
Divisão do sistema em pacotes
Agrupamento de Casos de uso, afins. Por exemplo poderíamos agrupar os casos de uso Incluir Dependentes e Exclui Dependentes em um único caso chamado Atualizar Dependentes.
Abaixo, o que seria a 1ª. Versão do Diagrama de Casos de Uso. Chamamos de 1ª. Versão pois percebe que ela ainda não tem nenhum caso de include (ou uses) ou extensão (extends).
Após a elaboração da 1ª. Versão temos os refinamentos. O primeiro passo seria analisar se existem passos comuns aos casos de uso do diagrama. Claro que, eventualmente, tal percepção só é possível quando começarmos as especificações dos casos de uso. Mas a experiência possibilitar que nos antecipemos e vislumbremos antes. Vejamos:
• Os Casos de Uso Incluir Dependente e Excluir Dependente, antes da respectiva inclusão ou exclusão devem fazer uma pesquisa para verificar se o dependente já não existe no cadastro. É bem verdade que o uso dado será diferente, pois no caso de inclusão, a operação só será feita se o dependente não existir. Já no caso da exclusão, a operação só pode ser completada se o dependente existir. Mas de todo modo, a pesquisa precisa ser feita e na especificação desses 2 casos de uso seria percebido que alguns passos (pertinentes a pesquisa) seriam os mesmos. Esse é o típico caso onde poderemos fazer uso do “Include” ou “Uses”. Veja no diagrama de caso de uso, abaixo, como ficaria o diagrama com essa alteração.
Na nova versão do diagrama abaixo, foi criado um novo caso de uso PESQUISAR DEPENDENTE, cujo passo a passo é comum tanto a Incluir Dependente, como a Exclui Dependente, logo ambos passam a “usar” esse caso de uso em algum ponto das respectivas especificações.
1° Identificação das Classes e Alguns Métodos
Para desenhar o diagrama de Classes CONCEITUAL, devemos olhar cada caso de uso, pois:
Alguns casos de uso derivam uma classe.
• Incluir Cliente deriva a classe CLIENTE
• Incluir Mídias deriva a classe MÍDIAS
• Excluir Dependente e Incluir Dependente derivam a classe DEPENDENTE
• Incluir Equipamento deriva a classe EQUIPAMENTO
• Registrar Locação deriva a Classe LOCAÇÃO
• Abrir Caixa e Fechar Caixa derivam a Classe CAIXA
• Incluir Recebimento Cartão deriva a Classe FATURAS CARTÃO
2°Primeira Versão do Diagrama de Classe Conceitual
A 1ª versão do diagrama pode nem possuir os atributos ainda. Abaixo a versão com as classes e os métodos acima identificados.
3°Identificação dos Atributos das Classes
O próprio mini mundo já nos traz alguns dados de atributos. Lembra que na aula 8, elaboramos uma tabela para servir de base a construção do MER. 
Que tal, com base nos dados desse estudo de caso, descobrirem os atributos das classes de negócios identificadas.
Saiba mais:
Sugerimos o acesso aos seguintes sites, referentes aos conceitos e práticas inerentes a técnica de Analise Essencial para desenvolvimento de sistemas.
 
Procure explorar todos os links existentes nas URLs abaixo relacionadas.
http://pt.wikipedia.org/wiki/Diagrama_de_transi%C3%A7%C3%A3o_de_estados