Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira www.cesar.org.br, silvio@cesar.org.br Eduardo Santana de Almeida.

Apresentação em tema: "Porque Componentização e Reuso não funcionaram... pelo menos até agora! Silvio Lemos Meira www.cesar.org.br, silvio@cesar.org.br Eduardo Santana de Almeida."— Transcrição da apresentação:

1 Porque Componentização e Reuso não funcionaram... pelo menos até agora!
Silvio Lemos Meira Eduardo Santana de Almeida

2 como aumentar a produtividade no desenvolvimento de software?
trabalhe mais rápido automação, ambientes, ferramentas substitua trabalho humano trabalhe mais inteligentemente melhore o(s) processo(s) evite/reduza tarefas de pouco valor EVITE O TRABALHO! REUSE ARTEFATOS do CICLO DE VIDA evite/reduza o desenvolvimento de artefatos específicos para cada projeto…

3 resultados: boehm {dod, 1999}
working-faster savings: 8% working-smarter savings: 17% work-avoidance savings: 47%

4 Agenda Reuso de Software Desenvolvimento Baseado em Componentes
Reuso Sistemático de Software Casos de Sucesso e Falhas Mitos Inibidores

5 Reuso de Software “Software reuse is the use of existing software knowledge or artifacts to build new software artifacts” [Frakes, 1995] Vantagens (em POTENCIAL) MAIS Qualidade MENOS Tempo de desenvolvimento MENORES custos TOTAIS no ciclo de vida... implementação, testes... integração, documentação, manutenção... evolução...

6 Artefatos reusáveis [D’Souza, 1999]
Código compilado [fonte] Casos de testes Modelos e projetos: frameworks e padrões Interface de usuário Planos, estratégias e regras arquiteturais ...

7 Desenvolvimento Baseado em Componentes (DBC)

8 Desenvolvimento Baseado em Componentes (DBC)
Visão clássica de desenvolvimento SW = “Blocos” monolíticos Grande número de partes inter-relacionadas num mundo “integral” ...um cenário em que DBC “quebra” tais blocos {simplificar!}… para reduzir complexidade e custo de desenvolvimento… num mundo distribuído… Até bem pouco tempo atrás, o desenvolvimento da maioria dos produtos de software, disponíveis no mercado, era baseado em uma abordagem de desenvolvimento de blocos monolíticos, formados por um grande número de partes inter-relacionadas, onde estes relacionamentos estavam, na maioria das vezes, implícitos. O DBC surgiu como uma nova perspectiva para o desenvolvimento de software, cujo objetivo é a “quebra” destes blocos monolíticos em componentes interoperáveis, reduzindo, desta forma, a complexidade do desenvolvimento, assim como os custos, através da utilização de componentes que, em princípio, seriam adequados para serem utilizados em outras aplicações [Sametinger, 1997]. Este objetivo não é novo no desenvolvimento de software. Em [Werner, 2000], são listados alguns trabalhos que, desde então, vislumbravam uma indústria de componentes de software reutilizáveis. A diferença é que estas abordagens se baseavam, essencialmente, em código. Entretanto, constata-se que o DBC, para ser efetivo, envolve muito mais do que isto. Apenas recentemente, o DBC está sendo considerado como uma técnica importante no desenvolvimento de software. Um conjunto de fatores despertou este novo interesse na área, provendo a motivação necessária para se acreditar que o DBC possa ser agora mais efetivo e realizado em larga escala. Dentre estes fatores, podemos citar [Sametinger, 1997], [D’Souza, 1999]: ·        Desenvolvimento da Internet, que aumentou a preocupação em relação à computação distribuída; ·        A mudança da estrutura de sistemas baseados em mainframes para sistemas baseados na arquitetura cliente e servidor, levando os desenvolvedores a considerarem as aplicações não mais como sistemas monolíticos, mas sim como um conjunto de sub-sistemas interoperáveis; e ·        Uso de Padrões para construção de aplicações, como o Object Management Group (OMG) e Component Object Model (COM).

9 Componentes de Software
Definições Diversas/Divergentes Bertrand Meyer [1999]: “a software element that must be usable by developers who are not personally known to the component’s author to build a project that was not foreseen by the component’s author.” Visões de um componente Elemento arquitetural Elemento implementacional Componente de negócio O conceito exato de componente em DBC ainda não é um tópico fechado. Cada grupo de pesquisa caracteriza, da maneira mais adequada ao seu contexto, o que seria um componente e, assim, não há ainda, na literatura, uma definição comum e precisa para este termo. Desde o primeiro workshop de DBC em 1998, Kyoto [Brown, 1998], até o mais recente, na Flórida, Estados Unidos [CBSE, 2002], passando por outras conferências mais específicas [ICSR, 2002], [WCOP, 2002], diversas definições têm sido apresentadas. Em [Heineman, 2001], um grupo formado por especialistas na área de engenharia de software baseada em componentes relata que ao fim de dezoito meses chegou-se a um consenso sobre o que seria um componente de software. Segundo esses especialistas, um componente de software é um elemento de software em conformidade com um modelo de componentes e que pode ser independentemente implantado e composto sem modificações, conforme um padrão de composição. Em [Brown, 1998], são apresentadas diversas definições do que vem a ser um componente. Algumas dessas visões são: ·        “Um componente como um elemento arquitetural. Este componente deve prover e estar em conformidade com um conjunto de interfaces”; ·        “Um componente como um elemento implementacional acessado através de interfaces bem documentadas, que podem ser descobertas em tempo de execução”; ·        “Um componente como um elemento implementacional, mas que faz parte de um contexto arquitetural específico”; ·        “Um componente de negócio representa a implementação de um conceito autônomo de negócio ou processo. Consiste dos artefatos de software necessários para expressar, implementar e executar o conceito como um elemento reutilizável de um grande sistema de negócio”.

10 Componentes de Software
Aspectos de um componente Descrever ou realizar uma função específica Estar em conformidade e prover um conjunto de interfaces definidas Ter uma documentação adequada Estar inserido no contexto de um modelo que oriente a composição deste componente com outros Categorias [Williams, 2001] Componentes GUI Componentes de Serviços Componentes do Domínio [Negócio] Cada uma dessas visões ressalta um determinado aspecto de um componente. Atualmente, pode-se notar que já existem definições mais precisas e convergentes. Em [Werner, 2000], são listados alguns aspectos que um componente de software deve realizar. Dentre estes aspectos, constatou-se que um componente deve: ·        descrever ou realizar uma função específica [Sametinger, 1997], [D’Souza, 1999]; ·        estar em conformidade e prover um conjunto de interfaces bem definidas [Sametinger, 1997], [Szyperski, 1998]; ·        ter disponível uma documentação adequada [Sametinger, 1997]; ·        estar inserido no contexto de um modelo que oriente a composição deste componente com outros (arquitetura de software); ·        ser autocontido em termos da funcionalidade que provê. Outro ponto importante é que, no início, a visão de um componente como um elemento, somente como código, era bastante comum e, atualmente, esta visão está mudando e os engenheiros de software começam a visualizar componentes em todos os níveis de abstração [D’Souza, 1999], [Heineman, 2001]. Segundo Williams [2001], os componentes podem ser divididos em três categorias: ·        Componentes GUI: são os mais conhecidos tipos de componentes encontrados no mercado. Nessa categoria enquadram-se todos os botões, menus e outros widgets utilizados na criação de interfaces para aplicações. ·        Componentes de Serviços: provêem acessos para serviços comuns necessários em muitas aplicações. Isso inclui acesso a banco de dados, acesso a serviços de mensagens e transações e serviços de integração. Uma característica comum dos componentes de serviços é que estes utilizam uma estrutura adicional ou sistemas para realizar suas funções. Por exemplo, pode-se empacotar um sistema existente a fim de criar um componente de serviço e este realize funções para outras aplicações [Mehta, 2002]. ·        Componentes do Domínio: também chamados de componentes de negócio, são os componentes mais difíceis de se projetar e construir. Esses componentes necessitam de um alto conhecimento do domínio para sua construção, a fim de permitirem uma maior reutilização no desenvolvimento das aplicações.

11 Componentes de Software
“Componentes reutilizáveis são artefatos autocontidos, claramente identificáveis, que descrevem ou realizam uma função específica e têm interfaces claras em conformidade com um dado modelo de arquitetura de software, documentação apropriada e um grau de reutilização definido.” Sametinger, 1997 Considerando todos os aspectos aqui mencionados, a definição de Sametinger [1997] apresenta-se suficientemente satisfatória, a fim de estabelecer o que vem a ser um componente de software.

12 a idéia NÃO é nova... Mass Produced Software Components, Doug McIlroy
NATO Software Engineering Conf., Garmisch, Germany, 1968

13 Mass Produced Software Components, ‘68
McIlroy e a indústria de componentes: ...to see standard catalogues of routines, classified by precision, robustness, time-space performance, size limits, and binding time of parameters ...to apply routines in the catalogues to any one of a larger class of often quite different machines; to have confidence in the quality of the routines ...[I want] different types of routine in the catalogue that are similar in purpose to be engineered uniformly, so that two similar routines should be available with similar options and two options of the same routine should be interchangeable in situations indifferent to that option

14 Systematic Software Reuse
De McIlroy até agora... pesquisa/desenvolvimento/evolução de Domain Engineering Component-Based Development Repository Systems Product Lines ... cujo principal objetivo é atingir... Systematic Software Reuse

15 Systematic Software Reuse
“Systematic Software Reuse is domain focused, based on a repeatable process, and concerned primarily with the reuse of higher level lifecycle artifacts, such as requirements, design, and subsystems” William B. Frakes, 1994

16 O caso da Hewlett-Packard Griss [94, 95]
Objetivos, 1980 Reduzir time to market Melhorar a produtividade dos desenvolvedores Melhorar a qualidade do produto 1990: Corporate Reuse Program entender reuso de SW dentro da HP e de outras empresas Metas Empacotar o conhecimento adquirido Desenvolver guidelines Maiores informações podem ser encontradas em: Papers: Software Reuse Experience at Hewlett-Packard Making Software Reuse Work at Hewlett-Packard

17 Corporate Reuse Program
Constatações fundamentais Gerenciamento é um fator crítico Fatores não técnicos são extremamente importantes {Administração de Projetos de SW é normalmente considerada uma POST-NORMAL SCIENCE!...}

18 Corporate Reuse Program
Mitos quebrados: “First step: To build a repository” “Produce that product, and on the way, produce components too” “Reuse requires using object technology” “Reusable components are always slow, because its generalization” “The need for such optimization makes reuse not worth the development effort” “You should not even considerer systematic reuse until your organization is at level 3 in the Software Engineering Institute's Capability Maturity Model”

19 Modelo Incremental para adoção de Reuso
Reuse enabled business Benefit High reuse levels Systematic Domain- specific reuse Broader coverage Architecture reuse Reduced maintenance costs Managed workproducts Reduced Development time Black box code reuse Code leverage None Investment, experience

20 O caso da Motorola Software Reuse at Motorola [Rebecca Joos, IEEE SW 94]
Transição inicial: Mudança hardware – software... ...implicava em transformar engenharia de software numa prioridade para o negócio fases do plano de reuso: Grass-roots {na engenharia} Senior-Management Involvement future markets and Tools Maiores informações podem ser encontradas em: Paper: Software Reuse at Motorola

21 Primeira fase Criação da força tarefa para reuso Principais atividades
Formada por líderes de cada setor da empresa para... investigar e fazer recomendações sobre reuso na Motorola Principais atividades Educar e disseminar conhecimento sobre reuso Definir métricas, prêmios, job descriptions Duas abordagens de reuso Reengenharia de análise, projeto e implementação para popular o repositório “forward engineering”

22 Segunda e Terceira fases
Senior-Management Involvement Relutância dos gerentes altos custos iniciais e baixo retorno de investimento (3+ anos) CEO manteve a iniciativa Mais uma vez, o problema foi mais cultural do que tecnológico Terceira fase ferramentas de automação

23 Problemas era preciso educar/treinar mais... descompasso
conhecimento vs. velocidade educação para reuso gerentes!... difícil, toma muito tempo... gente! voluntários demais... conceitos e capacidades desiguais era preciso educar/treinar mais...

24 Systematic Reuse – Fatores de Sucesso [Frakes, 1994]
Management Measurement Legal issues Economics “Componentes devem ser reusados mais de 13 vezes para recuperar o investimento...” [Favaro, 1991] Design for reuse Libraries Maiores informações podem ser encontradas em: Paper: Success Factors of Systematic Reuse To appear (before 21/08)

25 Reuso de Software: Casos de Sucesso e de Falhas...

26 Os Problemas [Rine, 1997] Não existe um conjunto de fatores de sucesso comuns entre empresas reuso É vantagem competitiva... pouco incentivo para compartilhar lições carência de DADOS Estudos recentes: Rine [1997] Morisio [2002]

27 Rine [1997] – Success Factors for Software Reuse that are applicable across domains and businesses
Survey conduzido em 1995 Determinar os fatores de sucesso para reuso de software em domínios de aplicação Fatores de sucesso Abordagens de linha de produto, Arquiteturas com interfaces padrão Engenharia de domínio, Gerenciamento Métodos, ferramentas Reutilização de artefatos do ciclo de vida Traceability Maiores informações podem ser encontradas em: Paper: Success Factors for Software Reuse that are applicable across Domains and Businesses

28 Morisio [2002] – Success and Failures Factors in Software Reuse
Conduzido durante Estudo empírico sobre empresas européias em processo de evolução 24 projetos analisados ao longo do período Fatores de sucesso Introdução de processos de reuso Modificação de processos visando o reuso Gerenciamento Fatores humanos Software staff e Overall staff Maturidade do processo

29 Morisio [2002] – Success and Failures Factors in Software Reuse
FALHAS...

30 Porque muitos programas de reuso falham?
[Griss, 1994]: Tratamento de reuso como um problema de aquisição tecnológica estratégias de reuso nos negócios são ruins programas de reuso não são orientados ao mercado Glass [1999]: Existem poucos componentes que podem ser reusados {?...}

31 Morisio [2002] – Success and Failures Factors in Software Reuse
cerca de 1/3 dos projetos falhou principais motivos: Não introduzir processos específicos de reuso Não modificar processos existentes que não consideravam reuso Não considerar fatores humanos como parte do processo

32 Reuso de Software: os Mitos

33 Frakes [1995] – Sixteen Questions about Software Reuse
Pesquisa realizada em 1991/2 113 engenheiros de software, gerentes, pesquisadores 28 empresas EUA, 1 EU

34 CASE tools promoted reuse across projects in our organization
40 Respostas 79 Média 1.8 Mediana 1 Desvio Padrão 1.0 19 13 6 Esta questão merece uma posterior investigação. Aparentemente, três questões devem ser analisadas: 1 – A qualidade das ferramentas 2 – O emprego correto das ferramentas 3 – Ferramentas especificas de reuso não estão sendo utilizadas 1 75% of respondents do not agree even somewhat that CASE tools have promoted reuse

35 It’s more fun to write my own software than to try to reuse
Respostas 104 Média 2.0 Mediana 2 Desvio Padrão 1.2 44 31 19 7 3 72% of respondents do not have The Not Invented Here (NIH) syndrome

36 EDUCAÇÃO e EXPERIÊNCIA...
Does reuse education influence reuse? Comparando a educação em reuso, entre indivíduos… os mais “informados” obtém maiores níveis de reuso de código e projeto Does software engineering experience influence reuse? Não foi identificada nenhuma correlação direta entre experiência e nível de reuso

37 Do recognition rewards increase reuse?
Algumas empresas pagam por assets colocados e recuperados do repositório mas… Não foi identificada nenhuma correlação direta entre gratificações e nível de reuso

38 A common software development process has promoted reuse across projects in our organization
38 Respostas 94 Média 2.3 Mediana 2 Desvio Padrão 1.3 21 17 9 9

39 Organizational reuse level
A common software development process has promoted reuse across projects in our organiz... Organizational reuse level Correlation between reuse levels and agreement that a common software process promotes reuse across projects Requirements 0.24 Design 0.40 Code Test plans 0.31 Test cases 0.34 User documentation 0.15 Um processo de desenvolvimento comum promove o reuso sobre projetos. Assim, ganhos em processos de maturidade PODE refletir-se em ganhos de reuso

40 Legal problems inhibit reuse
Respostas 92 Média 2.0 Mediana 2 Desvio Padrão 1.2 45 20 18 5 4 Uma vez que questões legais sobre regras de reuso entre fornecedores e compradores não estão definidas, surgiu a idéia de investigar se essa carência poderia inibir a reutilização dos desenvolvedores. Para 68%, os problemas legais são irrelevantes

41 Does having a reuse repository improve code reuse?
analisando empresas com e sem repositórios chegou-se à conclusão que… ter um repositório não garante uma melhoria no nível de reuso

42 Reuso de Software – Inibidores

43 Porque ainda não decolou.....
Pesquisa conduzida pelo Software Engineering Institute (SEI) durante [SEI, 2000] Economistas, analistas industriais, gerentes e engenheiros de software Análise de componentes de software Visão técnica e de negócio

44 os inibidores são... Carência de componentes disponíveis
para 30%... falta uma indústria para 20%... faltam comps em domínios Carência de padrões para tecnologia de componentes 30% lembraram a instabilidade dos padrões de componentes Carência de componentes certificados Carência de métodos para CBSE

45 mesmo assim…

46

47 no cesar… ainda em fase inicial
reuso EXTERNO a projetos em SLOC melhor caso: 69% pior caso: 2% média {MLOC…}: 17% {J2EE 12%} ganho de produtividade MÉDIO componentes WEB: 30% {0 – 50%} REUSO de PROCESSO: 80 – 100% METAs de REUSO/PRODUTIVIDADE SLOC: ? {não importa…} Esforço: 75% {melhor da NASA, MOT}

48 Referências Bibliográficas
[Brown, 1998] Brown, A., Wallnau, K. The Current State of CBSE, IEEE Software, Oct , 1998. [CBSE, 2002] 5th ICSE Workshop on Component-Based Software Engineering, Benchmarks for Predictable Assembly, In conjunction with the 24th International Conference on Software Engineering, (ICSE), May, 2002. [D’Souza, 1999] D’Souza, D., F., Wills, C., A. Objects, Components, and Frameworks with UML – The Catalysis Approach. Addison-Wesley, 1999. [Favaro, 1991] Favaro, J. What Price Reusability? A Case Study, ADA Letters, Mar, 1991. [Frakes, 1994] Frakes, W., B., Isoda, S. Success Factors of Systematic Software Reuse. IEEE Software, Sep, 1994. [Frakes, 1995] Frakes, W., B., Fox, C., J. Sixteen Questions about Software Reuse. Communications of the ACM, June, 1995. [Glass, 1999] Glass, R. Reuse: What’s wrong with this picture?, IEEE Software, Mar, 1998.

49 Referências Bibliográficas
[Griss, 1994] Griss, M. Software Reuse Experience at Hewlett-Packard, 16th International Conference on Software Engineering, (ICSE), May, 1994. [Griss, 1995] Griss, M., Wosser, M. Making Reuse Work at Hewlett-Packard, IEEE Software, 1995. [Heineman, 2001] Heineman, G., T., Council, W., T. Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley [ICSR, 2002] 7th International Conference on Software Reuse (ICSR), Austin, Texas, USA. April 2002. [Joos, 1994] Joos, R. Software Reuse at Motorola, IEEE Software, Sep, 1994. [Lamers, 1986] Lamers, S. Programmers at Work, Microsoft Press, 1986.

50 Referências Bibliográficas
[Mehta, 2002] Mehta, A., Heineman, G., T. Evolving Legacy System Features into Fine-Grained Components, In 24th International Conference on Software Engineering (ICSE). ACM Press, 2002. [Morisio, 2002] Morisio, M., Ezran, Tully, C. Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, Apr, 2002. [Rine, 1997] Rine, D, C. Success Factors for Software Reuse that are applicable across Domains and Businesses, ACM symposium on Applied Computing, Mar, 1997. [Sametinger, 1997] Sametinger, J. Software Engineering with Reusable Components. Springer-Verlag, 1997. [SEI, 2000] Software Engineering Institute. Market Assessment of Component-Based Software Engineering, Technical Report, May, 2000. [Visser, 1987] Visser, W. Strategies in Programming Programmable Controllers: A field study of Programmers, Workshop, 1987. [WCOP, 2002] 7th International Workshop on Component-Oriented Programming (WCOP) in conjunction with the 16th European Conference on Object-Oriented Programming (ECOOP), Málaga, Spain, 2002.

51 Referências Bibliográficas
[Werner, 2000] Werner, C.; Braga, R. Desenvolvimento Baseado em Componentes, In XVI Simpósio Brasileiro de Engenharia de Software, Minicursos, João Pessoa, Paraíba, 2000. [Williams, 2001] Williams, J. The Business Case for Components, In Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.

52 Contato … esa2@cin.ufpe.br
Obrigado Contato …

53