IFPA

Tecnologia em Análise e Desenvolvimento de Sistemas (TADS)

Práticas de Engenharia de
Software

Reutilização de software
- Introdução
PROFESSOR: Claudio Roberto de Lima Martins
claudiomartins2000@gmail.com
Tópicos

▶ Reutilização: conceito
▶ Benefícios e dificuldades
▶ Desenvolvimento baseado em componentes
 Desenvolvimento com reutilização
 Desenvolvimento para reutilização

2
2
Reutilização (definição nos dicionários)
▶ Reutilizar, v.t.d.
 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” e “reuso”

3
Reutilização de software

▶ Abordagem de desenvolvimento com o objetivo de

maximizar o uso de software pré-existente.
▶ Nos últimos 20 anos, muitas técnicas foram
desenvolvidas para apoiar o reuso:
Bibliotecas, objetos, componentes, etc.

▶ O movimento open source alavancou a base de

código disponível
▶ A necessidade de produzir software em escala, a
partir das experiências de “fábricas de software”
motivou estudos em melhorias de reuso de
software.
4
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, transístores) até
componentes mais complexos
(motores, turbinas)

5
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” (improvisada ou não sistematizada).
▶ Dada a pressão por produzir sw de boa qualidade
em pouco tempo → necessidade de reutilizar de
forma sistemática

6
 Histórico

1960 Reutilização de linhas de código de um programa em outro

1970 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).
???
[Jacques Sauvé 2002: http://jacques.dsc.ufcg.edu.br/cursos/map/html/intro/intro.htm]

7
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

8
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?

9
Requisitos para reutilização

▶ Existência de uma biblioteca (ou repositório de

componentes)
 Ex.: component source, jars, maven repository, archiva…

▶ 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

10
Níveis e escalas de Abstração
▶ Reutilização pode ser considerada em todas as fases
do desenvolvimento e em nível (escala) de tamanho
do que ser reutilizar.
▶ Pode-se reutilizar:
 Artefatos intermediários → padrões de software
 Reúso de modelos (templates), ideias e padrões (patterns).
 Sistemas
Um sistema pode ser reusado por incorporação à outro sistema.
Pode ser necessário customização
 Componentes
Reuso de média granularidade. Exemplo: componente arquitetural
ou subsistema.
 Funções/Objetos (código)
 Tipo mais comum de reutilização.
11
Planejamento para Reutilização

▶ Reutilização não ocorre por acaso

Ele deve ser planejado e incentivado em toda a
organização

▶ Muitas empresas desenvolvem sistemas em um

mesmo domínio.
 Domínio: é uma coleção de problemas reais; uma
coleção de aplicações que compartilham características
comuns.
 Surgem situações potenciais para reutilização
Ex: Software para jogos, Sistema financeiro, Seguros,
Saúde (gestão de hospitais e clínicas), etc.
12
Processo de Reutilização de Software

13
Processo: Planejamento

▶ Atividades do planejamento do reuso

 Coordenar o processo de reuso;
 Definir prioridades e cronogramas para os artefatos a
serem construídos;
 Resolver conflitos quando artefatos necessários não
estão mais disponíveis;
 Integrar o reuso no processo de desenvolvimento.

14
Fatores do Planejamento

▶ Alguns fatores a considerar no planejamento de

reutilização:
Cronograma de desenvolvimento
Ciclo de vida do software
Conhecimento e experiência da equipe
Domínio da aplicação

15
Cronograma e Ciclo de Vida

▶ Cronograma de Desenvolvimento
 Se o cronograma de entrega é apertado, reutilzar pode
agilizar a entrega do produto

▶ Ciclo de Vida do Software

 Reusar pode ser um problema em sistemas que sofrem
manutenções frequentes
 Componentes de terceiros (código proprietário) dificultam
a manutenção

16
Equipe e Domínio

▶ Conhecimento e experiência da equipe na

abordagem de reutilização
 Muitas abordagens são difíceis de serem usadas e
requerem experiência

▶ Domínio da aplicação
 Em alguns domínios, é fácil encontrar componentes e
bibliotecas para reusar

 Em outros domínios, é mais complicado

17
Processo: Criação dos Artefatos

▶ Atividades da Criação dos Artefatos

 Pesquisar os artefatos;
 Avaliação das necessidades do utilizador;
 Tecnologias e novidades do mercado;
 Engenharia de Domínio.

18
Engenharia de Domínio

▶ Domínio:
 Uma coleção de problemas reais
 Uma coleção de aplicações que compartilham
características comuns
▶ Identificar, construir, catalogar e disseminar um
conjunto de artefatos que podem ser utilizados em
softwares de um domínio específico.
▶ Com a Engenharia de Domínio é possível definir
modelos de domínios e arquiteturas comuns à uma
família de aplicações.
▶ Formalizar teorias específicas a um domínio
19
Processo: Gerência dos Artefatos

▶ Atividades da Gerência dos Artefatos

 Certificar novos artefatos;
 Classificar novos artefatos no repositório;
 Suporte ao processo de utilização;
 Checar as necessidades do processo de utilização com
os artefatos existentes;
 Coletar feedback e reportar erros.

20
Utilização dos Artefatos

▶ Atividades da Utilização dos Artefatos

 Análise dos requisitos do produto a ser construído;
 Especificação do produto a ser construído;
 Identificar os artefatos a serem reutilizados;
 Compreensão dos artefatos;
 Avaliação dos artefatos;
 Adaptação dos artefatos;
 Integração dos artefatos.

21
Panorama da reutilização de software

22
Técnicas (1)
▶ Padrões de projeto e de arquitetura
 Padrões (patterns) são soluções genéricas para problemas
recorrentes
▶ Frameworks de aplicação
 Coleção de classes abstratas e concretas que criam a
estrutura de uma aplicação
▶ Componentes
 Subsistemas que são integrados para criação da aplicação

▶ Linhas de produtos de software

 Família de aplicações desenvolvidas em torno de uma
arquitetura comum

23
Técnicas (2)
▶ Empacotamento de sistemas legados
 Sistemas legados são empacotados pela definição de
interfaces de acessos
▶ Sistemas orientados a serviços
 Sistemas desenvolvidos pela criação de serviços
compartilhados
▶ Bibliotecas de programas
 Classes e funções que implementam abstrações
comumente usadas
▶ Desenvolvimento dirigido por modelos
 O código é gerado a partir de modelos de domínio e
modelos de implementação

24
Técnicas (3)

▶ Desenvolvimento orientado a aspectos

 Técnica avançada de modularização de código para
apoiar a reutilização
▶ Desenvolvimento baseado em componentes (DBC)
 Abordagem de desenvolvimento estabelecida pela
integração planejada de componentes de software já
existentes.

25
Desenvolvimento Baseado em
Componentes (DBC)

26
Desenvolvimento baseado em componentes (DBC) -
Histórico
▶ Em 1969, McIlRoy já vislumbrava uma indústria de
componentes de software reutilizáveis.
 1976: linguagens de interconexão de módulos
 Abordagens até então se baseavam fortemente em código
▶ No Final da década de 90 havia uma frustração com o
reutilização de classes da programação orientada a objetos
(POO)
▶ A Reutilização na POO é limitada 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ícil reutilizá-las sem ter o código fonte
 Têm granularidade muito baixa
▶ Atualmente: novo impulso para DBC com a Internet, Arquitetura
cliente/servidor, Modelos de Componentes Distribuídos (CORBA, COM,
REST, SOAP, etc).
27
Desenvolvimento Baseado em Componentes - Objetivo

▶ Objetivo: quebra de blocos monolíticos em

componentes interoperáveis.
 Componentes são construídos/empacotados com o
objetivo de serem reutilizados em diferentes aplicações
▶ Um componente provê um conjunto de serviços
acessíveis através de uma interface bem definida
▶ Dificuldades:
 O que é de fato um componente?
 Que tecnologias estão envolvidas?
 Como desenvolver componentes?

28
O que é um “Componente”?
▶ É uma 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.
29
Definição para Componentes - consenso

▶ Na literatura há características de consenso sobre

o que deve ser um componente:
 descrever ou realizar uma função específica
 estar em conformidade e prover um conjunto de
interfaces bem definidas
 ter disponível uma documentação adequada
 prover um grau de maturidade do componente
 estar inserido no contexto de um modelo que guie a
composição deste componente com outros (arquitetura
de software)
 ser autocontido em termos da funcionalidade que provê.

30
Componente quanto à natureza

▶ Em geral, um componente representa a

implementação em software de um conceito
autônomo ou processo de negócio.
▶ Há dois tipos de componentes:
 componentes de negócio, que o domínio em si consegue
reconhecer (ex. cliente, contas, etc)
 componentes de infraestrutura ou componentes de
suporte aos componentes de negócio (ex: em uma
bibliográfica gráfica há botões, caixa de texto, etc; para
suporte ao armazenamento de dados e persistência.).
▶ Especificação de interfaces bem definidas que permitam a
composição entre componentes sem a necessidade de
conhecer a parte interna do mesmo
31
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
32
Metodologias de DBC

▶ Entre as metodologias para DBC, 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.

33
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 terceiros

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

34
Notação para components (UML)

Forma expandida
Forma abreviada
«interface»
UML 1.4 Interface_A
Componente
tipo Operação_A1 (tipo args)
Interface Interface tipo Operação_A2 (tipo args)
fornecida requerida
realiza

UML 2.0 Componente

Interface Interface
requerida fornecida depende de
Componente
«interface»
Interface_B
tipo Operação_C1 (tipo args)
tipo Operação_C2 (tipo args)
35
Interface

▶ Uma interface é um conjunto de assinaturas de

operações que podem ser invocadas por um cliente
 cada operação deve ter sua semântica especificada
(Szyperski, 1998)
▶ Determinam como este componente pode ser
reutilizado e interconectado com outros
componentes
▶ Um componente exporta (provê) serviços que
outro componente importa (requer).
▶ Na prática, seu uso dependerá da arquitetura. Ex:
Corba, Java RMI, Web Services, etc.
36
Exemplo

ICancelaReserva IFazReserva
...
Sistema de
reserva de
hotel

...
ICobrança
IGerencia

37
Exemplo

ICancelaReserva IFazReserva «interface»

... IFazReserva
getDetalhesHotel ( )
Sistema de getInfoQuartos ( )
reserva de FazReserva ( )
hotel

...
ICobrança usa
IGerencia

«interface»
IGerencia
getDetalhesHotel ( )
getInfoQuartos ( )

38
Repositório de componentes
▶ Base preparada para o armazenamento e
recuperação de componentes
▶ Recuperação efetiva: informações adicionais
relativas ao componente
▶ Três tipos de repositório:
 Repositórios locais
 Repositórios específicos a um domínio
 Repositórios de referência

▶ Exemplo de ferramenta para gerenciamento de

repositório:
 Apache Archiva (https://archiva.apache.org)

39
Referência

▶ SOMMERVILLE, Y. Engenharia de Software 9ª ed. Pearson -

Adisson Wesley 2011.
 Cap.15 e 16 (Reutilização, Componentes)

▶ Artigo “Gerência de Configuração no Desenvolvimento

Baseado em Componentes ”, 2007. Disponível em
http://www2.ic.uff.br/~leomurta/papers/murta2007.pdf

40