Baixe o app para aproveitar ainda mais
Prévia do material em texto
Análise de sistemas orientado a objetos Revisão Conceitos básicos da orientação a objetos 2 Objetivos: � Entender o significado de objetos e classes; � Definir abstração � Definir atributos e operações � Conhecer mecanismos de herança e polimorfismo � Exemplificar encapsulamento Introdução 3 Antes de começarmos a desenvolver orientado a objetos, é preciso, começar a pensar orientado a objetos Mas o que é um objeto? 4 Portanto, objetos são coisas do mundo real, como pessoas, animais etc, que descobrimos estudando suas características (atributos), como altura, tamanho, cor e seu comportamento (ações), como falar, dormir, andar. Além de objetos animados, essa observação inclui também objetos inanimados, como por exemplo: uma bola de futebol, que possui atributos, como diâmetro, cor, peso e ações como rolar, encher chutar etc. O que é abstração? 5 Suponha um conjunto formado pelos seguintes objetos: calculadora, caminhão, impressora, pessoas. Se por exemplo, o propósito fosse desenvolver um sistema de transporte, os demais objetos estariam descartados. Classes 6 Uma Classe é a definição dos atributos e funções de um tipo de objetos; ela descreve um conjunto de objetos individuais em qualquer contexto. Ela é obtida pela classificação de objetos com a mesma estrutura de dados e o mesmo comportamento. Nome da classe Atributos da classe Funções da classe Atributos 7 Os atributos, são recursos de uma classe ou qualquer outro elemento que represente propriedades ou elementos de dados. Em algumas linguagens, os atributos são denominados variável de instancia de classe ou membro de dado. Eles possuem algumas características importantes, como visibilidade (escopo), nome, tipo de dado e valor inicial. A visibilidade de um atributo pode ser: Operações 8 Os objetos interagem e comunicam-se por meio de mensagens, que identificam os métodos a serem executados, no objeto receptor. Para invocar um método de um objeto, enviar-se uma mensagem para ele especificando o nome do objeto, o método a ser executado e a lista de argumentos requeridos. Após a execução, o objeto pode ou não retornar um valor como resposta a mensagem recebida. Herança 9 Juntamente com o Polimorfismo, a Herança é uma das características mais poderosas e importantes da Orientação a objetos, em razão do fato de esta permitir o reaproveitamento de atributos e de métodos, otimizando o tempo de desenvolvimento, além de permitir a diminuição de linhas de código, bem como facilitar futuras manutenções. O conceito de herança trabalha com os conceitos de superclasses e subclasses. Uma superclasse é uma classe que possui classes derivadas dela, chamadas subclasses. As subclasses, ao serem derivadas de uma superclasse, herdam seus atributos e métodos. 10 Polimorfismo 11 Polimorfismo: é o principio pelo qual classes derivadas de uma mesma superclasse, podem invocar operações que tem a mesma assinatura, mas comportamentos diferentes em cada subclasse, produzindo diferentes resultados, dependendo de como cada objeto implementa a operação. Em outra palavras, é a capacidade de objetos diferentes possuírem operações com o mesmo nome e a mesma lista de argumentos, mas que executam tarefas diferentes Encapsulamento 12 Os atributos estão encapsulamento, isto é, envolvidos por código de forma que só é visível na operação em que foi criado. Isso também vale para as operações, quando algumas delas são visíveis apenas pelo próprio objeto. Análise e Projeto Orientados a Objeto com UML e Padrões Parte I Análise, Projeto, e Processo 13 O que é Análise e Projeto? Análise — “o quê” Investigação do problema e dos requisitos Requisitos Casos de uso Restrições Vocabulário Projeto — “como” Descrição de uma solução lógica Objetos Arquitetura Instalação & Operação Interface do usuário Fonte: Livro - Utilizando Uml e Padroes Por Craig Larman O que é APOO? Na essência, considerar um problema e uma solução dentro da perspectiva de objetos, coisas ou conceitos. O que é AOO? » Investigação dos objetos de domínio e seus relacionamentos � Descritos no Modelo de Objetos de Domínio O que é POO? » Elaboração de uma solução lógica em termos de componentes de software e suas colaborações e responsabilidades � Descritos em Diagramas de Classes e Diagramas de Interação Representação de um Conceito na APOO Ex.: O conceito “Livro” em um sistema de biblioteca Conceito de domínio public class Livro { public void imprimir(); private String titulo; } Representação no código Livro título Representação na análise Livro título Representação no projeto imprimir() Fases Planejamento e Elaboração » Concepção inicial, investigação de alternativas, definição de requisitos, etc. Construção » Construção do sistema através de múltiplos ciclos de análise, projeto, implementação e teste Implantação » Instalação e operação do sistema Fase de Planejamento e Elaboração 2. Criar Rel. Prel. de Investigação 3. Definir Requisitos 9. Refinar Plano7. Definir Mod.Conc. Inicial c 4. Reg. Termos no Glossário a 6. Definir Casos de Uso 1. Definir Plano Inicial 5. Implementar Protótipo b, d a. contínua b. opcional c. adiável d. ordem variada 8. Definir Arquit. Inicial a, c, d Notas ConstruçãoPlan. &Elaboração Implantação Fase de Planejamento e Elaboração Atividades: 1. Definir plano inicial � Prazos, recursos, orçamento 2. Criar relatório preliminar de investigação � Motivação, alternativas, necessidades de negócio 3. Definir requisitos � Especificação declarativa dos requisitos 4. Registrar termos no glossário � Dicionário de termos, regras, restrições 5. Implementar protótipo � Protótipo do sistema para ajudar na definição dos requisitos Fase de Planejamento e Elaboração Atividades: 6. Definir casos de uso � Descrição em prosa estruturada dos processos de negócio 7. Definir modelo conceitual inicial � Objetos de domínio e seus relacionamentos 8. Definir arquitetura inicial � Principais subsistemas e suas dependências 9. Refinar plano Fase de Construção Ciclo de Desenv. 1 Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. Ciclo de Desenv. 2 ... ConstruçãoPlan. &Elaboração Implantação Fase de Construção Repetição de ciclos de desenvolvimento » Construção progressiva do sistema até atingir uma versão que satisfaça corretamente os requisitos Atividades típicas de cada ciclo: 1. Refinar plano 2. Sincronizar artefatos 3. Análise 4. Projeto 5. Implementação 6. Teste Ciclos de Desenvolvimento Cada ciclo implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema » Crescimento incremental, através de expansões e refinamentos sucessivos Ciclos com tempo fixo de duas a oito semanas Vantagens: » Evita complexidade excessiva » Antecipa feedback dos usuários Ciclos de Desenvolvimento e Casos de Uso Um ciclo deve atacar um ou mais casos de uso, ou versões simplificadas de casos de uso Casos de uso mais relevantes devem ser atacados nos primeiros ciclos » Prioridade para serviços com grande influência na arquitetura do sistema ou de alto risco Ciclo de Desenv. 1 Caso de uso A Versão Simplificada Ciclo de Desenv. 2 Caso de uso A Versão Completa Ciclo de Desenv. 3 Caso de uso B Caso de uso C Fonte: Livro - UML 2 Guia Pratico Gilleanes T. A. Guedes Análise a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. DefinirCasos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas ... Ciclo de Desenv. 1 Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. Ciclo de Desenv. 2 Análise Subatividades: 1. Definir casos de uso essenciais 2. Refinar diagramas de casos de uso 3. Refinar modelo conceitual 4. Refinar glossário 5. Definir diagramas de seqüência do sistema 6. Definir contratos de operação 7. Definir diagramas de estado Projeto 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classes a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diag. interação b. ordem variada ... Ciclo de Desenv. 1 Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. Ciclo de Desenv. 2 Projeto Subatividades: 1. Definir casos de uso reais 2. Definir relatórios e interfaces com o usuário 3. Refinar arquitetura do sistema 4. Definir diagramas de interação 5. Definir diagramas de classes de projeto 6. Definir esquema do banco de dados Ênfase do Estudo de Caso: Camada de Lógica da Aplicação Apresentação Lógica da Aplicação Armazenamento SGBD Object Store Enter Item End Sale UPC Make Payment Total Quantity Tendered Balance Venda Pagamento BD Segurança Foco principal Foco secundário -objetos de domínio -objetos de serviço Foco menor Estratégia do Curso Aprendizagem e desenvolvimento iterativos APOO aplicada ao sistema POST em dois ciclos de desenvolvimento: » Ciclo 1 Funcionalidades básicas � Introdução das habilidades de análise e projeto pertinentes para o primeiro ciclo » Ciclo 2 Funcionalidades expandidas � Introdução de habilidades adicionais de análise e projeto Definição de Requisitos 2. Criar Rel. Prel. de Investigação 3. Definir Requisitos 9. Refinar Plano7. Definir Mod.Conc. Inicial c 4. Reg. Termos no Glossário a 6. Definir Casos de Uso 1. Definir Plano Inicial 5. Implementar Protótipo b, d a. contínua b. opcional c. adiável d. ordem variada 8. Definir Arquit. Inicial a, c, d Notas ConstruçãoPlan. &Elaboração Implantação Definição de Requisitos Requisitos mal-entendidos ou incorretamente especificados representam um grande risco para o desenvolvimento de software. Especificações bem-feitas requerem uma gama de habilidades e técnicas, cujo estudo detalhado está fora do escopo do curso. Foco: introdução à especificação de requisitos, usando o sistema POST como exemplo. O que são Requisitos? Descrições das necessidades ou desejos para um produto. Usados para identificar e documentar o que é realmente necessário, de uma forma que fique claro para clientes e desenvolvedores. Desafio: » Evitar ambiguidades » Identificar riscos » Coletar e “digerir” dados de fontes variadas de informação (documentos, entrevistas, reuniões, etc.) Descrição de Requisitos Alguns artefatos básicos: » Visão geral � Sumário descrevendo o propósito geral do projeto » Clientes � Quem encomendou ou está pagando pelo sistema » Objetivos � Objetivos a serem alcançados com o sistema » Funções � O que o sistema deve fazer » Atributos � Aspectos não funcionais relevantes Funções Devem ser documentadas e listadas em grupos logicamente coesos Categorias de funcões » Evidente � Deve ser executada, e o usuário deve estar ciente da execução (ex.: Registrar venda, Processar pagamento) » Escondida � Deve ser executada, mas de modo transparente para o usuário (ex.: Guardar informações no BD) » Opcional � Função não afeta os custos ou as outras funções do sistema de maneira significativa Atributos Características ou qualidades não funcionais do sistema » Ex.: facilidade de uso, tolerância a falhas, tempo de resposta, metáfora de interface, etc. Podem estar relacionados com todas as funções, ou ser específicos para uma função ou um grupo de funções particular. Podem ter detalhes (possíveis valores simbólicos para o atributo) e restrições de contorno (intervalos obrigatórios para os valores do atributo) . Artefatos de Requisitos para o Sistema POST Visão geral � O propósito deste projeto é criar um sistema para um terminal de ponto de venda a ser usado em lojas de varejo. Clientes � ObjectStore, Inc., uma cadeia de lojas de venda de componentes de software reutilizáveis. Objetivos � Redução do tempo de espera dos clientes nos caixas. � Análise rápida e acurada das vendas. � Controle automático de estoque. Artefatos de Requisitos para o Sistema POST Funções básicas R1.1 Registrar a venda corrente (itens de compra). evidente R1.2 Calcular total da venda corrente, incluindo imposto e descontos. evidente R1.3 Capturar informação do código de barras dos itens de compra (UPC), via uma leitora de código de barras ou digitação manual. evidente R1.4 Reduzir quantidades do estoque quando a venda for confirmada. escondida R1.5 Registrar venda no log de vendas completadas. escondida R1.6 Operador do caixa deve digitar um ID e senha para usar o sistema. evidente R1.7 Oferecer um mecanismo de armazenamento persistente. escondida Ref # Função Categoria Artefatos de Requisitos para o Sistema POST Atributos tempo de resposta (restrição de contorno) Durante o registro de um item de compra, a descrição e o preço do produto aparecerão em até 5 segundos. Atributo Detalhes e Restrições de Contorno metáfora de interface (detalhe) Janelas e caixas de diálogo baseadas na metáfora de formulários. (detalhe) Maximizar facilidade de navegação via teclado ao invés de via mouse. tolerância a falha (restrição de contorno) Deve registrar pagamentos com cartão de crédito autorizados junto ao sistema de contas a receber dentro de 24 horas, mesmo se houver falha de energia ou nos equipamentos. plataformas de S.O. (detalhe) Microsoft Windows 7/8 Casos de Uso Descrições narrativas de processos do domínio da aplicação. Documentam a sequência de eventos de um ator (um agente externo) usando o sistema para completar, do início ao fim, um determinado processo Representação em UML: Comprar Items Casos de Uso Exemplo de um caso de uso de alto-nível: A UML não especifica um formato rígido para os cabeçalhos e a estrutura de um caso de uso » Podem ser alterados de acordo com as necessidades de documentação Caso de uso: Atores: Tipo: Descrição: Comprar Itens (Buy Items) Cliente (Customer), Operador (Cashier ) primário Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta o pagamento. Ao final, o Cliente sai com os itens. Casos de Uso Exemplo de um caso de uso expandido: I. Caso de uso: II. Atores: III. Propósito: IV. Descrição: I. Comprar Itens com Dinheiro (Buy Items with Cash) II. Cliente (Iniciador), Operador III. Capturar uma venda e seu pagamento em dinheiro. IV. Um Cliente chega no caixa com itens para comprar. O Operador registra os itens e coleta um pagamento com dinheiro. Ao final, o Cliente sai com os itens. Tipo: Referencia: primário e essencial Funções: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1 Típica Sequência de Eventos Ação do Ator Resposta do Sistema 1. Este caso de uso começa quando um Cliente chega no caixa com itens para comprar. Casos de Uso Exemplo de um caso de uso expandido (cont.): Típica Sequência de Eventos Ação do Ator Resposta do Sistema 2. O Operador registra o identificador de cada item. Se há mais de um do mesmo item, o Operador também pode informar a quantidade. 3. Determina o preço do item e adiciona informação sobre o item à transação de venda em andamento. Mostra a descrição e o preçodo item corrente. 4. Após processar o último item, o Operador indica ao POST que a entrada de itens terminou. 5. Calcula e mostra o valor total da venda. 6. O Operador informa o total ao Cliente. . Casos de Uso Exemplo de um caso de uso expandido (cont.): Típica Sequência de Eventos Ação do Ator Resposta do Sistema 7. O Cliente entrega um pagamento em dinheiro, possivelmente maior do que o valor total. 8. O Operador registra o valor recebido em dinheiro. 9. Mostra o troco devido. Emite um recibo. 12. O Cliente sai com os itens comprados. . 10. O Operador deposita o dinheiro e retira o troco devido. O Operador entrega o troco e o recibo ao Cliente. 11. Registra a venda no log de vendas completadas. Atores Entidades externas ao sistema que de algum modo participam da estória do caso de uso » Estimulam o sistema com eventos de entrada, ou recebem alguma coisa dele » Designados pelo papel que exercem no caso de uso � Ex.: Cliente, Operador, etc. Representação em UML: Cliente Atores e Casos de Uso Um caso de uso possui um ator iniciador, que gera o estímulo inicial, e possivelmente vários atores participantes. » O ator iniciador deve ser indicado explicitamente na descrição do caso de uso Algumas categorias típicas de atores incluem: » papeis exercidos por pessoas » sistemas de computação » dispositivos elétricos e mecânicos Identificando Casos de Uso Normalmente não são eventos ou passos individuais, mas um processo completo. » Erro mais comum! Método baseado em atores 1. Identificar os atores relacionados com o sistema ou organização; 2. Para cada ator, identificar os processo que eles iniciam ou participam; Identificando Casos de Uso Método baseado em eventos 1. Identificar os eventos externos aos quais o sistema deve responder 2. Relacionar os eventos a atores e casos de uso Exemplos do sistema POST » Operador: Login, Retirar Dinheiro » Cliente: Comprar Itens, Devolver Itens » Digitar Senha? » Imprimir Recibo? Casos de Uso e Funções Todas as funções do sistema identificadas na especificação dos requisitos devem ser alocadas a casos de usos. » Alocação documentada através da seção Referencia; Idealmente, funções e casos de uso devem ser rastejáveis até a implementação e teste do sistema . Casos de Uso e o Limite do Sistema Identificar os atores e casos de uso de um sistema requer a definição de seu limite de atuação Alguns limites típicos incluem: » o software/hardware de um dispositivo ou sistema de computação » um departamento de uma organização » uma organização inteira Limites diferentes podem resultar em diferentes conjuntos de atores e casos de uso Tipos de Caso de Uso Primário Representam os processos principais ou mais comuns (ex.: Comprar Itens) Secundário Representam processos menos importantes ou mais raros (ex.: Cadastrar Operadores) Opcional Representam processos que podem ser ignorados ou incluídos em futuras versões do sistema (ex.: Solicitar Estoque para um Novo Produto). Casos de Uso no Processo de Desenvolvimento Passos da fase de Planejamento e Elaboração 1. Após as funções do sistema terem sido descritas, defina o limite de atuação do sistema e identifique atores e casos de uso. 2. Escreva todos os casos de uso no formato alto-nível, categorizando-os como primário, secundário ou opcional. 3. Desenhe um diagrama de caso de uso. 4. Relacione casos de uso e ilustre seus relacionamentos no diagrama de caso de uso. 5. Escreva os casos de uso mais importantes ou críticos no formato expandido essencial. 6. Se estritamente necessário, escreva alguns casos de uso no formato real. 7. Ordene os casos de uso por prioridade de desenvolvimento. Casos de Uso no Processo de Desenvolvimento Passos da fase de Construção 1. Análise—Escreva casos de uso expandidos essenciais para aqueles sendo atacados no ciclo de desenvolvimento corrente, se ainda não feito. 2. Projeto—Escreva casos de uso reais para aqueles sendo atacados no ciclo de desenvolvimento corrente, se ainda não feito. Passos do Processo para o Sistema POST Desenhar diagrama de caso de uso Caixa POST Compra Items Cliente Log In Reembolso items comprados Gerente System Administrator Start Up Manage Users etc. Priorizando Casos de Uso Atacar primeiro aqueles com maior influência na estrutura básica do sistema. Características que podem aumentar a prioridade de um caso de uso: » Impacto significativo no projeto da arquitetura » Funções complexas, arriscadas, ou de tempo crítico » Envolve novas pesquisas ou tecnologia emergente » Representa processos primários de negócio » Contribui diretamente para aumentar lucros ou diminuir custos Priorizando Casos de Uso Ordenação baseada em classificação simples de prioridades (ex.: alta-média-baixa) Priorizando os casos de uso do sistema POST Caso de Uso Média Manter Usuários Log In Devolver Itens Alta Comprar Itens Baixa Retirar Dinheiro Inicializar Encerrar Prioridade Justificativa Afeta sub-domínio de segurança Afeta sub-domínio de segurança Afeta contabilidade Processo primário de negócio Mínimo efeito na arquitetura Depende de outros casos de uso Mínimo efeito na arquitetura Modelo Conceitual Artefato mais importante da AOO Representa conceitos relevantes (do ponto de vista do modelador) do domínio do problema Na UML, ilustrado com diagramas de estruturas estáticas contendo: » Conceitos » Associações entre conceitos » Atributos de conceitos Modelo Conceitual para o Sistema POST Diagrama parcial POST Item Loja endereço nome Venda date hora Pagamento Valor total Vendas Itens linha quantidade Abastecido em * Casas 1..* Contido em 1..* Registros de vendas 0..1 pagar 1 1 1 1 1 1 1 1 Enviado para 4 Conceitos Associação Atributos Associações Uma associação é um relacionamento entre conceitos que indica uma conexão significativa e interessante Descritos na UML como “relacionamentos estruturais entre objetos de tipos diferentes” Indicam conhecimento de um relacionamento que precisa ser preservado durante algum tempo » Duração de milisegundos ou anos, dependendo do contexto Associações Notação na UML » Uma linha entre dois conceitos mais um nome » Inerentemente bidirecional » Pode conter um seta de direção de leitura » Pontas podem conter expressões de cardinalidade VendaPOST Registros-correntes 4 11 association name multiplicity -“seta de direção leitura" -Muitas vezes excluidos Ele não tem qualquer relação, com exceção para indicar a direção da leitura da etiqueta associada Cada ponta de uma associação é chamada de um “papel” Um papel pode ter: » Nome » Expressão de multiplicidade » Navegabilidade Papeis de Uma Associação ItemLoja Estoque * Multiplicidade de papeis 1 O valor da multiplicidade depende do contexto » Ex.: Pessoa Trabalha-para Empresa Expressões de Multiplicidade zero ou mais; “muitos" Um ou mais Um para 40 Exatamente cinco T T T T * 1..* 1..40 5 T3, 5, 8 Exatamente três,Cinco ou oito Atributos Um atributo é um dado lógico de um objeto do domínio Definidos para conceitos cujos requisitos (casos de uso) sugerem a necessidade de preservar algum tipo de informação » Ex.: atributos data e hora para o conceito Venda Notação na UML Venda data Hora inicio : hora atributos Identificando Atributos Atributos devem preferencialmente representar tipos primitivos de dados ou de valores simples » Ex.: Data, Número, Texto, Hora, Endereço, etc.Atributos não devem ser usados para: » Representar um conceito complexo » Relacionar conceitos (atributo “chave-estrangeira”) Caixa name atualPOST Caixa name POST numero Uses ruim bom Não é um simples atributo... 1 1 Registrando Termos no Glossário Um glossário ou dicionário de modelo é um documento que define os termos (ou vocabulário) do domínio » Similar a um dicionário de dados usado na modelagem de BD Fundamental para garantir uma comunicação consistente e um entendimento compartilhado entre usuários e desenvolvedores Também pode ser usado para registrar restrições de domínio e regras de negócio (não explorado no curso) Glossário Parcial para o Sistema POST Categoria atributo Uma descrição sucinta de um item de venda. caso de uso Descrição do processo de um cliente comprando itens numa loja. tipo Um item à venda numa loja. tipo Um pagamento em dinheiro. Comentário atributo O preço de um item de venda. Termo Especificação-Produto.descrição :Texto Comprar Itens Item Pagamento Especificação-Produto.preço :Quantidade atributo A quantidade de um tipo particular de item comprado. tipo Uma transação de venda. tipo Um item particular comprado como parte de uma venda. Item de Venda.quantidade :Inteiro Venda Item de Venda a. se ainda não feito b. contínuo c. opcional 2. Refinar Diag. Casos de Uso 3. Refinar Modelo Conceitual 4. Refinar Glossário b 6. Definir Contrat. de Operação 1. Definir Casos de Uso Essenciais a 5. Definir Diag. Seq. 7. Definir Diag. Estado c Notas Sinc. Artefatos Análise Projeto Teste Refin. Plano Impl. Um Ciclo de Desenvolvimento
Compartilhar