Especificação de Componentes
Conteúdo M2
8° SI -‐ UMC
Prof. Fabiano
Elementos de um componente
Especificação:
Um componente requer uma descrição abstrata
dos serviços que ele oferece servindo como um
contrato entre o cliente e o fornecedor do
serviço.
A especificação, além da relação das operações
disponíveis, orienta o cliente a como interagir
com o componente e informa as restrições dos
Elementos de um componente
Possibilidade de implementações:
Um componente deve suportar uma ou mais
implementações, as quais devem estar em
conformidade com a especificação.
A especificação deve ser flexível para que o
implementador possa escolher a linguagem
adequada, configuração adequada outros
recursos que julgar necessário.
Elementos de um componente
Padrão de Componente:
Um componente deve aderir a um modelo de
componentes. Os modelos de componentes
suportam um conjunto de serviços.
Exemplos de modelos de componentes:
§
MicrosoO COM+/DCOM
§
MicrosoO .NET
§
OMG Corba CCM
§
Sun EJB.
Elementos de um componente
Empacotamento:
Os componentes podem ser agrupados em
unidades funcionais conhecidas como pacotes
(package), permi[ndo que o conjunto de
serviços oferecidos por eles possa ser
subs[tuído por outro componente similar e que
possa ser distribuído e instalado.
Elementos de um componente
Distribuído (Deployment):
Implementação de Componentes
§
Podem exis[r componentes de soOware
implementados em um paradigma procedural,
tais como ro[nas em COBOL e bibliotecas de
funções em C, embora, a maior parte dos
componentes seja desenvolvida u[lizando-‐se
metodologias e linguagens orientadas a objetos.
§
Para um componente o relevante é sua interface
externa e não a maneira como foi implementado.
Implementação de Componentes
§ As primeiras APIs para componentes disponibilizavam apenas um conjunto de funções que componentes externos poderiam invocar, enxergando o componente com um bloco único.
§ Atualmente, as APIs possibilitam acessar os objetos que compõe o modelo do componente. Desta maneira, as interfaces que o
componente disponibiliza ou requer definem o modelo de objetos que é compaavel com aquele componente.
§ Referências a objetos criados em um componente deixam as fronteiras e se tornam visíveis aos clientes do componente. Por
exemplo, é possível acessar o objeto célula do componente Planilha Eletrônica, o objeto ponto do Gerenciador Gráfico, etc. Desta
maneira, o componente deixa de ser visto como um bloco único para ser visto como um contexto onde os objetos executam.
Implementação de Componentes
§ Outro fator importante a ser considerado na construção de componentes é o empacotamento, que possibilita que o componente seja instalado como uma unidade.
§ empacotamento pode conter arquivos, módulos, código executável, código fonte, código de validação, especificações, testes,
documentações, etc.
§ Os mecanismos para o empacotamento diferem de tecnologia para tecnologia.
§ Por exemplo, componentes Java são empacotados em arquivos JAR, que incluem as classes que implementam os serviços dos
componentes, as classes adicionais, etc.
§ Os diversos fatores que definem as possibilidades de
implementação de um componente são definidos no component
model correspondente.
Modelos de Componentes
§ Ao comprar um eletrodomés[co, podemos plugá-‐lo na tomada de uma casa porque a tomada, o plug e a energia disponíveis são
aderentes a uma padronização.
§ Ao buscarmos a reu[lização e subs[tu[bilidade de componentes de soOware, eles também devem ser aderentes a um padrão, que na literatura é chamado de modelo de componentes (component
model).
§ Assim como há mais de um padrão para tomada, há mais de um modelo para componentes de soOware.
§ Um programador pode criar seu próprio modelo, eventualmente sendo uma especialização de um modelo disponível. Para
compa[bilizar componentes de um modelo para outro, pode-‐se desenvolver adaptadores.
Modelos de Componentes
§ Um component model define vários aspectos da construção e da interação dos componentes, abordando, entre outros fatores: como especificar o componente, como instanciar o componente, quais os [pos de conectores e portas disponíveis, qual o modelo de dados que é entendido por todos os componentes, como as
ligações entre os objetos pertencentes a componentes diferentes são realizadas, como são feitas transações distribuídas, quais são os [pos de interface, as interfaces obrigatórias, como são tratados o catálogo e a localização dos componentes, o despacho das
requisições e respostas, a segurança, o repositório, o formato, a nomeação, os meta dados, a interoperabilidade, a documentação, os mecanismos de customização, a composição, a evolução, o
controle de versões, a instalação e a desinstalação, os serviços de execução, o empacotamento, etc.
Modelos de Componentes
§
Alguns component models u[lizam uma interface
descrip0on language (IDL) independente da
linguagem de programação, enquanto outros
valem-‐se de conceitos da própria linguagem ou
da tecnologia para definir a interface, como é o
caso das interfaces OO. Dependendo da IDL,
interfaces podem incluir as exceções que podem
ser lançadas, pré-‐ condições e pós-‐condições
Modelos de Componentes
§
Um component model deve definir quais são os padrões de
composição.
§
Os [pos de acoplamento mais comuns entre dois
componentes são o de cliente/servidor e de publicador/
ouvinte.
§
No primeiro, o cliente explicitamente chama operações do
servidor e, no segundo, o ouvinte se registra como tratador
de eventos e informações disponibilizadas pelo publicador.
§
O component model define também os [pos de conectores
disponíveis, que podem ser herdados da linguagem de
programação correspondente ou serem próprios da
Modelos de Componentes
§
O component model também define o padrão de
deployment, que especifica a estrutura e a
semân[ca para os arquivos descritores. O
component model define a maneira como é feito
o deployment, incluindo o eventual registro do
componente e da interface.
§
Tipicamente o deployment envolve três passos:
o instalação do componente;o configuração do componente e do ambiente de execução; e o instanciação do componente para uso.
Modelos de Componentes
§
Corba Component Model (CCM), MicrosoO OLE,
MicrosoO (D)COM/COM+, MicrosoO .NET, Sun
EJB, JavaBeans e Webservice são alguns
exemplos de componente models.
§
Alguns modelos, como CORBA e Webservices,
possibilitam a reu[lização de componentes que
não foram necessariamente desenvolvidos na
mesma linguagem de programação.
Exemplos de Modelos de Componentes
COM
• Component Object Model (COM) é uma plataforma da MicrosoO para com-‐ ponentes. Ela viabiliza comunicação entre processos e criação dinâmica de objetos em diferentes linguagens. A sigla COM é muitas vezes usada como sinônimo para um grupo de tecnologias, dentre elas: Object Linking and Embedding (OLE), OLE Automa0on, Ac[veX, COM+ e DCOM. Apesar de introduzido em 1993 no desen-‐ volvimento dos produtos, a MicrosoO não divulgou sua biblioteca até 1997.
• COM é uma tecnologia independente de linguagem de programação para o desenvolvimento dos seus componentes. Dessa forma, eles podem ser u[lizados em ambientes diferentes dos quais foram criados. É uma pré-‐ condição do Component Object Model que o desenvolvedor forneça uma interface bem definida e separada da implementação, permi[ndo a
reu[lização dos objetos sem o conhecimento de sua implementação. • Apesar de ter sido implementado portável a várias plataformas, COM é
muito u[lizado nos sistemas operacionais da MicrosoO Windows. Tem-‐se trabalhado para que ela seja subs[tuído, ou pelo menos estendido, pela plataforma MicrosoO .NET, suportando então Web Services através da Windows Communica0on Founda0on (WCF).
Exemplos de Modelos de Componentes
COM+§ COM+ é o nome da tecnologia baseada nos serviços e
funcionalidades da COM e sua primeira versão foi lançada no Windows 2000. COM+ acrescentou à COM com-‐ ponentes para
suportar as funcionalidades da MicrosoA Transac0on Server (MTS). • Essa tecnologia também encapsula algumas a[vidades de baixo
nível, como ma-‐ nutenção do pool de conexões, finalização de conexões, controle transacional e dis-‐ tribuição e controle de submissões.
• Para fornecer aos desenvolvedores suporte a transações distribuídas e melhor gerenciamento de memória e
processamento, assim como para posicionar o Win-‐ dows como uma alterna[va a outros sistemas operacionais corpora[vos, a
Micro-‐ soO introduziu a tecnologia MicrosoA Transac0on Server no Windows NT Service Pack 4. No Windows 2000, tal extensão
significa[va à COM foi incorporada ao sis-‐ tema operacional e renomeada COM+. Na mesma época a DCOM foi reconsiderada como uma en[dade separada.
Exemplos de Modelos de Componentes
.NET
• A plataforma COM vem sendo subs[tuída pela MicrosoO .NET, com a
MicrosoO focando seu marke[ng exclusivamente a essa nova plataforma. A COM era geralmente usada para interoperar códigos complexos e de grande desempenho com interfaces ao usuário em Visual Basic ou ASP. Para algumas extensões a COM agora foi depreciada em favor da .NET já que a .NET fornece ferramentas de desenvolvimento rápido similares ao Visual Basic tanto para Windows Forms quanto para Web Forms com Just-‐ in-‐Time(JIT), o código de alto desempenho pode ser implementado em C#. • Apesar disso, a COM permanece como uma tecnologia viável com
importante base de sistema legado. Por exemplo, o SoAware
Development Kit (SDK), popular renderizador do DirectX 3D, é baseado em COM. A COM também trabalha com o controle de scripts de aplicações como o Office ou o Internet Explorer, pois fornece uma interface para chamar métodos de objetos COM de um script ao invés de ne-‐ cessitar o conhecimento de uma API em tempo de compilação.
• Vários serviços fornecidos pela COM+ ainda são importantes em aplicações .NET corpora[vas, tais como transações e filas de componentes.
Exemplos de Modelos de Componentes
EJB
• Nessa seção serão abordados tópicos sobre o funcionamento dos
Enterprise Java Beans (EJB) em sua versão 3.0. A figura 5.1
simplifica o funcionamento da arquite-‐ tura EJB:
• Os EJBs são conhecidos por serem o núcleo da plataforma J2EE
(Java 2 Pla-‐ taform Enterprise Edi0on) justamente por sustentarem de uma maneira robusta e simples o desenvolvimento de
aplicações de grande porte, provendo um modelo distribuído de componentes de negócio e provedores de serviços dentro do contêiner da aplicação.
• Em EJB, os beans são considerados remotos; então, mesmo na
implementação de um bean descrito como local, deve-‐se fazer uma busca pela implementação da interface e então pode-‐se u[lizar
suas funcionalidades. O responsável por achar, instanciar e retornar a implementação da interface é o contêiner onde executa-‐se a
aplicação. Caso o contêiner não ache ou apresente falha nesse processo, uma exceção será lançada pela aplicação e o uso do componente ficará inviabilizado.
Exemplos de Modelos de Componentes
Webservices
§
Webservices é um padrão para comunicação
entre componentes através da tecnologia
Web.
§
A aplicação u[liza os serviços destes
componentes através do protocolo SOAP, que
encapsula as chamadas dos serviços e os
retornos em pacotes XML ou JSON (JavaScript
Object Nota[on).
Infra-‐estrutura de Execução
§ Um contêiner é um sistema, normalmente desenvolvido por terceiros,
com o obje[vo de hospedar e gerenciar componentes de um determinado modelo, provendo a eles serviços de infra-‐estrutura de execução.
§ O acesso remoto, o gerenciamento de transações distribuídas, o pooling de recursos, o acesso concorrente, o clustering, a tolerância a falhas, a auten[cação, a persistência, a configuração, o gerenciamento de
permissões e de sessão, etc., são exemplos de serviços providos por containers.
§ O container libera o desenvolvedor de implementar serviços técnicos de sistema de baixo nível, direcionando seus esforços para as regras de negócio e para a composição do sistema.
§ Em alguns casos, o uso de container também possibilita alterar aspectos não relacionados com a lógica do negócio sem ter que alterar a aplicação, bastando re-‐configurar o container para mudar aspectos como segurança, permissões, logging, banco de dados, etc.
Infra-‐estrutura de Execução
§
A máquina virtual Java é um contêiner para executar
componentes Java (arquivos .class ou .jar).
§
Algumas arquiteturas estendem o container para gerenciar
componentes mais especializados como servlets ou
applets.
§
Tomcat, JBoss, Webspheare, Pluto, JetSpeed, etc. são
outros exemplos de containers.
§
O container define uma interface que estabelece a conexão
com os componentes. Esta interface é chamada de lifecycle
interface. Esta interface é acessada pelo container para
gerenciar a inicialização, execução e desa[vação do
componente.
Contêineres
§
Um Contêiner é um ambiente de execução para
componentes
§
Faz a ligação entre os componentes e o mundo exterior
§
Recebe pedidos de execução de serviços e os repassa
ao componente, que executa o serviço
§
Evita que o componente tenha que interagir com o
sistema operacional, o suporte de comunicação e com
os serviços de aplicação
§
Permite que componente seja independente do
ambiente de execução, tornando-‐o mais portável e
mais fácil de reuPlizar
Contêineres
•
Contêineres u[lizam recursos de soOware e
hardware e serviços da plataforma de
execução para executar o componente
–
Serviço de Nomes: permite localizar instâncias de
componentes
–
Serviço de Comunicação: troca de informação
–
Serviço de Persistência: faz o armazenamento de
estado dos componentes
–
Serviço de Transações: mantém a consistência
–
Serviço de Segurança: auten[ca componentes e
Contêineres
•
Tipos de Interfaces:
–
Externa: Atravessa o contêiner
–
Interna: acessível somente dentro do contêiner
–
De Callback: interface usada pelo contêiner para
Contêineres
•
O contêiner efetua Callbacks para:
–
Indicar falhas na obtenção ou na u[lização de
recursos do suporte de execução
–
Entregar mensagens do serviço de comunicação
–
Salvar o estado do componente e restaurá-‐lo em
caso de reinicialização
–
Relatar a violação de regras de funcionamento ou
de segurança
Interação
•
Componentes interagem para trocar dados e
solicitar a execução de serviços
•
Componentes podem estar localizados em:
–
Um mesmo servidor -‐> Interação local
–
Servidores diferentes -‐> Comunicação remota
•
O ideal é que o desenvolvedor abstraia a
localização dos componentes, podendo agir
da mesma forma independentemente de os
componentes estarem na mesma máquina ou
em máquinas diferentes
Interação
•
Para abstrair a localização de componentes o
ideal é que os mecanismos usados para
interação local sejam usados também para
comunicação remota
•
Mecanismos de interação local
–
Chamada de procedimento/método
–
No[ficação de eventos/mensagens
•
Mecanismos de comunicação remota
–
Chamada remota de proced./método
Interação
•
Chamada de procedimento/método
–
Segue o modelo Cliente/Servidor
–
Um componente fornece uma interface com
procedimentos/métodos para solicitar a execução
de seus serviços – é um servidor
–
Componentes/aplicações u[lizam os serviços de
outros componentes – são seus clientes
Interação
•
No[ficação de eventos remotos
–
Produtores e consumidores de eventos podem
estar em máquinas diferentes
•
Canal de eventos permite desacoplamento
–
Não é necessário que as partes se conheçam ou se
sincronizem para enviar o evento
Interação
•
Formato dos dados
–
Na chamada de método, a sua assinatura define os
parâmetros e seus [pos de dados
–
O formato dos eventos é em geral mais flexível
•
Cardinalidade
–
Chamada de método tem sempre apenas um
cliente e um servidor
Interação
•
Sincronismo
–
Na chamada de método o emissor fica bloqueado
aguardando o término da execução
–
Na no[ficação de eventos o produtor con[nua a
execução sem aguardar resposta
Interação
•
Protocolos de comunicação de alto nível são
necessários para interação entre
componentes em máquinas diferentes
•
Escolha natural: usar TCP/IP como base
–
Cria conexões entre processos para troca de
mensagens
–
Amplamente disponível, confiável e robusto
–
Rela[vamente simples e eficiente
Interação
•
Mecanismo de comunicação entre
componentes deve tratar questões não
resolvidas pelo TCP/IP
–
Formato comum dos dados
–
Localização de componentes
–
Segurança
•
Os protocolos usados pelos suportes de
execução de componentes já incorporam tais
mecanismos
Projeto
•
Projeto de sistemas basedos em componentes
–
Técnicas tradicionais de Eng. de SoOware podem
ser usadas na análise e projeto de sistemas
baseados em componentes
–
Com base nas funcionalidades requeridas do
sistema, define-‐se quais componentes são
necessários para sua construção
–
Deve-‐se buscar reu[lizar componentes e/ou
desenvolver novos componentes que possam ser
reaproveitados
Projeto
•
Projeto deve levar em conta que:
–
O componente deve fornecer serviços a outros
componentes, que os u[lizarão através das
interfaces do componente
–
Deve ser possível ajustar a forma como os serviços
são executados, alterando valores de
propriedades
–
O componente deve ser sujeito a composição
–
O componente deve procurar ser independente de
outros componentes
Projeto
•
Abordagem de Cheesman & Daniels
–
Modelagem do Domínio: realizada para entender
o contexto do problema a ser solucionado, sem
assumir nenhuma solução de soOware
–
Especificação do SoOware: consiste na concepção
de um sistema de soOware para resolver o
Projeto
•
Modelagem do Domínio
–
Definir casos de uso
–
Definir modelo conceitual
–
Definir modelo comportamental
•
Especificação do SoOware
–
Iden[ficar componentes
–
Iden[ficar interações entre componentes
–
Especificar componentes
Projeto
•
Casos de uso
–
Especificam as funcionalidades existentes no
sistema
–
Exemplo: Sistema de Bibliotecas
Nome: Efetuar emprésPmo
ObjePvo: Emprestar um livro a um usuário
Pré-‐condição: Livro deve estar disponível para emprésPmo; usuário deve ter <5 livros emprestados.
Ação: emprestar (livro, usuário)
Nome: Fazer devolução
Obje[vo: Devolver um livro emprestado a um usuário
Pré-‐condição: Livro estar emprestado; não estar danificado. Ação: devolver (livro)
Projeto
•
Modelo conceitual
–
Especificar as en[dades do mundo real
manipuladas pelo sistema e suas associações
–
Exemplo:
•
Modelo comportamental
–
Iden[ficar estados, eventos e transições de estado
–
Exemplo: Diagrama de estados de livro
Projeto
•
Iden[ficação de componentes
–
Produz uma especificação de arquitetura inicial de
um sistema
–
Iden[fica as interfaces suportadas por cada
componente
–
Deve-‐se sempre buscar reu[lizar componentes
–
Exemplo:
Projeto
•
Interação entre componentes
–
Iden[fica as operações necessárias
–
Atribui responsabilidades
–
Exemplo:
•
Se uma pré-‐condição exige que o usuário respeite um
limite máximo de emprés[mos, deve haver uma
operação para recuperar o número de emprés[mos de
um usuário
•
O componente Gerenciador de Usuários e a en[dade
Projeto
•
Especificação dos componentes
–
Cria uma especificação detalhada das interfaces
dos componentes, definindo as assinaturas de
suas operações e suas propriedades
–
Exemplo:
Kits de Componentes
§
Um component kit é uma coleção de
componentes que foram projetados para
trabalhar em conjunto.
§
Component kits são frequentemente u[lizados
para construir interfaces gráficas para aplicações
a par[r de botões, formulários, listas, etc.
§
De um kit de componentes gera-‐se uma família
de soluções, fazendo diferentes arranjos e
eventualmente desenvolvendo alguns sob
medida.
Kits de Componentes
§ Um toolkit é um [po de SDK (SoAware Development Kit), que apresenta, além dos componentes, um conjunto de ferramentas para criar aplicações para uma determinada plataforma, sistema ou framework. Os toolkits são mais comumente encontrados para componentes de interface com o
usuário, também chamados de widgets. Alguns exemplos de toolkits de widgets para a linguagem Java são o AWT (Abstract Windowing Toolkit), Swing e SWT (Standard Widget Toolkit).
§ Toolkits possibilitam que programadores desenvolvam soOware a par[r de componentes prontos, mesmo sem muita experiência de programação, no es[lo das ferramentas RAD (Rapid Applica0on Development). Os toolkits favorecem a cria[vidade dos desenvolvedores, o que é fundamental para áreas não bem estabelecidas. Ao encapsular detalhes de implementação de baixo nível, os toolkits liberam os desenvolvedores para pensar em novas interfaces e mecanismos de interação, e possibilitam uma
Arquitetura de So>ware Baseada em Componentes
§ Uma arquitetura define a estrutura de um soOware, descrevendo as propriedades, restrições e relacionamentos de suas partes.
§ Ela representa o conjunto de restrições e regras da implementação, definindo os elementos, conectores, protocolos, componentes,
propriedades visíveis e a interação e a função de cada parte no contexto do sistema.
§ A arquitetura é uma representação abstrata de alto nível do projeto de um soOware. A granularidade dos componentes da arquitetura pode variar de pequenos pedaços de código a aplicações inteiras, como SGBDs ou servidores de e-‐mails.
§ As conexões entre os componentes abstraem como eles de fato interagem, como por exemplo, chamada de método,
compar[lhamento de dados, pipes, RPCs (Remote Procedure Calls), sockets, etc.
Arquitetura de So>ware Baseada em Componentes
§ A maneira de reu[lizar bons projetos de arquiteturas é através dos es[los arquiteturais. Um es[lo arquitetural descreve uma família de arquiteturas de soOware que compar[lham propriedades, como por exemplo, os
componentes permi[dos, as restrições e interações entre os componentes, as invariantes, o modelo computacional, etc.
§ Fluxo de dados, máquina virtual, chamada de procedimento, MVC (Model View Controller), cliente-‐servidor, peer-‐to-‐peer, blackboard, camadas e orientação a serviços são exemplos de es[los arquiteturais.
§ Cada es[lo normalmente endereça um aspecto específico do sistema, sendo portanto possível de u[lizar mais de um es[lo na mesma
arquitetura. Além disto, cada componente de um sistema pode ter uma arquitetura e es[lo arquitetural próprios, desde que a parte externa do componente seja compaavel com a arquitetura da aplicação.
Arquitetura de So>ware Baseada em Componentes
§
Apesar da arquitetura ser única, pode-‐se fornecer várias
visões sobre ela. Cada visão enfoca um determinado aspecto
da arquitetura, omi[ndo os demais
§
Algumas visões são mais apropriadas para o desenvolvimento
do sistema, outras para o reuso, outras para o teste e
implantação.
§
O desenvolvimento baseado em componentes considera pelo
menos duas visões da arquitetura: arquitetura de aplicação e
arquitetura técnica.
Arquitetura de So>ware Baseada em Componentes
§ Na arquitetura de aplicação, a preocupação é com a estrutura dos
componentes do domínio, representando um projeto lógico de alto nível independente da tecnologia de suporte. Nesta arquitetura são mostradas a função de cada componente no contexto do sistema e a interação entre eles. A arquitetura de aplicação consiste de um conjunto de decisões
sobre a plataforma, um conjunto de component frameworks e os mecanismos de interoperação entre eles.
§ A arquitetura técnica considera os detalhes da tecnologia de
componentes a ser u[lizada e é totalmente independente do domínio da aplicação. A arquitetura técnica retrata as tecnologias de comunicação entre os componentes (TCP/IP, ODBC, etc.) e aspectos referentes a escalabilidade e performance.
