Component Oriented Programming
Download
Report
Transcript Component Oriented Programming
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 ComponentsJ. J.Cheesman and J.Daniels
Catalysis http://www.iconcomp.com/catalysis D. D'Souza andA. A.
Wills
KobrA C.Atkinson et al.
59