Engenharia de Software
2007.1
Projeto com Reuso
31/05/07
1
Reutilização de software



Na maioria das disciplinas de engenharia, sistemas
são projetados com base na composição de
componentes existentes que foram utilizados em
outros sistemas.
A engenharia de software, até então, tinha como
base o desenvolvimento tradicional.
Para alcançar software com mais qualidade, de
forma mais rápida e com baixo custo, é necessário
adotar um processo de desenvolvimento baseado
na reutilização generalizada e sistemática de
software.
2
Engenharia de software baseado
no reuso de software

Reuso de sistemas de aplicações


Reuso de Componentes


Todo o sistema pode ser reutilizado pela sua
incorporação, sem mudança, em outros sistemas
Componentes de uma aplicação que variam
desde subsistemas até objetos isolados podem
ser reutilizados
Reuso de funções

Componentes de software que implementam uma
única função podem ser reutilizados
3
Artefatos reusáveis
 Afinal,
o que se pode “reusar”?

Código compilado

Casos de testes

Modelos e projetos: frameworks e padrões

Interface de usuário

Planos, estratégias e regras arquiteturais

Soluções

Idéias
4
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
5
Benefícios do Reuso

Maior confiabilidade


Redução dos riscos de processo


Reuso de componentes ao invés de pessoas.
Conformidade com padrões


Menos incertezas sobre as estimativas de custos de
desenvolvimento.
Uso efetivo de especialistas


Os componentes já foram experimentados e testados em
sistemas que já estão funcionando.
Os padrões são embutidos ao se reutilizar componentes.
Ex: padrões de interfaces com o usuário
Desenvolvimento acelerado

Reduz tempo do desenvolvimento e validação, acelerando
a produção
6
Benefícios do Reuso
 Resumindo
-> Produtividade
Trabalhar mais rápido
 Automação, ambientes, ferramentas
 Substituir trabalho humano
 Trabalhar mais inteligentemente
 Melhoria do(s) processo(s)
 Evitar/reduzir tarefas de pouco valor

 Evitar

o trabalho propriamente dito
Reuso de ARTEFATOS do CICLO DE VIDA

Evitar/reduzir o desenvolvimento de artefatos específicos
para cada projeto
7
Modelo Incremental para
adoção de Reuso
Reuse
enabled
business
Benefit
High reuse levels
Broader
coverage
Reduced
maintenance
costs
Reduced
Development
time
Systematic
Domainspecific
Architecture reuse
reuse
Managed
workproducts
Black box
code reuse
Code
leverage
None
Investment, experience
8
O que são Padrões

O que é?

Nova categoria de conhecimento
Conhecimento não é novo, mas falar sobre ele é
 Objetivo: conhecer o que você já conhece


Como?

Partindo de problemas e soluções recorrentes
em diferentes áreas do conhecimento
9
O que é um Padrão (Cont.)

Aplicação


Arquitetura
Ciência da Computação




Engenharia de software
Engenharia Mecânica
Telecomunicações
...
10
O que é um Padrão (Cont.)

Por que padrões de software?




engenheiros de software não iniciam o seu
projeto do nada
ao contrário, nós reutilizamos “idéias”que já
vimos antes
as mesmas técnicas são utilizadas
repetitivamente
a indústria de software necessita documentar
o que nós fazemos
11
Diferentes Definições

“Um padrão é uma entidade que descreve
um problema que ocorre repetidamente em
um ambiente e então descreve a essência
da solução para este problema, de tal forma
que você use esta solução milhões de vezes,
sem nunca utilizá-la do mesmo modo,”
Christopher Alexander
12
Diferentes Definições (Cont.)

“Um padrão é um pedaço de literatura que
descreve um problema de projeto e uma
solução geral para o problema num contexto
particular, ” James Coplien
13
Diferentes Definições (Cont.)

“Um padrão é uma solução provada para um
problema em um contexto, ” Comunidade de
Software
14
Um Pouco da História





Object-Oriented (OO)
 Metade do anos 80
Padrões de software emergiram de objetos
Ward Cunningham and Kent Beck
 1987: linguagem de padrões para interface de usuário
James Coplien
 1988: idioms
Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides
 1990  1995: Padrões de projeto (Design Patterns)
15
Diferentes tipos de padrões

Etapas de Desenvolvimento de Sistemas


Domínio de Aplicação


Segurança, BD, GUI, XML, Web, Sistemas
Distribuídos
Camada de Aplicação do Padrão


Requisitos, Análise, Projeto, Implementação e Teste
Negócios, Apresentação, Integração (Sun)
Classificação de Autores


GoF: Estrutural, Comportamental, Criação
POSA: Sistemas Interativos, Organização do
Trabalho, Comunicação
16
Classificação dos Padrões de Software (Cont.)
Padrões
Arquiteturais
Padrões de
Requisitos
Padrões de
Análise
Meta-Padrões
Idiomas
Padrões de
Projeto
Requisitos
Análise
Projeto
Implementação
17
Padrões de Requisitos



Documentam as necessidades do usuário e
o comportamento genérico do sistema em
um alto nível de abstração
Ações que os desenvolvedores de software
podem tomar para melhorar os requisitos
não-funcionais
Mostram os relacionamentos entre o usuário
ou o operador e o sistema
18
Padrões de Requisitos (Cont.)

Fault-tolerant telecommunication patterns


Visa a manutenção dos sistemas de comutação
Medidas apropriadas para serem tomadas no estágio
de desenvolvimento de requisitos
 Padrões relacionados a confiabilidade (mensagens
do sistema e falhas do sistema)


Five minutes of no escalation messages
Padrões relacionados aos fatores humanos
19
Padrões de Análise


Inicialmente apresentados como complementos
aos padrões de projeto
Um passo antes do projeto


Modelo de análise que focaliza nas estruturas
conceituais
Padrões de análise do Martin Fowler


Domínio de conhecimento de software de negócios
Party, quantity, subtype state machines, entre outros
20
Padrões de Análise (Cont.)



Party
Problema: pessoas e organizações têm
responsabilidades semelhantes
Solução: Crie um tipo party como um
supertype de uma pessoa ou organização
21
Padrões de Projeto





Estrutura repetida de elementos de projeto
“Um esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relações entre eles.”
“...resolvem um problema geral de projeto num contexto
particular.”, GoF
Padrões de projeto que incluem detalhes de código de baixo
nível
Aplicados a diferentes tipos de problemas
Padrões Arquiteturais e Meta-Padrões podem ser
considerados Padrões de Projeto.
22
Idiomas


Relacionados com a implementação de
características de projeto específicas
Padrão de baixo nível específico para uma
linguagem de programação

Idiomas em C++

C++ Programming Styles and Idioms, James
Coplien, 1991
23
Idiomas (Cont.)





Nome: Counted Body
Contexto: A interface de uma classe é separada de sua
implementação (respectivamente, classes handle e body)
Problema: atribuição em C++ é definida recursivamente
como membro-por-membro com cópia quando a recursão
termina
Solução: Um contador de referência é adicionado à classe
body para facilitar o gerenciamento de memória
Autor e data: James Coplien, 1994
24
A Comunidade de Padrões





Uma hierarquia de workshops de escritores
Grupos de leitura local
Grupo Hillside
Livros com os artigos da conferência
Conferências PLoP ao redor do mundo
25
Ética de Padrões





Regra de Buschmann: nunca capture suas
próprias idéias em um padrão
Não pense que padrões resolvem tudo
Tente sempre encorajar as pessoas a repassar os
conhecimentos
Sempre reconheça aqueles que criaram as
técnicas ou que primeiro se empenharam a
escrever sobre elas
Padrões são “apenas” mais uma técnica para
ajudá-lo no desenvolvimento de software
26
Reuso

Conheça os padrões que estão disponíveis



Catálogo de padrões de 2000
Escolha aquele que satisfaz as suas necessidades
 Um padrão é difícil de entender se você não necessita
dele
 Apenas tenha uma visão geral
Utilize o vocabulário dos padrões em revisões e
sessões de projeto
27
Reuso (Cont.)

GoF


Core J2EE Pattern Catalog


Bastante utilizado entre a comunidade de software
http://java.sun.com/blueprints/corej2eepatterns/
Padrões Arquiteturais

Frank Bushmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Michael Stal (Gang of Five)
28
GoF Design Patterns
Behavioral Patterns
Creational patterns
Abstract factory
Chain of Responsibility
Builder
Command
Interpreter
Factory method
Prototype
Singleton
Iterator
Structural patterns
Mediator
Adapter
Memento
Bridge
Observer
Composite
State
Decorator
Strategy
Facade
Template Method
Flyweight
Visitor
Proxy
29
Core J2EE Pattern Catalog
Presentation Tier
Integration Tier
Intercepting Filter
Front Controller
Data Access Object
View Helper
Service Activator
Business Tier
Composite View
Business Delegate
Service to Worker
Service Locator
Dispatcher View
Session facade
Transfer Object
Transfer Object
Assembler
Value List Handler
Composite Entity
30
Architectural Patterns
From Mud to Structure
Layers
Adaptable Systems
Pipes and Filters
Reflection
Blackboard
Microkernel
Distributed Systems
Broker
Pipes and Filters
Microkernel
Interactive Systems
Model-ViewController
PresentationAbstractionControl
31
Template
GoF
J2EE
Coplien
POSA
Nome
Classificação
Intenção
Também Conhecido
Como
Motivação
Aplicabilidade
Estrutura
Participantes
Colaborações
Implementação
Código Exemplo
Consequências
Usos Conhecidos
Padrões
Relacionados
Nome
Problema
Forças
Solução
- Estrutura
- Estratégias
Consequências
Código Exemplo
Padrões
Relacionados
Nome
Contexto
Problema
Forças
Solução
Sketch
Contexto Resultante
Argumentação
(Rationale)
Nome
Também
Conhecido Como
Exemplo
Contexto
Problema
Solução
Estrutura
Dinâmica
Implementação
Exemplo Resolvido
Variantes
Usos Conhecidos
Consequências
Veja Também
32
Maiores Informações

Página de Padrões do Grupo Hillside

http://hillside.net


Apontadores para listas, livros, arquivos ftp, padrões online, conferências, entre outros
Listas



[email protected]
[email protected]
[email protected]
 [email protected]

Repositório de Padrões Portland

http://c2.com/ppr/index.html
33
Em resumo ...

Arquitetos experientes não têm consciência que
utilizam padrões


Padrões funcionam como uma porta para troca
de experiências



Bons para compartilhar informação e capturar
conhecimento
Pode ajudar novos desenvolvedores a aprenderem
com os mais experientes
Vocabulário Comum
Padrões dão uma competência arquitetural de
organização
34
Em resumo ... (Cont.)

Você deve escrever padrões para




Aprender mais sobre padrões
Compartilhar conhecimento
 Provavelmente você usa alguma coisa que não foi
documentada ainda
Tarefa difícil e nem todos tem tempo ou vontade
Você deve reutilizar padrões

Em busca de uma melhoria no desenvolvimento de
software
35
Component
Dictionary definition

A unit of, part of a model

Hardware components
Software components


SD
1
•
2
3
4
5
6
7
8
9
10
11
12
Differences?
36
What is a component? (1)
1.
A component is a nontrivial, nearly independent, and
replaceable part of a system that fulfills a clear function
in the context of a well-defined architecture. A
component conforms to and provides the physical
realization of a set of interfaces. (Philippe Krutchen,
Rational Software)
2. A runtime software component is a dynamically bindable
package of one or more programs managed as a unit
and accessed through documented interfaces that can
be discovered at runtime. (Gartner Group)
37
What is a component? (2)
3. A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be
deployed independently and is subject to third-party
composition. (Clemens Szyperski)
4. A business component represents the software
implementation of an “autonomous” business concept or
business process. It consists of the software artifacts
necessary to express, implement, and deploy the
concept as a reusable element of a larger business
system. (Wojtek Kozaczynski, SSA)
38
What is a component? (3)
5. A reusable part of software, which is
independently developed, and can be
brought together with other components to
build larger units. It may be adapted but may
not be modified.
A component can be, for example, a compiled
code without a program source, or a part of a
model and/or design.
--- D'Souza and Wills
39
What is a component? (4)
6. A software component is a software element that
conforms to a component model and can be
independently deployed and composed without
modification according to a composition
standard.
--- Councill and Heineman
40
What are in common?





A piece of software
Independently deployable
Composable
Self-contained
Reusable


A set of interfaces provided to, or required from
the environment.
An executable code, which can be coupled to the
code of other components via interfaces.
41
Implications

The following implications arise as a result of
Szyperski’s definition:



For a component to be deployed independently, a
clear distinction from its environment and other
components is required.
A component must have clearly specified
interfaces.
The implementation must be encapsulated in the
component and is not directly reachable from the
environment.
42
Implications


A software component simply cannot be
differentiated from other software elements
by the programming language used to
implement the component.
The difference is in how software
components are used.
43
DBC

Abordagem de desenvolvimento de software
na qual todos os aspectos e fases do ciclo de
vida do desenvolvimento, incluindo análise
de requerimentos, arquitetura, projeto,
construção, testes, distribuição, suporte
técnico, e também a gerência de projeto, são
baseados em componentes.
44
Commonality and Difference



SP (Structured Programming)
OOP (Object-Oriented Programming)
COP (Component-Oriented Programming)


What are common?
What are different?
45
SP
OOP
COP
Yes
Yes
Yes
Unification of data and function
 a software entity combines data and the functions
processing those data.
 improve cohesion
Yes
Yes
Encapsulation
 The client of a software entity is insulated from
how that software entity’s data is stored or how its
functions are implemented.
 Reduce coupling
Yes
Yes
Identity
 Each software entity has a unique identity
Yes
Yes
Divide and conquer
 for managing complexity
 break a large problem down into smaller pieces
Interface
 represent specification dependency
 divide a component specification into interfaces
 restrict inter-component dependency
Yes
46
Composability

Software entity and its ability of being integrated
with other entities

SP – functions, procedures: low

OOP – classes, objects: high

COP – components: very high
47
The Interchangeability




Interchangeable parts are components of any
device designed to specifications which insure that
they will fit within any device of the same type.
SP: Two different implementations can never be
interchangeable.
OOP: Two different objects implementing the same
specification are interchangeable.
COP: Two different components with different
specifications are interchangeable as long as they
satisfy those interface requirements for all client
components.
48
Component Goals
If you are asked to name three goals for using
component technology, what are they?
1.
2.
3.
Conquering complexity
Managing change
Reuse
49
Conquering Complexity



We are living in a complex world!
“The world produces between 1 and 2
exabytes of unique information per year,
which is roughly 250 megabytes for every
man, woman, and child on earth. An exabyte
is a billion gigabytes, or 1018 bytes.”
http://www.sims.berkeley.edu/research/projec
ts/how-much-info/summary.html
50
Managing Change




Change is inherent in software engineering.
The user requirements change, specifications
change, personnel change, budgets change,
technology change, etc. etc.
This means building for change, design for change,
is necessary.
It is important to place primary emphasis during
architecture and design on the dependencies
between the components, and the management of
those dependencies.
51
Reuse



Design and implement something once and
use it over and over again in different
contexts.
This will realize large productivity gains,
taking advantage of best-in-class solutions,
the consequent improved quality, and so
forth.
Develop for reuse, and develop with reuse
52
CBSE



Component-Based Software Engineering
CBSE = COA + COD + COP + COM
Two key activities:


Development for reuse
Development with reuse
53

Para se criar um componente, devemos
primeiro garantir:




Que os serviços que o componente oferece,
independam do contexto
Que os dados que o componente trabalha, sejam
acessíveis em qualquer projeto
Que o componente defina e implemente sua
interface padrão
Que o componente esteja dentro de um container
padrão
54
Conclusão

Objeto vs. Componente

Componentes são independentes do contexto
onde são usados.


Criado de tal forma que funciona em qualquer projeto
de software, módulo ou container.
Objetos são projetados para um fim específico, e
não podem (ou não devem) ser utilizados em
outros contextos.

Ex: se você criar um objeto Pedido para um sistema
de atacado, dificilmente este objeto poderá ser
utilizado em outro aplicativo como um aplicativo de
gestão de recursos humanos.
55
Conclusão

Objeto vs. Componente


Quando modelamos objetos, pensamos
primeiramente no problema que tentamos
resolver
Componentes são projetados para serem
elementos chave de qualquer aplicativo de
software



Todo componente deve ter suas interfaces bem
definidas
3’s C (Containers, Conectors and Components)
Exemplos
56
Problemas com Reuso

Aumento nos custos de manutenção


Falta de ferramentas de apoio





»Código fonte de componentes não disponíveis
»Falta integração de CASEs com bibliotecas de
componentes
Síndrome do “não foi inventado aqui”
Manutenção de uma biblioteca de componentes
Encontrar e adaptar componentes reutilizáveis
É preciso ser planejado e incorporado por meio de
um programa de reuso da organização.
57
Referências
Andrade, R.M.C, “Capture, Reuse, and Validation of Requirements
and Analysis Patterns for Mobile Systems”, Ph.D. Thesis,
University of Ottawa, Ottawa, 2001.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., FiksdahlKing, I., and Angel, S., A Pattern Language: Towns, Buildings,
Construction, Oxford University Press, New York, NY, 1977.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.,
Pattern-Oriented Software Architecture, John Wiley and Sons, New
York, NY, 1996.
Coplien, J. O., Software Patterns, SIGS books and Multimedia, June
1996.
Fowler, M., Analysis Patterns: Reusable Object Models, AddisonWesley, Reading, MA, 1997.
58
Referências (Cont.)
Gamma E., Helm R., Johnson R., Vlissides J., “Design Patterns:
Element of Reusable Object-Oriented Software”, 1995.
Pattern Languages of Program Design I, II, III & IV; Patterns from the
PLoP Conference at Allerton Park in Illinois, US and EuroPLoP in
Europe; Addison-Wesley, 1994-95-96-98.
Rising, Linda, “Patterns: A Way to Reuse Expertise,” IEEE
Communications Magazine, Vol. 37, No. 4, April 1999.
Rising, Linda, The Pattern Almanac 2000, Software Pattern Series,
Addison-Wesley, 2000. ISBN 0-201-61567-3.
Metodologias para o DBC
Wang A.J.A, Qian K, Component Oriented Programming
UML Components􀂄J. J.Cheesman and J.Daniels
Catalysis http://www.iconcomp.com/catalysis D. D'Souza andA. A.
Wills
KobrA C.Atkinson et al.
59