Análise e Projeto Orientado a Objetos

Transcrição

1 Universidade Estadual Vale do Acaraú Apresentação Gradução: Bacharelado em Ciências da Computação UVA Análise e Projeto Orientado a Objetos Prof. Raquel Silveira Pós-Graduação: Especialização em Engenharia de Software INTA Mestrado Acadêmico em Ciências da Computação UECE (em andamento) Atividades Profissionais Analista de Sistemas no Instituto Altântico Prof. Faculdade IEducare (FIED) Prof. Instituto de Pesquisa Vale do Acaraú (IVA) Prof. Instituto Federal de Educação, Ciência e Tecnologia Títulos Certificações SCJP e CBTS Disponibilização de Material / Contato RUP Rational Unified Process Grupo da disciplina: raquelsilveira.wordpress.com de contato: raquel.vsilveira@hotmail.com Site de apoio: Processo de Engenharia de Software. Abordagem baseada em disciplinas. Objetivo: Garantir produção de software com qualidade, que atenda às necessidades dos clientes, dentro de um cronograma e orçamento possíveis. RUP Rational Unified Process Por Onde Começar? Identificação das Necessidades 1. Reunião: Responder a pergunta Por que vamos desenvolver um software? 2. Responder questões do tipo: Qual a função do sistema? Qual o desempenho esperado? Qual o nível de confiabilidade? Qual a tecnologia disponível? Qual a tecnologia disponível? Integração com outros sistemas? 1

2 Por Onde Começar? RUP Rational Unified Process Identificação das Necessidades 3. Uma vez definidos os objetivos gerais do sistema, determinar: Existe tecnologia para construir o sistema? Quais recursos especiais de desenvolvimento e produção serão exigidos? Quais os limites foram estabelecidos para os custos e prazos? Como fazer isso no RUP? O que é é uma linguagem de diagramação ou notação para especificar, visualizar e documentar modelos de sistemas de software orientados a objeto. O que não é não é um método de desenvolvimento. Quem desenvolve e mantém A UML é controlada pelo Grupo de Gerenciamento de Objeto (Object Management Group OMG) e é um padrão da indústria para descrever graficamente software. Mas auxilia a visualizar seu desenho e a comunicação entre objetos. Principais modelos suportados - Diagramas de estrutura: Diagrama de Classe Diagrama de Componente Diagrama de Colaboração - Diagrama de comportamento: Diagrama de Diagrama de Estado Diagrama de Atividade - Diagrama de interação: Diagrama de Sequência 2

3 Artefatos Relevantes Modelo de caso de uso Detalhamento Do caso de uso Glossário Especificação De Requisitos Técnicas existentes: -Entrevista -Questionário -Observação direta -Sessões brainstorming Tipos de Requisitos Requisitos funcionais: Declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Requisitos não funcionais Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. Requisitos de domínio Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio. Requisitos Funcionais - Descrevem a funcionalidade ou serviços de sistema. - Dependem do tipo de software, dos usuários esperados e o tipo de sistema onde o software é usado. - Requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer mas os requisitos funcionais de sistema devem descrever os serviços de sistema em detalhe. Sistema de Biblioteca Um sistema de biblioteca fornece uma interface única para uma série de artigos em bibliotecas diferentes. Os usuários podem pesquisar, baixar e imprimir estes artigos para estudo pessoal. - Quais os requisitos funcionais podemos identificar neste sistema? 3

4 Requisitos Não Funcionais - Estes definem propriedades e restrições de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos de armazenamento. - Restrições são capacidade de dispositivos de E/S, representações de sistema, etc. - Requisitos não funcionais podem ser mais críticos do que os requisitos funcionais. Se estes não forem atendidos, o sistema é inútil. Requisitos Não Funcionais Organizacionais: Refere-se a políticas e procedimentos nas organizações do cliente e do desenvolvedor. Ex.: De entrega, de implementação, padrões de processo. Externos: Refere-se a fatores externos ao sistema e ao processo de desenvolvimento. Ex.: Interação do sistema com outros, éticos, legais, privacidade e de segurança. De produto: Especificam o comportamento do produto. Ex.: Eficiência (desempenho, espaço, rapidez, memória), confiabilidade, portabilidade. Requisitos Não Funcionais Ambiente Físico: Refere-se ao ao equipamento onde o software funcionará. Interfaces: Refere-se a saída vai para outro ou outros sistemas. Funcionalidade: Refere-se a limitações quanto à velocidade de execução, ao tempo de resposta, ou a saída. Os usuários e os fatores humanos: Refere-se a diversidade de tipos de usuários. Sistema de Biblioteca O cliente afirma que o sistema deve ser rápido, não podendo ultrapassar uma média de 3 segundos por operação. Além disso, o idioma do sistema deve ser português e inglês. -Quais os requisitos não-funcionais podemos identificar este sistema? -Que outros requisitos não-funcionais podemos sugerir? Meta x Requisitos Requisitos não funcionais podem ser muito difíceis de definir precisamente e requisitos imprecisos podem ser difíceis de verificar. Meta: Uma intenção geral do usuário tal como facilidade de uso. Requisito não funcional verificável Uma declaração usando alguma medida que pode ser objetivamente testada. Exemplo: Meta x Requisitos. Meta do sistema: O sistema deve ser fácil de ser usado por todos os usuários e ser organizado de modo que os erros dos usuários sejam minimizados. Requisito não-funcional verificável Os usuários devem ser capazes de usar todas as funções do sistema depois de um treinamento de 2 horas. Após esse treinamento, o número médio de erros cometidos pelos usuários não deve exceder dois por dia. 4

5 Requisitos de Domínio REQUISITOS DE DOMÍNIO - Derivados do domínio de aplicação e descrevem características de sistema que refletem o domínio. - Podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados. - Se os requisitos de domínio não forem satisfeitos, o sistema pode não funcionar. Exemplo: Sistema de Biblioteca Devido às restrições de direitos autorais, alguns documentos devem ser excluídos imediatamente na chegada. Dependendo dos requisitos de usuário, esses documentos serão impressos localmente no servidor de sistema para serem encaminhados manualmente para o usuário ou direcionados para uma impressora de rede. Problemas REQUISITOS DE DOMÍNIO Entendimento: - Requisitos são expressos na linguagem do domínio de aplicação; - Isso não é, freqüentemente, compreendido pelos engenheiros de software que estão desenvolvendo o sistema. Implícito - Especialistas em domínio compreendem a area tão bem que não pensam em tornar os requisitos de domínio explícitos. Requisito 1. O relatório deve ser gerado em no máximo 10 segundos. 2. O sistema deve ser capaz de emitir um relatório de controle de estoque. 3. O percentual do lucro deve ser calculado da seguinte forma: Preço de venda Média de preço de compra das últimas 10 compras 4. O sistema deve possuir restrição das funcionalidades de acordo com o usuário. 5. O sistema deve ser instalado em máquina cliente com capacidade mínima de 2Gb de disco disponível. 6. O sistema deve possuir um cadastro de produtos que permita inserir, atualizar, remover e pesquisar os produtos. 7. O sistema deve ser internacionalizável. Tipo Dada a seguinte especificação, defina os requisitos funcionais, nãofuncionais e de domínio. Sistema de controle de cheques O banco X está renovando seu sistema de cheques e precisa armazenar informações de seus clientes, assim como dos cheques e todas as transações realizadas para o cheque. A quantidade máxima de passos para realizar uma transação não deve ultrapassar 3 menus. O banco possui um cálculo matemático que define a taxa de juros caso o cheque não seja compensado. A quantidade mínima de memória por máquina deve 1Gb. O sistema deve possuir segurança de acesso dos usuários através da autenticação por meio de teclado virtual. -Os usuários de um sistema não estão nem um pouco interessados na estrutura interna ou em detalhes técnicos do sistema. -Sua principal preocupação é definir, junto com os analistas, como o sistema os auxiliará a realizar suas tarefas. -Um caso de uso descreve, do ponto de vista dos atores, um grupo de atividades num sistema que produz um resultado concreto e tangível. -A idéia é modelar o sistema de acordo com seus usários e não o contrário. 5

6 -O modelo de casos de uso é uma representação das funcionalidades externamente observáveis de um sitema e dos elementos externos ao sistema que interagem com ele. -O modelo de caso de uso não considera os aspectos internos da implementação do sistema. -É uma forma do engenheiro de requisitos especificar os limites e as funcionalidades do sistema. -Permite: -Que clientes e usuários validem o sistema; -Que os desenvolvedores do sistema construam o que é esperado. -Componentens: -Casos de uso -Atores Diagrama de É um diagrama usado para se identificar como o sistema se comporta em várias situações que podem ocorrer durante sua operação. Descreve o sistema, seu ambiente e a relação entre os dois. Os componentes deste diagrama são os atores e os Use Case. Ator É qualquer entidade que interage com o sistema. Pode ser uma pessoa, outro sistema, etc. Não é parte do sistema. Representa os papéis que o usuário do sistema pode desempenhar. Pode interagir ativamente com o sistema. Pode representar um ser humano, uma máquina ou outro sistema. ator Use case Nome do Ator Use Case É uma seqüência de ações que o sistema executa e produz um resultado de valor para o ator. Modela o diálogo entre atores e o sistema. É iniciado por um ator para invocar uma certa funcionalidade do sistema. É um fluxo de eventos completo e consistente. O conjunto de todos os Use Case representa todos as situações possíveis de utilização do sistema. Nome do use case Um supermercado deseja implantar um sistema para controlar o estoque. A venda pode ser realizada de forma a prazo, para isso será necessário informar o cliente. Cada produto deve possuir uma quantidade mínima de estoque. Quando esta quantidade for alcançada, o sistema deve emitir um alerta informando que o produto está acabando. Ao efetuar uma venda, o sistema deve emitir um cupom fiscal. Caso o pagamento seja a prazo, o sistema deve gerar boletos bancários. Os produtos devem ter associação com seus fornecedores. O sistema deve emitir relatório de venda por período. Informações técnicas: Idioma: português. SO: Windows XP. Interface: 800 x

7 Tipos de Interação Comunicação Representa quais atores estão ligados a quais casos de uso. Inclusão Um caso inclui (precisa de, é composto de) outro. Extensão Um caso de uso pode opcionalmente utilizar um outro. Generalização Um caso de uso é dividido em outros casos de uso. Automação de uma clínica odontológica O sistema deve conter um cadastro de todos os clientes. O sistema deve ter um histórico de todas as consultas do cliente. Ao ligar para a clínica, o sistema disponibiliza para a atendente uma agenda contendo todos os dias disponíveis para consulta, assim como os horários marcados e os disponíveis. Para que o sistema possa dispor de dados para montar esta agenda, é necessário ter um cadastro dos dias disponíveis para a consulta e uma opção para agendamento da ligação. A opção de agendamento da ligação deve estar disponível juntamente com a agenda disponibilizada a atendente no momento da ligação. A qualquer momento, a atendente pode gerar um relatório de todas as consultas a serem realizadas de acordo com um determinado período. O sistema deve emitir um alerta no momento de cada consulta marcada,mostrando o cliente que deve ser consultado naquele momento. Tipos de Especificação de Casos de Uso Descrição inicial Nome: Atores: Descrição Descrição base Nome: Atores: Descrição: Fluxo Básico Descrição elaborada Nome: Atores: Descrição: Fluxo Básico: Fluxo Alternativo: Exceções: Pré-condição: Pós-condição: Requisitos Especiais: Inclusões: Extensões: Regras de negócio: 7