Reutilização de software Nov/2005

Tópicos Reutilização: conceito Benefícios e dificuldades Desenvolvimento baseado em componentes Desenvolvimento com reutilização Desenvolvimento para reutilização Padrões de software 2

Referências E. Bezerra. Princípios de Análise e Projeto de Sistemas com UML. Editora Campus, 2a. Edição, 2007. DESCHAMPS, F. “Padrões de Projeto. Uma Introdução”. Notas de Aula. Departamento de Automação e Sistemas (DAS). Universidade Federal de Santa Catarina. GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. "Design Patterns: Elements of Reusable Object-Oriented Software". Reading, MA: Addison Wesley, 1995. JANDL, P. Jr. “Uma Introdução aos Padrões de Projeto com Java”. 2003. Obtido na Internet em ago/2005. PRESSMAN, R.S. “Sw Engineering: a Practitioner’s Approach”. McGraw- Hill, 4ª ed, 1997, c.26. SOMMERVILLE, I.. “Sw Engineering”, 6ª ed, 2001, cap14. 3

Reutilização Reutilizar, v.t.d. Reutilização, s.f. 1. Tornar a utilizar. 2. Dar novo uso a. Reutilização, s.f. 1. Ato ou efeito de reutilizar. 2. Procedimento em que, material que já for a anteriormente processado, após tratamento conveniente, se insere numa corrente ou processo [FERREIRA, Aurélio B. H. “Novo Dicionário da Língua Portuguesa”. Rio de Janeiro, RJ: Nova Fronteira, 2ª edição, 1986.] Também designada em alguns textos técnicos como reutilização

Reutilização em outras áreas da engenharia Atividade comum Engenheiros mecânicos ou elétricos dificilmente especificam um projeto no qual os componentes tenham que ser fabricados especialmente São reutilizados desde componentes pequenos (válvulas, trnasístores) até componentes mais complexos (motores, turbinas)

Reutilização em Engenharia de Software “Qualquer procedimento que produza (ou ajude a produzir) um sistema tornando a utilizar algo desenvolvido previamente” [Peter Freeman 1987, citado em Pressman95, cap.26]] Reutilização é algo praticado há muito tempo em Engenharia de Software, só que de maneira ad hoc Dada a pressão por produzir sw de boa qualidade em pouco tempo  necessidade de reutilizar de forma sistemática

Histórico 1960 Reutilização de linhas de código de um programa em outro Reutilização de código comum (subrotinas) Reutilização de funções genéricas (bibliotecas de funções) 1980 OO: herança, composição / delegação uso de interfaces (implementadas, em algumas linguagens, por classes abstratas Polimorfismo e ligação dinâmica (late binding): qqr implementação da interface pode ser usada em tempo de execução 1990 Padrões de software: reutilização de várias classes e de suas colaborações. reutilização não mais restrita ao código. Frameworks: reutilização de análise, projeto, implementação e testes de domínios de aplicações. Componentes: reutilização de código executável, configurável, adaptável. 2004(?) Serviço: reutilização de unidade autônoma de execução (função de negócio). ??? Fonte: Jacques Sauvé, UFCG. Ligação em tempo de compilação x late binding: este último permite que mais objetos possam cooperar uns com os outros, pois sabem menos a respeito uns dos outros. Serviço: inclui comportamento. É autônomo, ou seja, independe de outros serviços. Implementa uma função de negócio ou um grupo de funções de negócio. [Jacques Sauvé 2002: http://jacques.dsc.ufcg.edu.br/cursos/map/html/intro/intro.htm]

Reutilizar: sim ou não? Vantagens: Desenvolvimento acelerado pois custos com desenvolvimento e validação são reduzidos Conformidade com padrões Maior confiabilidade, pois utilizam-se soluções já experimentadas

Reutilizar: sim ou não? Dificuldades: Seleção, recuperação e modificação de artefatos reutilizáveis Compreensão dos artefatos recuperados Qualidade dos artefatos recuperados Composição de aplicações a partir dos artefatos recuperados Síndrome do “não foi inventado aqui” Falta de ferramentas de apoio pois atualmente os CASE não apoiam desenvolvimento com reutilização  será válido ainda hoje?

Reutilizar: sim ou não Um caso de fracasso Invasões mongóis no Japão (1274 – 1281) Samurais atacam barco da tropa mongol

Reutilizar: sim ou não Um caso de fracasso Invasões mongóis no Japão (1274 – 1281) Kublai Khan, neto de Genghis Khan, decide invadir o Japão após ter conquistado China e Coréia 1ª invasão:  800 barcos, 15 000 soldados mongóis e chineses, 8000 coreanos, conquistam duas ilhas mas ... Pesadas baixas Rebelião entre soldados coreanos e chineses fizeram-nos recuar até o litoral mas ... Tempestades destruíram uma boa parte dos barcos Fonte:http://wapedia.mobi/pt/Invasão_mongol_do_Japão, maio/2009

Reutilizar: sim ou não Um caso de fracasso Invasões mongóis no Japão (1274 – 1281) 2ª invasão (inicia-se em 1275 e termina em 1281): Nova tentativa, com mais contingente, mais navios (4000) Novamente o exército é obrigado a se retirar e retomar os navios, mas ... Um tufão, kamikaze (vento divino), destruiu 1/3 da frota mongol. Porquê? A frota se constitui de botes fluviais chineses e navios leves Em parte por sabotagem: engenheiros chineses introduziram falhas nos navios novos Em parte por falta de tempo: os botes fluviais não puderam ser adaptados para reutilização no oceano Os mongóis eram grandes cavaleiros, mas não marinheiros

Requisitos para reutilização Existência de uma biblioteca (ou repositório de componentes) ex.: component source, jars Garantia de que o componente se comportará conforme foi especificado e que serão confiáveis Existência de documentação que ajude a compreendê-los e adotá-los

Níveis de Abstração Reutilização pode ser considerada em todas as fases do desenvolvimento Pode-se reutilizar: Artefatos intermediários  padrões de software Sistemas de aplicação Componentes Funções

Desenvolvimento baseado em componentes (DBC) Final da década de 90: frustração com o reutilização de classes de OO Reutilização em OO é limitado pois: Classes não são unidades executáveis por si só, isto é, precisam ser compiladas ou conectadas a uma aplicação para serem utilizadas É difícl reutilizá-las sem ter o código fonte Têm granularidade muito baixa

Componente Entidade executável independente. O código fonte pode não estar disponível. Sua interface é pública e conhecida, e todas as interações são feitas por meio desta interface: Interface fornecida (provided): define os serviços formecidos pelo componente Interface requerida (required): especifica os serviços que devem estar disponíveis no contexto de uso do componente. Sua interface é descrita em termos de operações parametrizadas, ou seja, seu estado interno não é exposto. [Sommerville 2001, 14.1]

Notação Forma expandida Forma abreviada UML 1.4 UML 2.0 «interface» Interface_A tipo Operação_A1 (tipo args) tipo Operação_A2 (tipo args) UML 1.4 Componente Interface requerida Interface fornecida realiza Componente UML 2.0 Interface requerida Interface fornecida Componente depende de «interface» Interface_B tipo Operação_C1 (tipo args) tipo Operação_C2 (tipo args)

Exemplo ... ... ICancelaReserva IFazReserva ICobrança IGerencia Sistema de reserva de hotel ... ICobrança IGerencia

Exemplo ... ... usa ICancelaReserva IFazReserva ICobrança IGerencia «interface» IFazReserva getDetalhesHotel ( ) getInfoQuartos ( ) FazReserva ( ) Sistema de reserva de hotel ... ICobrança usa IGerencia «interface» IGerencia getDetalhesHotel ( ) getInfoQuartos ( )

Reutilização de componentes prontos A materialização de componentes prontos pode se dar de duas formas: Reutilização de componente já utilizado pela organização Geralmente os componentes associados ao domínio de negócio são os mais propícios a serem reutilizados Aquisição de componentes a partir de catálogos de terceiros Compra ou uso de sw livre (open source ou freeware) Componentes reutilizados nem sempre atendem exatamente aos requisitos: Necessidade de adaptar os requisitos Necessidade de adaptar a arquitetura para permitir a integração de componentes prontos

Reutilização de componentes prontos – um processo Identificar componentes candidatos Revisar as especificações Avaliar o impacto na arquitetura Avaliar arquitetura Negociar requisitos [aceito] Atualizar arquitetura [inspirado em CompGov]

Reutilização de componentes prontos – um processo Listar componentes candidatos Selecionar componente Validar componente Levar em conta: Requisitos funcionais - Atributos de qualidade - Restrições de projeto Identificar componentes candidatos Revisar as especificações Avaliar o impacto na arquitetura Avaliar arquitetura Negociar requisitos [aceito] Atualizar arquitetura [inspirado em CompGov]

Metodologias de DBC Existem várias, dentre as quais as mais conhecidas são: UML Components J. J.Cheesman e J.Daniels Catalysis (http://www.iconcomp.com/catalysis) D. D'Souza e A. A. Wills KobrA C.Atkinson et al.

Reutilizar componentes: sim ou não? Custos: Vantagens do reutilização em geral + Redução dos riscos do processo pois o uso de componentes prontos reduz as incertezas quanto aos custos de desenvolvimento de novos componentes Aumento nos custos de manutenção pois componentes de terceiro podem ser difíceis de entender e podem se tornar incompatíveis com mudanças do sistema Síndrome do “não foi criado aqui”: é mais desafiador desenvolver um componente original; acredita-se mais na qualidade do que é desenvolvido “em casa” Necessidade de manutenção de uma biblioteca de componentes Dificuldade em encontrar, compreender e adaptar componentes reutilizáveis

Frameworks de aplicações Framework: projeto de um subsistema (ou arquitetura de sw semi-definida) constituído de um conjunto de componentes individuais e das interconexões entre eles. Frameworks criam uma infra-estrutura pré-fabricada para o desenvolvimento de aplicações de um domínio específico. Uma aplicação pode ser construída a partir da integração de vários frameworks.

Conceitos básicos Hot spots Frozen spots Partes do framework que são projetados para serem genéricos Podem ser adaptados às necessidades da aplicação Frozen spots Definem a arquitetura geral da aplicação, seus componentes e os relacionamentos entre eles Permanecem fixos em todas as instanciações do framework

características específicas Frameworks OO A maioria dos frameworks são descritos em termos de OO. São constituídos de classes abstratas e concretas e das relações entre elas. Conforme o modo de estender um framework tem-se: Framework caixa branca: usuários desenvolvem implementações para as classes abstratas fornecidas, que funcionam como pontos adaptáveis, bem como o código específico para a aplicação. Framework caixa preta: contém todas as possíveis alternativas para todos os seus pontos adaptáveis. O usuário escolhe uma das alternativas disponíveis para criar sua aplicação. Permitem ao usuário adequar o framework às características específicas da aplicação No caso do fwk cx preta, o usuário não precisa conhecer a estrutura do fwk para criar sua aplicação. A dificuldade em construí-los está em que é difícil antecipar todas as diferentes formas de utilização de todos os seus pontos adaptáveis.

Frameworks  bibliotecas de classes Aplicação Framework Bibliotecas Aplicação O controle da execução está na aplicação que está sendo construída Inversão de controle: a aplicação que utiliza o framework pode ser invocada por ele

Linhas de Produto de Software Linhas de produto de software (LPS), ou família de aplicações: Consiste no desenvolvimento de um conjunto de produtos de software, com alto grau de similaridade entre si e que atendem às necessidades específicas de um segmento de mercado ou missão, de forma prescritiva, a partir de um conjunto de ativos centrais. [Clements & Northrop. Software Product Lines: Practices and Patterns. Addison Wesely, 2002] Atividades essenciais para implantação e manutenção de LPS: Desenvolvimento de ativos centrais: Ativos centrais: partes a serem reutilizadas entre os produtos da família Desenvolvimento de produtos: Construção de produtos utilizando os ativos centrais Gerência Atividades que gerenciam a implantação e manutenção de LPS

Identificação do usuário Exemplo de LPS Diagrama de características Caixa Eletrônico Características obrigatórias Identificação do usuário Emissão de extrato Ou exclusivo Ou inclusivo Característica opcional Toque na tela Leitura de cartão Tela Impressão Modelo de características: técnica muito utilizada para modelagem de aspectos comuns e variáveis entre os produtos de uma LPS. Faz parte do método de Análise de Domínio conhecido como FODA (Feature-Oriented Domain Analysis) Características modeladas podem ser: serviços (ex.: redirecionamento de chamadas), operações (ex.: enviar msg de texto), propriedades não funcionais (ex.: desempenho) e tecnologias (ex.: algoritmos de tratamento de erros na transmissão de rádio) Características podem ser hierarquicamente decompostas em um diagrama, como mostrado na figura. As características podem ser: - obrigatórias (devem estar presentes em qqr produto - opcionais: são selecionáveis - alternativas: não mais do que uma deve ser selecionada para um produto. Se há um ou inclusivo, significa que as duas podem ser selecionadas Características alternativas W.M.Assis 2009, Dissertação de Mestrado, IC-Unicamp]

Reutilização de serviços Existem várias definições para serviços. Aqui usamos a de Ribarov et al. (2007) Serviço: bloco de construção de SOA que realiza uma funcionalidade de negócio combina dados e comportamento encapsula lógica de negócio e dados deixa visível somente uma interface para o resto do sistema é autônomo com relação aos demais serviços do sistema  de componentes

Mais características de serviços Têm interfaces bem definidas, independentes da implementação São auto-contidos (autônomos) e fracamente acoplados Podem ser descobertos dinamicamente Podem ser compostos de outros serviços [Mahmoud 2005]

Serviço e processo Serviços (de negócio) são autônomos – como fazer com que cooperem? Processos (de negócio): Outro bloco de construção de desenvolvimento orientado a serviços Fazem a ligação e o seqüenciamento entre os serviços Representam a execução do negócio como um todo segundo um workflow e gestão de processos de negócio (BPM)

Demais conceitos Aplicação (frontend application) Materializa o processo de negócio Repositório de serviços (service registry) Registra informações sobre os serviços e sobre o que fazem Barramento de serviços (service bus) Faz a conexão entre os serviços Serve de mediador entre o consumidor e provedor do serviço, permitindo introduzir qualidade de serviço (QoS) ou transformação de dados [Ribarov et la. 2007]

Conceitos Aplicação Contrato Lógica do negócio S O Serviço A Implementação Dados Interface Repositório de Serviços Implementação do serviço é escondida. Barramento de Serviços [Krafzig et al.2005]

Paradigma find-bind-execute Repositório de Serviços Consumidor Provedor Cliente Serviço Busca (find) Publica barramento Conecta (bind-execute)

Acordo de nível de serviço SLA (Service Level Agreement) Contrato entre fornecedor e consumidor de um serviço, que visa garantir as características de qualidade do serviço oferecido O nível de qualidade do serviço (QoS) pode variar de acordo com o quanto o consumidor quer pagar QoS, especificada em termos mensuráveis, serve para medir e monitorar o desempenho do fornecedor Não cumprimento do SLA  multa para o fornecedor

Contrato de SLA Pode conter especificações sobre: Disponibilidade Ex.: o serviço deve estar disponível 99,9% do tempo ao longo do ano, ou seja, pode parar no máximo 8,7 horas em um ano Confiabilidade Ex.: durante 1 ano o serviço não deve registrar mais de 1 defeito a cada 1 milhão de operações realizadas Desempenho Ex.: o serviço deve ser realizado em até 2 segundos Prioridade e desempenho Ex.: solicitações indicadas como “urgentes” devem ser realizadas em até 8h, as marcadas como “importantes”, em até 24h e as “rotineiras”, em até 72h

Modelos de serviços Jini Serviços de grades (GS) Serviços Web (WS) Proposta da Sun de 1990 Serviços são descobertos e usados dinamicamente (em rede) Serviços de grades (GS) Serviços Web (WS) Noção de serviços de Jini + Web + diversos padrões [Mahmoud 2005; Sommerv.2007, c.12.4]

Padrões Padrão, s.m.[do latim patronu, protetor] 1. Modelo oficial de pesos e medidas. 2. Aquilo que serve de base ou norma para a avaliação de qualidade ou quantidade. 3. Qualquer objeto que serve de modelo à feitura de outro. ... [FERREIRA, Aurélio B. H. “Novo Dicionário da Língua Portuguesa”. Rio de Janeiro, RJ: Nova Fronteira, 2ª edição, 1986.]

Padrões de software Porquê Aumentar a possibilidade de reutilização de boas soluções para problemas freqüentes, garantindo, com isso, melhor qualidade para o software Especialistas têm tendência a reutilizar soluções para problemas surgidos em trabalho anterior Os padrões surgem com a experiência prática Experiência de especialistas pode ser compartilhada com novatos

Uma definição “Um padrão descreve um problema que ocorre repetidamente no nosso ambiente, descrevendo a essência de uma solução para este problema, de forma que pode-se usar esta solução milhares de vezes, sem faê-lo da mesma forma duas vezes.” [ALEXANDER, Christopher, 1977 --> propôs padrões a serem usados em Arquitetura, de onde surgiu a idéia de utilizar do mesmo recurso em software] [ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING, I., ANGEL, S. "A Pattern Language". New York, NY (USA): Oxford University Press, 1977].

Outra definição “Um padrão de software nomeia, motiva e explica uma solução genérica a um problema recorrente que surge em uma situção específica. Ele descreve o problema, a solução, quando é aplicável e quais as conseqüências de seu uso.” [Gamma et al]

Características [Jandl 2003] Descrevem e justificam soluções para problemas concretos e bem definidos. Documentam a experiência existente e comprovada. Fornecem um vocabulário comum aos desenvolvedores de software. Descrevem relações entre conceitos, estruturas e mecanismos existentes nos sistemas. Podem ser utilizados em conjunto com outros padrões.

Uso de padrões Padrões podem ser utilizados nas diversas etapas de desenvolvimento de software: Análise (M.Fowler 1997) Arquitetura, Projeto e Codificação (Gamma e al; Buschmann 1996.) Testes (R.Binder 1999) Manutenção (Barry 2003; Hammouda 2004) Reengenharia (Demeyer 2003) ...

Categorias de padrões Padrões de análise Padrões de arquitetura Fazem parte da Especificação de Requisitos ou da Modelagem Conceitual Definem conjunto de objetos do mundo real, seus relacionamentos e as regras que definem seu comportamento São dependentes da aplicação pois descrevem aspectos específicos do domínio do problema Padrões de arquitetura Representam esquemas para estruturar o software. Definem conjunto de subsistemas pré-definidos, especificam suas responsabilidade e as regras para organizar os relacionamentos entre eles.

Categorias de padrões Padrões de projeto Idiomas Permitem refinar os subsistemas da arquitetura, ou os relacionamentos entre eles Focam em aspectos típicos de projeto, tias como: interface-usuário, criação de objetos, entre outros São os mais comuns na literatura Idiomas São padrões de baixo nível, específicos para linguagens de programação Descrevem como implementar aspectos dos subsistemas ou dos relacionamentos entre eles, usando características de uma determinada linguagem de programação

Categorias de padrões Padrões de manutenção Regras e restrições que devem ser satisfeitas por entidades de um programa (classes, métodos e atributos) para facilitar a manutenção, mais especificamente, a documentação (HAMMOUDA 2004)

Elementos de um padrão Nome Conseqüências Problema: Exemplos: Solução Existem diversas formas de descrever um padrão. Para os padrões de projeto a forma mais comum é aquela descrita no livro de Gamma et al, denominado Gang of Four (GoF): Nome Deve ser curo e intuitivo (mnemônico) Problema: Descreve em que situação o padrão pode ser aplicado Solução Descreve os elementos envolvidos, suas responsabilidades e colaborações Conseqüências Custos e benefícios da aplicação do padrão Exemplos: Exemplos de aplicação

Exemplo: um padrão de Análise Padrão Party: Representa componentes de uma organização e os relacionamentos entre eles Conceitos usados: Party: pessoa ou organização de interesse para a aplicação Relação de subordinação: entre pessoas, entre pessoas e organizações

LocalizaçãoParty dataInício: Date dataTérmino: Date Party nome: String * Party nome: String Party endereço: String * * * subordinado a * * Pessoa Organização Cargo empregado empregador 1 1..* 1 * Emprego dataInício: Date dataTérmino: Date tipo NomeaçãoCargo - dataInício: Date - dataTérmino: Date nomeações 1 1..* [Bezerra 2007]

Como selecionar um padrão Considere como os padrões de projeto solucionam os seus problemas de projeto. Examine as seções de descrição do problema de cada padrão. Estude como os padrões se interrelacionam. Estude padrões de finalidades semelhantes. Examine uma causa de reformulação de projeto. Considere o que deveria ser variável no seu projeto. [Deschamps2005]

Como usar um padrão Leia o padrão por inteiro, uma vez, para obter uma visão geral. Estude as seções de descrição do problema e do padrão. Olhe exemplos de código do padrão. Escolha nomes para os participantes do padrão que tenham sentido no contexto da sua aplicação. Defina as classes. Defina nomes específicos da aplicação para as operações no padrão. Implemente as operações para apoiar as responsabilidades e colaborações presentes. [Deschamps2005]

Padrões de software: utilizar ou não? Para melhorar a estrutura de algo já implementado, quando o domínio do problema está bem compreendido Podem melhorar a compreensão do código melhorando a modularidade, separação de conceitos e simplicidade de descrição ex.: é mais fácil dizer: “utiliza-se uma instância do padrão Visitor do que "este é um código que varre a estrutura e realiza chamadas a alguns métodos em uma ordem particular e de uma determinada forma". Utilize padrões somente para resolver problemas já identificados no projeto/código pois ... ... podem diminuir a capacidade de compreensão ao introduzir acesso indireto e aumentar a quantidade de código

Onde obter mais informações Catálogo sobre padrões http://www.dofactory.com/Patterns/Patterns.aspx#list Tutorial sobre padrões: www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/objectives. html http:// Padrões de projeto, Idiomas e Frameworks ttp://www.cs.wustl.edu/~schmidt/patterns.html http:// Apresentação geral sobre padrões http://www.mindspring.com/~mgrand/pattern_synopses.htm

Sumário dos principais pontos aprendidos

Exemplo – padrão de teste de regressão Critérios de entrada: Delta já foram testados Conjunto de testes previamente aplicados já existe Matriz associando casos de uso aos casos de teste foi criada O ambiente de testes já foi configurado igual aos dos testes prévios Critérios de saída Todos os testes selecionados foram aplicados e os bugs devidamente registrados Conseqüências Risco moderado de não revelar uma falha de regressão Baixo custo de análise para seleção de casos de teste ... Nome: Teste de caso de uso de maior risco Problema Útil quando não se dispõe de tempo, recursos ou pessoal suficiente para reaplicar todos os testes Solução Usar critérios de risco para avaliar os casos de uso a serem testados Aplicar os critérios para obter o subconjunto de testes a ser reaplicado Usar como oráculo os resultados do conjunto de testes aplicado anteriormente [Binder 2000, c.15]