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 de software 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 objetose 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 bemdefinidas;

Plataformas de componentes são compartilhados e reduzem 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ão

disponibilizados 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ível

prever 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ções

em 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

Component

Defines the services

from the component’s

environment that it

uses

Defines the services

that 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

repor t

initialise

sensorManagement

sensorData

11

Modelos de Componentes

Um modelo de componente é uma definição de normas

para 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 interfaces

devem 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

InterfacesUsage

informationDeployment

and use

Interface

definition

Specific

inter faces

Composition

Naming

convention

Meta-data

access

Customisation

Packag ing

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 de interfaces utilizadas para acessar as implementações de serviço.

14

Modelo de Serviços de Componentes

Platform services

AddressingInter face

definitionComponent

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á-los reutilizáveis.

Um componente é mais provável de ser reutilizável, se associado a uma abstração de domínio estável (objeto de negó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 do componente.

Há um trade-off entre reusabilidade e usabilidade

Quanto mais a interface é genérica, maior a capacidade de reutilizaçã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 fazer

trade-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 a mudançã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

Requisitos Gerais do Sistema

Identificar Componentes

Candidatos

Alterar Requisitos de acordo com componentes identificadas

Projeto de Arquitetura

Identificar Componentes

Candidatas

O processo de identificação de

componentes

23

Busca de Componentes

Seleção de Componentes

Validação de Componentes

Questões na identificação de

componentes Confiança:Você precisa ser capaz de confiar no fornecedor de um

componente. Na melhor das hipóteses, um componente nãoconfiável pode não funcionar como anunciado, na pior das hipó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 um

sistema. (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 envolvecompor 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 a

composiçã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

removeSensorstar tSensor

stopSensor

testSensor

listAll

repor t

initialise

sensorManagement

sensorData

Adaptersensor

star t

getdata

stop

32

Interface

Você tem que confiar na documentação do componente para

decidir 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

adaptorImage

Manager

getImage

User

Inter face

getCatalogEntry

addItem

retrieve

catEntry

34

OCL

O Object Constraint Language (OCL) é destinado a definir

as 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 apply

context 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 true after execution

post: 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 entre

requisitos 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 requisitos

funcionais?

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ção

das Notas de Aula disponibilizadas em http://www.cs.st-

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