Engenharia de Software II

Transcrição

1 Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Engenharia de Software II Aula 01 (rogerio@fct.unesp.br) Bibliografia Básica PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional, 7ª Edição, McGraw-Hill- Bookman, Porto Alegre, SOMMERVILLE, I. Engenharia de software, 9ª Edição, Ed. Pearson Prentice Hall, São Paulo, PETERS, J.F., PEDRYCZ, W. Engenharia de software: teoria e prática, Editora Campus, Rio de Janeiro, PFLEEGER, S. L., Engenharia de Software, Teoria e Prática. Pearson Brasil,

2 Avaliação As notas de todas as atividades entre 0 (zero) e 10,0 (dez) serão atribuídas individualmente, mesmo em atividades em grupo; A média final será calculada da seguinte maneira: MA = (NP1 + 2*NP2)/3 Mt = (NT1 + NT NTn) / n MT = (8 * NPJ + 2 * Mt) Média Final: MF = (8*MA + 2*MT)/10 SE E SOMENTE SE (MA>=5 E MT>=5) Caso contrário (MA<5 OU MT<5) MF = Menor Nota (MA ou MT) Onde: MF = Média Final. MA = Média de Provas Mt = Média de Trabalho (exercícios e atividades ao longo da disciplina) NPJ = Nota Projeto MT = Média final dos trabalhos (parte prática) Caso o aluno não obtenha a nota mínima para aprovação, será aplicado o Regime Especial de Recuperação 4 3 Tópicos da Disciplina Gerenciamento de projetos de software Gerenciamento de riscos Gerenciamento de times Qualidade de software 2

3 Metodologia Aulas expositivas teórico-práticas; Exercícios práticos; Projetos individuais e/ou em grupo; Trabalhos teóricos sobre tópicos abordados e relacionados 7 5 Abordagem Prática Vantagens Mão na massa Prática Fixação Problemas potenciais Falta de comprometimento dos alunos Dependência inter-grupos Importante a responsabilidade e consideração dos grupos com os colegas O sucesso depende de vocês! 3

4 Engenharia de Software PROCESSO DE SOFTWARE A aplicação de uma abordagem sistemática, disciplinada e possível de ser medida para o desenvolvimento, operação e manutenção do software (IEEE) 8 Qualidade de Software Usuário Definição Desenvolvedor Organização requisitos de software produto Avaliação requisitos atendidos PROCESSO DE SOFTWARE Processo de Desenvolvimento SOFTWARE PRODUTO 9 SOFTWARE COM QUALIDADE 4

5 O Processo de Software Abrange um conjunto de três elementos fundamentais: Métodos, Ferramentas e Procedimentos para projetar, construir e manter grandes sistemas de software de forma profissional 10 O Processo de Software MÉTODOS: proporcionam os detalhes de como fazer para construir o software Planejamento e estimativa de projeto Análise de requisitos de software e de sistemas Projeto da estrutura de dados Algoritmo de processamento Codificação Teste Manutenção 11 5

6 O Processo de Software FERRAMENTAS: dão suporte automatizado aos métodos. Existem atualmente ferramentas para sustentar cada um dos métodos Quando as ferramentas são integradas, é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering 12 O Processo de Software PROCEDIMENTOS: constituem o elo de ligação entre os métodos e ferramentas Seqüência em que os métodos devem ser aplicados Produtos que se exige que sejam entregues Controles que ajudam assegurar a qualidade e coordenar as alterações Marcos de referência que possibilitam administrar o progresso do software. 13 6

7 Fases Genéricas dos Modelos de Processo de SOFTWARE Independentemente da natureza do projeto e aplicação os modelos de processo de software possuem: fase de definição fase de desenvolvimento fase de manutenção atividades de apoio Fase de Definição do Processo de Software focaliza "o que" será desenvolvido que informação vai ser processada que função e desempenho são desejados que comportamento pode ser esperado do sistema que interfaces vão ser estabelecidas que restrições de projeto existem que critérios de validação são exigidos para definir um sistema bem sucedido que tarefas serão realizadas 7

8 Fase de Definição do Processo de Software focaliza "o que" será desenvolvido que informação vai ser processada três tarefas principais ocorrem de alguma forma: que função e desempenho são desejados que comportamento pode ser esperado do sistema engenharia de sistemas que interfaces vão ser estabelecidas planejamento do projeto de software que restrições de projeto existem que critérios de análise validação de requisitos são exigidos para definir um sistema bem sucedido 16 Fase de Desenvolvimento do Processo de Software Focaliza "como" o software será desenvolvido como os dados vão ser estruturados como a função vai ser implementada como uma arquitetura de software como os detalhes procedimentais vão ser implementados como as interfaces vão ser caracterizadas como o projeto será traduzido em uma linguagem de programação como os testes serão efetuados 17 8

9 Fase de Desenvolvimento do Processo de Software Focaliza "como" o software será desenvolvido como os dados vão ser estruturados três tarefas técnicas específicas deverão como a função vai ser implementada como uma arquitetura de software ocorrer sempre: projeto de software como os detalhes procedimentais vão ser implementados geração de código como as interfaces vão ser caracterizadas Inspeção e teste de software como o projeto será traduzido em uma linguagem de programação como os testes serão efetuados 18 Fase de Manutenção do Processo de Software focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional A fase de manutenção reaplica os passos das fases de definição e desenvolvimento, mas faz isso no contexto de um software existente. 19 9

10 Fase de Manutenção do Processo de Software focaliza as "mudanças" que ocorrerão depois que o software for liberado para uso operacional As mudanças estão associadas com correção de erros/defeitos adaptações exigidas conforme o ambiente do software evolui mudanças devido a melhoramentos ocorridos por alterações nos requisitos dos clientes A fase de manutenção reaplica os passos das fases de definição e desenvolvimento, mas faz isso no contexto de um software existente 20 Atividades de Apoio ao Processo de Software As três fases genéricas do processo de software são complementadas por uma série de atividades de apoio. As atividades de apoio são aplicadas durante toda a engenharia do software 21 10

11 Atividades de Apoio ao Processo de Software As três fases genéricas do processo de software são complementadas por uma série de atividades de Atividades apoio. típicas nessa categoria são: Controle As atividades e Acompanhamento de apoio são do aplicadas Projeto durante de Software toda a Revisões engenharia Técnicas do software Formais Garantia de Qualidade de Software Gerenciamento de Configuração de Software Preparação e Produção de Documentos Gerenciamento de Reusabilidade Medidas 22 Modelos de Processo de Software Existem vários modelos de processo de software (ou paradigmas de engenharia de software) Cada um representa uma tentativa de colocar ordem em uma atividade inerentemente caótica Pode-se citar os seguintes modelos de processo de software 23 11

12 Modelos de Processo de Software O Modelo Seqüencial Linear também chamado Modelo Cascata O Modelo de Prototipação O Modelo RAD (Rapid Application Development) Modelos Evolutivos de Processo de Software O Modelo Incremental O Modelo Espiral O Modelo de Montagem de Componentes O Modelo de Desenvolvimento Concorrente Modelo de Métodos Formais Técnicas de Quarta Geração 24 Modelos de Processo de Software O Modelo Seqüencial Linear também chamado Modelo Cascata O Paradigma de Prototipação O Modelo RAD (Rapid Application Development) Modelos Evolutivos de Processo de Software O Modelo Incremental O Modelo Espiral O Modelo de Montagem de Componentes O Modelo de Desenvolvimento Concorrente Modelos de Métodos Formais Técnicas de Quarta Geração 25 12

13 O Modelo Cascata modelo mais antigo e o mais amplamente usado da engenharia de software modelado em função do ciclo da engenharia convencional requer uma abordagem sistemática, seqüencial ao desenvolvimento de software o resultado de uma fase se constitui na entrada da outra 26 O Modelo Cascata Engenharia de Sistemas Análise de Requisitos Projeto Codificação Testes Manutenção 27 13

14 Método Larman: Planejar e Elaborar Planejar e Elaborar Construir Implantar 1. Definir Plano Inicial 2. Criar Relatório de Investigação Preliminar 3. Definir Requisitos a ongoing b opcional c adiável d ordem variada 4. Registrar Termos no Glossário a 7. Definir Modelo Conceitual Inicial c 5. Implementar Protótipo bd 8. Definir Arquitetura Inicial do Sistema acd 6. Definir Casos de Uso (Alto Nível e Essenciais) 9. Aperfeiçoar (Refinar) Plano 28 Método Larman Planejar e Elaborar Construir Implantar 1. Definir Plano Inicial 2. Criar Relatório de Investigação Preliminar Engenharia de Requisitos 3. Definir Requisitos 4. Registrar Termos no Glossário 5. Implementar Protótipo 6. Definir Casos de Uso (Alto Nível e Essenciais) Definir Modelo Conceitual Inicial 8. Definir Arquitetura Inicial do Sistema 9. Aperfeiçoar (Refinar) Plano 14

15 Desenvolvimento Iterativo Planejar e elaborar Construir Instalar Ciclo de Desenvolvimento 1 Ciclo de Desenvolvimento 2 Refinar Plano Sincronizar Artefatos Analisar Projetar Construir Testar 30 Método Larman Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Essenciais 4. Refinar Glossário 2. Refinar Diagramas de Casos de Uso 3. Refinar o Modelo Conceitual 5. Definir Diagramas de Seqüência do Sistema Definir Contratos de Operação 7. Definir Diagramas de Estado 15

16 Método Larman Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Essenciais 4. Refinar Glossário 2. Refinar Diagramas de Casos de Uso 3. Refinar o Modelo Conceitual 5. Definir Diagramas de Seqüência do Sistema Definir Contratos de Operação 7. Definir Diagramas de Estado Método Larman Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Essenciais 4. Refinar Glossário 2. Refinar Diagramas de Casos de Uso 3. Refinar o Modelo Conceitual 5. Definir Diagramas de Seqüência do Sistema Definir Contratos de Operação 7. Definir Diagramas de Estado 16

17 Desenvolvimento Iterativo Planejar e elaborar Construir Instalar Refinar Plano Ciclo de Desenvolvimento 1 Sincronizar Artefatos Ciclo de Desenvolvimento 2 Analisar Projetar Construir Testar Próximo passo Atividades da Fase Projetar Refinar Plano Sincronizar artefatos Analisar Projetar Construir Testar Definir Casos de Uso Reais 3. Refinar a arquitetura do sistema 5. Definir Diagramas de Classes de Projeto 2. Definir Relatórios, IU e Storyboards 4. Definir Diagramas de Interação 6. Definir o Esquema Do Banco de Dados 17

18 Refinar Plano Atividades da Fase Projetar Sincronizar artefatos Analisar Projetar Construir Testar 1. Definir Casos de Uso Reais 3. Refinar a arquitetura do sistema 5. Definir Diagramas de Classes de Projeto 2. Definir Relatórios, IU e Storyboards 4. Definir Diagramas de Interação 6. Definir o Esquema Do Banco de Dados 36 Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Padrões de Projeto (revisão) Uma breve introdução e GRASP 18

19 Padrões Desenvolvedores de software experientes criaram um repertório de princípios gerais e boas soluções para guiar a construção de softwares Essas soluções foram descritas em um formato padronizado (nome, problema, solução) e podem ser usadas em outros contextos 38 Padrões Padrões usualmente não contêm novas idéias organizam conhecimentos e princípios existentes, testados e consagrados Padrão é uma descrição nomeada de um problema e uma solução, que pode ser aplicado em novos contextos 39 19

20 Padrões GRASP GRASP = General Responsibility Assignment Software Patterns Descrevem princípios fundamentais de atribuição de responsabilidade a objetos Alguns padrões GRASP principais: Especialista (Expert) Criador (Creator) Coesão alta (High Cohesion) Acoplamento fraco (Low Coupling) Controlador (Controller) 40 Controlador Problema: Quem deve ser responsável por tratar um evento do sistema? Solução: A responsabilidade de receber ou tratar as mensagens de eventos (operações) do sistema pode ser atribuída uma classe que: represente todo o sistema, um dispositivo ou um subsistema chamado de controlador fachada - OU represente um cenário de um caso de uso dentro do qual ocorra o evento TratadorDe<NomeDoCasoDeUso>, ControladorDe<NomeDoCasoDeUso> 41 20

21 Controlador Exemplo: quem vai tratar os eventos do sistema TPV? Comprar Itens :Sistema :Caixa iniciarnovavenda( ) entraritem(cup, quantidade) descrição item, total *[mais itens] terminarvenda() fazerpagamento(quantia) troco, recibo 42 Exemplo ID Item Quantidade :Caixa Entrar Item açãoexecutada(eventodaação) Camada de Interface Camada do Domínio :CWindow :???? entraritem(itemid, quantidade) 43 21

22 Exemplo: Opções de Controlador todo o sistema (controlador fachada): TPV entraritem( ) :TPV um tratador artificial do caso de uso: ControladorDeComprarItem entraritem( ) :ControladorDe ComprarItem 44 Discussão: Controladores Fachada Um controlador fachada deve ser um objeto (do domínio) que sugira uma cobertura sobre outras camadas e que seja o ponto principal para as chamadas provenientes da interface com o usuário ou de outros sistemas pode ser uma abstração de uma entidade física ex: TPV pode ser um conceito que represente o sistema ex: sistematpv São adequados quando não há uma quantidade muito grande de eventos de sistema Não é possível redirecionar mensagens do sistema para controladores alternativos (ex: outros subsistemas ) 45 22

23 Discussão :Controladores de Casos de Uso Deve existir um controlador diferente para cada caso de uso Não é um objeto do domínio, e sim uma construção artificial para dar suporte ao sistema. Ex: ControladorDeComprarItem, ControladorDeDevolução Pode ser uma alternativa se a escolha de controladores fachada deixar a classe controladora com alto acoplamento e/ou baixa coesão (controlador inchado por excesso de responsabilidade) É uma boa alternativa quando existem muitos eventos envolvendo diferentes processos. 46 Controladores inchados Classe controladora mal projetada - inchada coesão baixa falta de foco e tratamentos de muitas responsabilidades Sinais de inchaço: uma única classe controladora tratando todos os eventos, que são muitos. Comum com controladores fachada o próprio controlador executa as tarefas necessárias para atender o evento, sem delegar para outras classes (coesão alta, não especialista) controlador tem muitos atributos e mantém informação significativa sobre o domínio, ou duplica informações existentes em outros lugares 47 23

24 Controlador Curas para controladores inchados acrescentar mais controladores misturar controladores fachada e de casos de uso delegar responsabilidades Corolário: objetos de interface (como objetos janela ) e da camada de apresentação não devem ter a responsabilidade de tratar eventos do sistema 48 Controlador Benefícios: aumento das possibilidades de reutilização de classes e do uso de interfaces plugáveis. conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso, garantindo a seqüência correta de execução de operações 49 24

25 Exemplo ID Item Quantidade :Caixa Camada de Interface Entrar Item açãoexecutada(eventodaação) :CWindow entraritem(itemid, quantidade) Camada do Domínio :TPV :Venda 50 criaritemlinhavenda (itemid, quantidade) Especialista Problema: qual é o princípio mais básico de atribuição de responsabilidades a objetos? Solução: Atribuir responsabilidade ao especialista da informação. Exemplo: no sistema TPV, alguma classe precisa conhecer o total geral de uma venda 51 25

26 Exemplo Venda conhece o total da venda ItemLinhaVenda conhece o subtotal da linha EspecificaçãoProduto conhece o preço do produto. 52 t:=obtertotal( ) :Venda 1*: st:=obtersubtotal( ) * :LinhadeItemdeVenda 1.1: p:=obterpreço( ) 53 :Especificaçãode Produto 26

27 Especialista Discussão É o padrão mais utilizado Fazê-lo eu mesmo objetos fazem coisas relacionadas à informação que têm Lembrar que existem especialistas parciais que colaboram numa tarefa informação espalhada comunicação via mensagens Tem uma analogia no mundo real 54 Especialista 55 Benefícios: Mantém encapsulamento favorece o acoplamento fraco O comportamento fica distribuído entre as classes que têm a informação necessária (classes leves ) favorece alta coesão Contra-indicações contra indicado quando aumenta acoplamento e reduz coesão Ex: quem é responsável por salvar uma Venda no banco de dados? 27

28 Criador Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe? Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira: B agrega objetos de A B contém objetos de A B registra objetos de A B usa objetos de A B tem os valores iniciais que serão passados para objetos de A, quando de sua criação 56 Criador Exemplo: No sistema TPV, quem é responsável pela criação de uma instância de ItemLinhaVenda? criaritemlinha (quantidade) Venda contém vários itens de linha de venda :Venda 1:criar(quantidade) :ItemLinhaVenda 57 28

29 Criador Discussão objetivo do padrão: definir como criador o objeto que precise ser conectado ao objeto criado em algum evento escolha adequada favorece acoplamento fraco objetos agregados, contêineres e registradores são bons candidatos à responsabilidade de criar outros objetos algumas vezes o candidato a criador é o objeto que conhece os dados iniciais do objeto a ser criado Ex: Venda e Pagamento 58 Exemplo fazerpagamento(quantia) :Venda Venda possui dados iniciais do pagamento 1:criar(quantia) :Pagamento 59 29

30 Criador Benefícios favorece o acoplamento fraco provavelmente o acoplamento não é aumentado porque o objeto criado provavelmente já é visível para o objeto criador, devido às associações existentes que motivaram sua escolha como criador 60 Acoplamento Acoplamento: dependência entre elementos (classes, subsistemas, ), normalmente resultante de colaboração para atender a uma responsabilidade O acoplamento mede o quanto um objeto está conectado a, tem conhecimento de ou depende de outros objetos acoplamento fraco (ou baixo) um objeto não depende de muitos outros acoplamento forte (ou alto) um objeto depende de muitos outros 61 30

31 Acoplamento Problemas do acoplamento alto: mudanças em classes interdependentes forçam mudanças locais dificulta a compreensão do objetivo de cada classe dificulta reutilização 62 Acoplamento Fraco Problema: como favorecer a baixa dependência e aumentar a reutilização? Solução: Atribuir responsabilidade de maneira que o acoplamento permaneça baixo. Exemplo: No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 63 31

32 Qual? Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV fazerpagamento( ) 1: criar( ) :TPV p:pagamento 2 : adicionarpagamento(p) Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV 1: fazer Pagamento( ) :Venda :Venda 1.1: criar( ) 64 :Pagamento Qual projeto é melhor? Qual dos projetos anteriores favorece o acoplamento fraco? em ambos os casos, Venda será acoplada a (terá conhecimento de) Pagamento projeto 1 acoplamento entre Pagamento e TPV projeto 2 não aumenta acoplamento PREFERÍVEL 65 32

33 Formas de Acoplamento Um objeto tem um atributo que referencia um objeto de outra classe Um objeto tem um método que referencia um objeto de outra classe parâmetro, variável local ou retorno Um objeto invoca os serviços de um objeto de outra classe Uma classe é subclasse de outra, direta ou indiretamente 66 Acoplamento Fraco Discussão: Acoplamento fraco classes mais independentes reduz impacto de mudanças favorece reuso de classes Considerado em conjunto com outros padrões Extremo de acoplamento fraco não é desejável fere princípios da tecnologia de objetos comunicação por mensagens projeto pobre: objetos inchados e complexos, responsáveis por muito trabalho baixa coesão 67 33

34 Acoplamento Fraco Discussão: dica: concentre-se em reduzir o acoplamento em pontos de evolução ou de alta instabilidade do sistema ex: cálculo de impostos terceirizados no sistema TPV Benefícios: classe são pouco afetadas por mudanças em outras partes classes são simples de entender isoladamente conveniente para reutilização 68 Coesão Coesão mede o quanto as responsabilidades de um elemento (classe, objeto, subsistema, ) são fortemente focalizadas e relacionadas Objeto com Coesão Alta objeto cujas responsabilidades são altamente relacionadas e que não executa um volume muito grande de trabalho Objeto com Coesão Baixa objeto que faz muitas coisas não relacionadas ou executa muitas tarefas difícil de compreender, reutilizar e manter constantemente afetadas por mudanças 69 34

35 Coesão Alta Problema: Como manter a complexidade sob controle? Solução: Atribuir responsabilidade de tal forma que a coesão permaneça alta. Exemplo (o mesmo para o acoplamento fraco): No sistema TPV, suponha que queremos criar uma instância de pagamento e associá-la à venda. Qual classe deve ser responsável por essa tarefa? 70 Exemplo Projeto 1: segundo padrão Criador, responsabilidade atribuída ao TPV fazerpagamento( ) :TPV 1: criar( ) 2 : adicionarpagamento(p) p:pagamento :Venda O TPV toma parte na responsabilidade de fazer pagamento. Neste exemplo, isso seria aceitável, mas o que aconteceria se houvessem 50 mensagens recebidas por TPV? 71 35

36 Exemplo Projeto 2: alternativa responsabilidade atribuída à Venda fazerpagamento( ) :TPV 1: fazer Pagamento( ) 1.1: criar( ) :Venda :Pagamento Esta solução favorece uma coesão mais alta em TPV e também um acoplamento mais fraco. Portanto, projeto 2 é preferível. 72 Coesão Alta Discussão: Coesão alta, assim como Acoplamento Fraco, são princípios que devem ser considerados no projeto de objetos má coesão traz acoplamento ruim e vice-versa regra prática: classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas, e não executa muito trabalho analogia com mundo real ex: pessoas que assume muitas responsabilidades não associadas podem tornar-se (e normalmente tornam-se) ineficientes 73 36

37 Coesão Alta Benefícios mais clareza e facilidade de compreensão no projeto simplificação de manutenção e acréscimo de funcionalidade/melhorias favorecimento do acoplamento fraco aumento no potencial de reutilização classe altamente coesa pode ser usada para uma finalidade bastante específica 74 Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Bacharelado em Ciência da Computação Próximos Passos... 37

38 Tipos de Padrões 76 Factory Method Classificação: Criacional. Conhecido como: Virtual Constructor Propósito: Definir uma interface ou classe abstrata para a criação de um objeto, permitindo decidir qual das implementações ou subclasses devem ser instanciadas; deixa uma classe deferir instanciação para subclasses [Gamma et al, 1994]. Retornar uma instância dentre muitas possíveis classes, dependendo dos dados providos a ele [Destro, 2004]. (dependendo do parâmetro passado na sua invocação) 77 38

39 Factory Method Motivação: Útil para se construir objetos individuais, para um propósito específico, sem que a construção requeira conhecimento das classes específicas sendo instanciadas. Uma classe de abstração é criada, contendo um método em que decide qual das opções de classe retornar. Então, apenas este método é invocado, sem conhecer a classe que será retornada por ele [Destro, 2004]. Por isso, este padrão é chamado de Factory Method ( método-fábrica ): um método é responsável pela fabricação de um objeto [Gamma et al, 1994]. 78 Factory Method Aplicabilidade: Quando uma classe não pode antecipar ou conhecer a classe dos objetos que deve criar; Quando uma classe quer suas subclasses para especificar os objetos que cria; Quando classes delegam responsabilidade à alguma das várias subclasses ajudantes, e deseja-se localizar qual é a subclasse ajudante acessada. [Gamma et al, 1994] 79 39

40 Factory Method Estrutura: Onde: Super : é a classe abstrata (ou superclasse) dos objetos que o método-fábrica cria. Sub [n]: classes que vão herdar (ou implementar) a classe abstrata (ou interface) Super. Representam as diferentes classes sobre as quais se deve decidir instanciar. Factory : nesta classe reside o método-fábrica, que avalia o parâmetro passado na sua invocação, para retornar um determinado objeto do tipo Super. 80 Factory Method Conseqüências Vantagens: Dá maior flexibilidade para as classes. Factory Methods eliminam a necessidade de colocar classes específicas da aplicação no código: Sendo um exemplo de aplicação: 81 O código só lida com a interface Produto O código pode portanto funcionar com qualquer classe ProdutoConcreto 40

41 Factory Method Conseqüências Desvantagens: Em alguns casos, pode ser criada uma relação superclasse-subclasse para a criação de classes que suportam o método-fábrica, e de acordo com a classe a ser criada, uma das várias subclasses podem sobrescrever o método-fábrica, a fim de conectar hierarquias de classes paralelas e fornecer maior portabilidade [Gamma et al, 1994]. 82 Factory Method Implementação 1: Onde: Main: é a classe Java que inicializa a execução do aplicativo. O "método-fábrica" de CarroFactory é invocado (é um método estático, o que dispensa a instanciação da classe à qual pertence). A opção escolhida em CarroFactory é passada como parâmetro na invocação do "método-fábrica", o que lhe permite identificar qual subclasse de Carro deve ser instanciada (Gol, Golf, Vectra ou Ômega), contendo as informações a serem consultadas (por exemplo, preço)

42 Factory Method Usos Conhecidos Factory Methods são comumente usados em toolkits e frameworks 84 Factory Method Resumo Factory Method é apenas um apelido para um método que instancia objetos. Como uma fábrica, o trabalho do Factory Method é criar objetos. Factory Method é útil quando você não está certo de que implementação concreta da classe instanciar. Você pode deixar esses detalhes com o Factory Method

43 Contextualizando ISO 12207: Estrutura Processos Fundamentais Aquisição Processos de Apoio Documentação Fornecimento Garantia de Qualidade Desenvolvimento Operação Manutenção Verificação Validação Revisão Conjunta Auditoria Resolução de Problemas Adaptação Processos Organizacionais 86 Gerência Melhoria Infra-estrutura Treinamento 87 Abordagem Prática Separação em equipes Mesma equipe assume papéis distintos em atividades do desenvolvimento Exemplo: Equipes E1, E2, E3 e E4 Projetos P1 E1 gerencia as atividades, planejando as tarefas e controlando seus resultados. E2 é responsável por atividades de SQA. E3 é responsável pela Análise e Projeto. E E4 é responsável pela implementação. 43

44 88 Conteúdo: Parte 1: Gerenciamento & Qualidade Plano de Projeto - aspectos gerais Parte 2: Plano de Projeto - Métricas e Estimativas Parte 3: Plano de Projeto - Cronograma e Controle Parte 4: Exercícios de Fixação Atividade Definir os Grupos/Equipes 89 44

45 Distribuição de atividades Projetos Grupos Equipes Identificação P1 P2 P3 P Gerência SQA An&Prj Codifica Codifica Gerência SQA An&Prj 8 13 An&Prj Codifica Gerência SQA 4 14 SQA An&Prj Codifica Gerência Gerência SQA An&Prj Codifica Codifica Gerência SQA An&Prj An&Prj Codifica Gerência SQA 7 24 SQA An&Prj Codifica Gerência Gerência SQA An&Prj Codifica Codifica Gerência SQA An&Prj 6 33 An&Prj Codifica Gerência SQA 3 34 SQA An&Prj Codifica Gerência 90 45