16 Component Es

7/23/2019 16 Component Es

http://slidepdf.com/reader/full/16-component-es 1/39

Curso de Especialização – DEINF - UFMA

Desenvolvimento Orientado a Objetos

Prof. Geraldo Braz Junior

Desenvolvimento Orientado a

Componentes



Introdução Engenharia de software baseada em componentes (CBSE –

Component Based Software Engineering) é uma abordagem aodesenvolvimento de software que se baseia em reutilização desoftware através de componentes.

Ela surgiu a partir do fracasso do desenvolvimento orientadoa objetos para apoiar a reutilização eficaz.

Classes de objetos individuais são muito detalhadas e específicas.

Os componentes são mais abstratos que as classes de objetos

e podem ser considerados prestadores de serviço autônomo.

2



Fundamentos CBSE Componentes independentes especificados por suas

interfaces.

Padrões de implementação de Componentes para facilitar a

integração de componentes.

Middleware que fornece suporte para a interoperabilidade.

Um processo de desenvolvimento que é orientada para a

reutilização.

3



CBSE e princípios de projeto Além dos benefícios de reutilização, CBSE é baseado em

sólidos princípios de projeto de engenharia de software:

Os componentes são independentes, de modo nãointerferem uns com os outros;

Implementações de componentes são ocultadas;A comunicação ocorre através de interfaces bem

definidas;

Plataformas de componentes são compartilhados ereduzem os custos de desenvolvimento.

4



Componente como um prestador de

serviços

O componente é uma entidade independente executável.Ele não tem que ser compilado antes de ser usado com

outros componentes.

Os serviços oferecidos por um componente sãodisponibilizados através de uma interface e todas as

interações entre componentes realizada através da

interface.

5



Problemas CBSE

Confiabilidade de componentes

Certificação de componentes - Quem vai certificar a

qualidade dos componentes?

Previsão de Propriedade Emergente- Como é possívelprever propriedades emergentes em relação aos

componentes?

Trade-off entre compromissos de Requisitos do sistema

com componentes disponíveis em mercado

6



Características

Padrão padronização de componentes significa que um componente que é usado em

um processo CBSE tem de obedecer a algum modelo de componentes

padronizados. Este modelo pode definir as interfaces de componentes, o

componente de meta-dados, a composição, documentação e implantação.

Independente Um componente deve ser independente - deve ser possível utilizá-lo e

implantá-lo sem ter que usar outros componentes específicos. Em situaçõesem que o componente precisa de serviços fornecidos externamente, estas

devem ser definidas de forma clara em um “require" a especificação de

interface.

Passível de

composição

Para um componente pode ser composto, todas as interações externas devem

ocorrer por meio de interfaces publicamente definidas. Além disso, deve

fornecer o acesso externo a informações sobre si próprio, como os seus

métodos e atributos.

7



Características

Implantável Para ser implantado, um componente tem de ser auto-suficiente e deve ser

capaz de operar como uma entidade autônoma sobre a plataforma, que

implementa o modelo de componente. Isso geralmente significa que o

componente é um componente binário que não precisa ser compilado antes de

ser implantado.

Documentado Componentes têm que ser devidamente documentados, para que os potenciais

utilizadores do componente possam decidir se eles atendam às suas

necessidades. A sintaxe e, idealmente, a semântica de todas as interfaces de

componentes devem ser especificados.

8



Interfaces de Componentes Interface Forncecida

Define os serviços que são oferecidos pelo componente

Interface requerida

Define os serviços que especifica quais serviços devem ser

disponibilizados para que o componente possa executar

conforme especificado.

9



Interfaces de Componentes

Provides int erfaceRequires int erface

ComponentDefines the servicesfrom the component’s

environment that it

uses

Defines the servicesthat are provided

by the component

to other components

10



Um componente Coletor de Dados

Provides int erfaceRequires int erface

Data collector

addSensor

removeSensor star tSensor

stopSensor

testSensor

listAll

report

initialise

sensorManagement

sensorData

11



Modelos de Componentes

Um modelo de componente é uma definição de normaspara documentação de componentes, execução e

implantação.

Exemplos de modelos de componentes Modelo EJB (Enterprise Java Beans)

Modelo COM + (. Modelo NET)

Corba

O modelo de componente especifica como as interfacesdevem ser definidas e os elementos que devem ser

incluídas em uma definição de interface.

12



Elementos de um modelo de

componentes

Component model

Interfaces Usage

information

Deployment

and use

Interface

definition

Specific

inter faces

Composition

Nam ing

convention

Meta-data

access

Customisation

Packaging

Documentation

Evolution

suppor t

13



Middleware Modelos de componentes são a base para o middleware que

fornece suporte para a execução de componentes.

Implementação do modelo de componentes fornece: Plataforma de serviços que permitem que componentes escritos de acordo

com o modelo possam se comunicar;

Serviços horizontais que sejam serviços independentes da aplicação utilizadapor diferentes componentes.

Para usar os serviços fornecidos por um modelo, os componentessão implantados em um container. Este é um conjunto deinterfaces utilizadas para acessar as implementações de serviço.

14



Modelo de Serviços de Componentes

Platform services

Addressing Inter face

definition

Component

communications

Exception

management

Horizontal services

Security

Transaction

management

Concurrency

Component

management

Persistence

Resource

management

15



Componente de desenvolvimento para

reutilização

Componentes desenvolvidos para uma aplicação específica,normalmente têm de ser generalizado para torná-losreutilizáveis.

Um componente é mais provável de ser reutilizável, se

associado a uma abstração de domínio estável (objeto denegócio).

Por exemplo, em um hospital, abstrações estáveis

de domínioestão associados com o objetivo fundamental –

gerenciamento de enfermeiros, pacientes, tratamentos, etc

16



Componente de desenvolvimento

para reutilização

Reutilização de componentes Deve refletir abstrações estáveis do domínio;

Deve ocultar a representação do Estado;

Deve ser tão independente quanto possível;

Deverá publicar exceções por meio da interface docomponente.

Há um trade-off entre reusabilidade e usabilidade

Quanto mais a interface é genérica, maior a capacidade dereutilização,

No entanto, a reutilização é mais complexa

17



Mudanças para reutilização

Remover métodos de aplicação específica.

Mudar de nomes para torná-los geral.

Adicionar métodos para ampliar a cobertura.

Fazer tratamento de exceção consistente. Adicionar uma interface de configuração para a adaptação do

componente.

Integrar componentes necessários para reduzir as

dependências.

18



Componentes de Sistemas Legados

Sistemas legados existentes que desempenham uma funçãoútil do negócio podem ser re-empacotados como

componentes para reutilização.

Trata-se de escrita de um wrapper que implementa e provê

interfaces que acessam o sistema legado.

Apesar de uma abordagem relativamente custosa, a mesma

pode ser muito menos dispendiosa do que reescrever o

sistema legado.

19



Os componentes reutilizáveis O custo de desenvolvimento de componentes

reutilizáveis

pode ser maior do que o custo de criação de

equivalentes específicos.

Este custo extra deve ser mantido pela organização e não

pelo projeto.

Componentes genéricos podem ser menos eficientes na

alocação de espaço e ter tempos de execução maiores do que

uma solução específica.

20



O processo CBSE

Quando reutilizar componentes, é essencial para fazertrade-offs entre os requisitos ideais e os serviçosefetivamente prestados pelos componentesdisponíveis.

Trata-se de: Determinar o atendimento a todos os requisitos;

Componentes que possam ser modificados de acordo com amudanção de funcionalidade ou mudanças de funcionalidadesde acordo com os componentes disponíveis

Buscar novamente para descobrir se existem componentesmelhores que satisfaçam os requisitos revistos.

21



O processo CBSE

22

RequisitosGerais doSistema

IdentificarComponentes

Candidatos

Alterar Requisitosde acordo comcomponentesidentificadas

Projeto deArquitetura

IdentificarComponentes

Candidatas



O processo de identificação de

componentes

23

Busca deComponentes

Seleção deComponentes

Validação deComponentes



Questões na identificação de

componentes

Confiança:Você precisa ser capaz de confiar no fornecedor de umcomponente. Na melhor das hipóteses, um componente nãoconfiável pode não funcionar como anunciado, na pior dashipóteses, ele pode violar a sua segurança.

Requisitos: Diferentes grupos de componentes irão satisfazerexigências diferentes.

Validação:

A especificação do componente pode não ser suficientementedetalhado para permitir testes abrangentes para ser

desenvolvido. Os componentes podem ter funções desnecessárias. Como você

pode testar se isso não irá interferir com o seu pedido?

24



Composição de componentes

O processo de montagem de componentes para criar umsistema. (de compor)

A composição envolve a integração de componentes uns com

os outros e com a infra-estrutura componente.

Normalmente você tem que escrever “código cola” para

integrar componentes.

25



Tipos de composição

Composição seqüencial componentes compostos são executados em seqüência. Isso envolve

compor as interfaces disponibilidades de cada componente.

Composição hierárquica

Um componente chama serviços de outro.

Composição do aditiva

as interfaces de dois componentes são colocadas juntas paracriar um novo componente.

26



Tipos de composição

(a)

A A

B B

A B

(b) (c)

27



Incompatibilidade de Interfaces

Incompatibilidade de parâmetro onde as operações têm o mesmo nome, mas são de diferentes

tipos.

Incompatibilidade Operação

onde os nomes das operações nas interfaces compostas são

diferentes.

Inconclusão de Operação

onde a interface provides de um componente é um subconjunto

da interface required de um outro componente

28



Componentes Incompatíveis

addressFinder

phoneDatabase (string command)string location(string pn)

string owner (string pn)

string proper tyType (string pn)

mapper

mapDB (string command)displayMap (string postCode, scale)

printMap (string postCode, scale)

29



Adaptor

Resolver o problema de incompatibilidade de componentes,conciliando as interfaces dos componentes, que são

compostos.

Diferentes tipos de adaptadores são necessários dependendo

do tipo de composição.

Um addressFinder e um mapeador (exemplo anterior)

podem ser compostos através de um adaptador que tira o

código postal de um endereço e passa isso para o componente

de mapeamento.

30



Composição através de um adaptador

O postCodeStripper componente é o adaptador que facilita acomposição seqüencial dos componentes addressFinder e

mapper.

31

address = addressFinder.location (phonenumber) ;postCode = postCodeStripper.getPostCode (address) ;mapper.displayMap(postCode, 10000) ;



Adaptador para coletor de dados

Data collector

addSensor

removeSensor

star tSensor

stopSensor

testSensor

listAll

repor t

initialise

sensorManagement

sensorData

Adapter sensor

star t

getdata

stop

32



Interface

Você tem que confiar na documentação do componente paradecidir se as interfaces que são sintaticamente compatíveis

são realmente compatíveis.

Considere uma interface de um componente Photolibrary:

33

public void addItem (Identifier pid ; Photograph p; CatalogEntry photodesc) ;public Photograph retrieve (Identifier pid) ;public CatalogEntry catEntry (Identifier pid) ;



Foto composição biblioteca

Photo

Library

adaptor Image

Manager

getImage

User

Inter face

getCatalogEntry

addItem

retrieve

catEntry

34



OCL

O Object Constraint Language (OCL) é destinado a definiras restrições que estão associadas com os modelos UML.

Baseia-se em torno da noção de especificação de condição de

pré e pós

35



Descrição formal da biblioteca de fotos

usando OCL

-- The context keyword names the component to which the conditions applycontext addItem

-- The preconditions specify what must be true before execution of addItem

pre: PhotoLibrary.libSize() > 0

PhotoLibrary.retrieve(pid) = null

-- The postconditions specify what is t rue after executionpost: libSize () = libSize()@pre + 1

PhotoLibrary.retrieve(pid) = p

PhotoLibrary.catEntry(pid) = photodesc

context delete

pre: PhotoLibrary.retrieve(pid) <> null ;

post: PhotoLibrary.retrieve(pid) = null

PhotoLibrary.catEntry(pid) = PhotoLibrary.catEntry(pid)@pre

PhotoLibrary.libSize() = libSize()@pre - 1

36



PhotoLibrary Condições

Como especificado usando OCL:

Não deve haver uma fotografia na biblioteca com o mesmo

identificador como a fotografia para ser inscrito;

A biblioteca deve existir com pelo menos 1 item Cada nova entrada aumenta o tamanho da biblioteca por 1;

Se você recuperar uma foto passando um identificador, em

seguida você recebe de volta a foto que você adicionou;

37



Composição: relação de ganho

Ao compor componentes, você pode encontrar conflitos entrerequisitos funcionais e não funcionais, e os conflitos entre a

necessidade de entrega rápida e evolução do sistema.

Você precisa tomar decisões, tais como:

Qual a composição de componentes é eficaz para satisfazer os requisitosfuncionais?

Qual a composição de componentes permite mudar o futuro?

Quais serão as propriedades emergentes do sistema composto?

38



Referências

39

Ian Sommerville, Engenharia de Software. 8 edição Traduçãodas Notas de Aula disponibilizadas em http://www.cs.st-

andrews.ac.uk/~ifs/Books/SE8/Syllabuses/index.html

Documents

16 Component Es