Tecnologias de Reuso

Desenvolvimento de Sistemas Colaborativos
MAC0434 e MAC5798 Desenvolvimento de Sistemas Colaborativos
Tecnologias de Reuso
Marco Aurlio Gerosa gerosa@ime.usp.br
Marco A. Gerosa 1 / 53 IME / USP
Algumas Formas de Reuso

Sub-rotinas, funes e procedimentos - agrupamento de cdigo Bibliotecas de funes - agrupamento de funes relacionadas em um pacote Herana - reuso da implementao de uma classe, de modo a estender o comportamento Frameworks e Componentes Agrupamento de classes de forma mais propcia para reuso e extenso Aspectos Separao e centralizao de cross-cutting concerns
Marco A. Gerosa
2 / 53
IME / USP
Vantagens do reuso
Vantagens do desenvolvimento com reuso:
Reduo da quantidade de cdigo a ser escrito e mantido Uso de cdigo j testado e validado Possibilidade de investimento de esforos na parte especfica da aplicao Reduo do tempo para produo de uma famlia de aplicaes (Product Line). Adaptao e evoluo
Em caso do reuso de design:

Melhor adaptao da reuso do cdigo, visto que ela decidida em fases iniciais do desenvolvimento, sendo ento mapeada a cdigo Direcionamento a uma arquitetura voltada para o domnio especfico
Marco A. Gerosa
3 / 53
IME / USP
Frameworks
Marco A. Gerosa
4 / 53
IME / USP
Frameworks
Da mesma forma que classes abstratas funcionam como um molde para as suas subclasses, um framework funciona como um molde para aplicaes. uma implementao de uma soluo parcial.
Marco A. Gerosa
5 / 53
IME / USP
O que um framework?
Um framework pode ser considerado como uma infraestrutura de classes que prov o comportamento necessrio para implementar aplicaes de um domnio.
O framework no gera uma aplicao no sentido da aplicao ficar independente. O framework instanciado e se torna parte da aplicao, reusando o que comum e especializando o que especfico.
Frameworks, sozinhos, no so executveis. Desta forma, para produzir uma aplicao executvel deve-se instanciar o framework de forma especfica aplicao.
Aplicao
Framework
Marco A. Gerosa
6 / 53
IME / USP
Framework
Meios para extenso:
Herana Composio Parametrizao (XML)
Framework no gerenciador de componentes e no repositrio de componentes. A aplicao utiliza a infra-estrutura provida pelo framework e fica acoplada a ele. O processo de reuso de frameworks comumente chamado de processo de instanciao. durante este processo que os pontos de extenso existentes no framework so preenchidos para se obter a aplicao final.
Marco A. Gerosa
7 / 53
IME / USP
Definies
Um framework definido como um sistema composto de um subsistema ncleo, que comum a todas as aplicaes que so instanciadas a partir deste framework, e um subsistema de hot-spots que o implementa o comportamento especifico das aplicaes instanciadas. Sendo assim, um desenvolvedor de uma aplicao gera uma instncia do framework adequando o subsistema de hot-spots durante o processo de instanciao. [Fontoura, 1999] Um framework de classes define um conjunto de classes e a parte de suas implementaes que comum a todas as aplicaes do domnio do framework [Szyperski, pg 368].
Marco A. Gerosa
8 / 53
IME / USP
Pontos de extenso
As partes do framework que podem ser customizadas e extendidas so so chamadas de hot-spots enquanto as outras partes so chamadas de frozen-spots (kernel) Os frozen-spots so partes de cdigo j implementadas no framework que chamam um ou mais hotspots definidos em cada instncia
Marco A. Gerosa
9 / 53
IME / USP
Modelo de objetos
Ao fazer o modelo de objetos, deve-se criar classes abstratas ou interfaces nos pontos onde se deseja que os desenvolvedores da aplicao provenham funcionalidade especfica. Herana x composio
Marco A. Gerosa
10 / 53
IME / USP
Classificao (Escopo)
Infra-estrutura cuida de solues de problemas tcnicos. Integrao So comumente utilizados para integrar sistemas distribudos permitindo a troca de dados entre sistemas heterogneos. Domnio Especfico Estes frameworks so direcionados um domnio de aplicao especfico.
Mais de um framework pode ser utilizado na mesma aplicao, cada um cuidando de um aspecto [Govoni, 1999]. Desafio: composio de frameworks
Marco A. Gerosa
11 / 53
IME / USP
Documentao
Com relao a artefatos reusveis, prover uma documentao clara atualizada fundamental, visto que alm do usurio desenvolvedor, h tambm o usurio reutilizador, que normalmente no o desenvolvedor original e, muitas vezes, no um expert no domnio da aplicao. A documentao do framework precisa apresentar de forma clara, no s suas estruturas internas mas como sua (re-)utilizao dever ser feita.
Marco A. Gerosa
12 / 53
IME / USP
Componentes de Software
Marco A. Gerosa
13 / 53
IME / USP
Histrico
A idia de que o software deveria ser componentizado surgiu na conferncia da NATO, que lanou o termo engenharia de software, na Alemanha em 1968. Nesta conferncia, Doug McIlroy [1968], em um artigo intitulado Mass Produced Software Components, levantou a necessidade de agrupar coerentemente rotinas relacionadas de forma a montar componentes que poderiam ser reutilizados em diversos sistemas. Esta reutilizao, alm de economizar esforo de desenvolvimento, possibilitaria a produo de programas a partir de partes j testadas e amplamente utilizadas. De acordo com ele, j naquela poca, os requisitos de software no eram novos e j teriam sido desenvolvidos anteriormente em um contexto um pouco diferente.
Marco A. Gerosa
14 / 53
IME / USP
Desenvolvimento Baseado em Componentes

O Desenvolvimento Baseado em Componentes (DBC) surgiu como uma nova perspectiva para o desenvolvimento de software, cujo objetivo a quebra dos blocos monolticos em componentes interoperveis, reduzindo, tanto a complexidade no desenvolvimento, quanto os custos, por meio da reutilizao de componentes [Sametinger, 1997]. O software passa a ser composto de partes relativamente independentes, que foram concebidas para serem substituveis, reutilizveis e interoperveis.
Marco A. Gerosa
15 / 53
IME / USP
Exemplo de Componentizao
Boto ligar velocidade Motor Boto parar Marcador
A componentizao neste exemplo ilustrada pelo fato de os mesmos botes e o marcador poderem ser reutilizados em outras situaes (por exemplo, utilizando o marcador para marcar a temperatura) e estes componentes serem substituveis por outros equivalentes (por exemplo, substituindo os dois botes por uma chave liga-desliga ou o marcador analgico por um digital). A interoperabilidade assegurada pela compatibilidade entre os conectores. As interconexes so feitas pelos fios eltricos.
Princpios: reuso, substituio e montagem
Conceito de Lego
Exemplo de Componentizao em SW
Aplicao Aplicao Web
Newsfeed
Planilha
Banco de Dados
Uma aplicao:
l dados de um newsfeed sobre aes registra em uma planilha, que faz clculos, e passa os resultados a um banco de dados. Uma aplicao web extrai as informaes sob demanda.
Cada um destes componentes poderia ser visto como uma aplicao stand-alone, talvez at com sua prpria interface grfica. Porm, so disponibilizados meios para interagir com outros softwares. Eventualmente, um destes componentes, a planilha por exemplo, nem precisa de interface grfica ou de mecanismos de persistncia.
Definio de Componente de Software

Para alguns autores um componente de software pode ser qualquer elemento que possa ser reutilizado: cdigo binrio, cdigo fonte, estruturas de projeto, especificaes e documentaes [Krueger, 1992]. Outros autores focam na tecnologia, e consideram um componente um cdigo que segue um modelo de componentes, de forma que qualquer objeto acessvel por um middleware visto como um componente
A component is an object written to a specification. It does not matter what the specification is: COM, Java Beans, etc., as long as the object adheres to the specification. [Wikipedia, 2005].
Para o DBC as caractersticas de projeto so relevantes (reuso, encapsulamento, etc.)
Marco A. Gerosa
18 / 53
IME / USP
Algumas Definies
Grady Booch [1987]: Mdulo logicamente coerente e fracamente acoplado que denota uma abstrao nica. Meta Group [1994]: Mdulo de software reusvel, autocontido, pr-testado e pr-fabricado que agrupa conjuntos de dados e procedimentos e desempenha tarefas especficas. Johannes Sametinger [1997]: Pedao de software autocontido, claramente identificvel, que descreve ou executa funes especficas, tem interfaces claras, documentao apropriada e um status de reuso. Clemens Szyperski [1998, pg 34]: Unidade binria com interfaces contratualmente especificadas e dependncias de contexto explcitas, que pode ser disponibilizado de forma independente e usado por terceiros sem modificao para compor aplicaes finais.
Marco A. Gerosa
19 / 53
IME / USP
Algumas Definies
Component Int. Labs [1995]: Pedao de software pequeno o suficiente para implementar e manter, grande o suficiente para distribuir e dar suporte, e com interfaces padronizadas para oferecer interoperabilidade. Brown & Wallnau [1996]: Um componente uma parte notrivial de um sistema, praticamente independente e substituvel, com uma funo clara no contexto de uma arquitetura bem definida. Barroca et al. [2005]: Unidade de software independente, que encapsula, dentro de si, seu projeto e implementao, e oferece servios, por meio de interfaces bem definidas, para o meio externo.
Marco A. Gerosa
20 / 53
IME / USP
Algumas Definies
Um pacote coerente de software que (a) pode ser desenvolvido e entregue independentemente como uma unidade, (b) tem interfaces explcitas e bem definidas para os servios que ele prov, (c) tem interfaces explcitas e bem definidas para os servios que ele espera de outros, e (d) pode ser utilizado para composio com outros componentes, sem alteraes em sua implementao, podendo eventualmente ser customizado em algumas de suas propriedades. Um componente de software um elemento que est em conformidade com um modelo de componentes e pode ser implantado (deployed) independentemente e composto sem modificaes.
Marco A. Gerosa
21 / 53
IME / USP
Caractersticas dos componentes de sw

auto-contidos (so relativamente independentes, fracamente acoplados e encapsulam seu projeto e implementao, incluindo dados e funcionalidades); reusvel (podem ser utilizados por terceiros, que no necessariamente precisam ter acesso ao seu cdigo fonte); substituveis (podem ser trocados por outros componentes compatveis) provem servios especficos de uma maneira coesa e bem definida, possivelmente padronizada; podem ser desenvolvidos e mantidos independentemente. possui uma especificao clara do que requer e do que prov [Szyperski, pg. 30]. executvel* em sua forma de disponibilizao. *Szyperski chamava anteriormente de forma binria, mas mudou na nova verso de seu livro para executvel.
Marco A. Gerosa
22 / 53
IME / USP
Exemplos de componentes
Plugins dos navegadores web, IDEs, editores, etc. Widgets de interface com o usurio Add-ons, Mdulos, Servios, etc.
Marco A. Gerosa
23 / 53
IME / USP
Diferenciao com outras tecnologias

Dada a elasticidade e o desgaste do termo componente, apropriado diferenci-lo de outros conceitos e tecnologias para melhor caracteriz-lo.
Mdulo Objeto Classe Biblioteca API
Marco A. Gerosa
24 / 53
IME / USP
Mdulo x Componente
O conceito de componente similar ao conceito tradicional de mdulo, presente h bastante tempo na engenharia de software. A modularidade um pr-requisito para a tecnologia de componentes. O que diferencia a tecnologia de componentes so as padronizaes (modelo de componentes) e infra-estrutura especfica para seu gerenciamento e execuo (component framework).
Marco A. Gerosa
25 / 53
IME / USP
Objeto x Componente
Tambm h uma confuso entre componentes e objetos, principalmente porque a maioria dos componentes implementada utilizando linguagens orientadas a objetos.
Objetos so instncias identificveis criadas por um sistema em execuo. O componente cria, envia e recebe objetos. Componentes muitas vezes so representados e acessados por mltiplos objetos de diferentes classes.
Marco A. Gerosa
26 / 53
IME / USP
Classe x Componente
Classe representa uma abstrao lgica (classe conceitual) ou uma estrutura de programao utilizada para gerar objetos (classe de software). A componentizao se encontra em um nvel de abstrao diferente. Um componente uma unidade de execuo, que pode ser a implementao fsica de uma ou de um conjunto de classes*. Uma classe s pode pertencer a um nico componente. Um componente no necessariamente precisa estar na mesma mquina que a aplicao que a utiliza e nem na mesma linguagem de programao. Diferentemente de classes, um componente pode estar disponvel somente na forma binria e o nome do componente no pode ser utilizado para definir o tipo de uma varivel ou parmetro. * Um componente no obrigatoriamente precisa conter classes. Um componente pode conter cdigo escrito em outras tecnologias.
Marco A. Gerosa
27 / 53
IME / USP
Classe x Componente
As padronizaes para componentes tambm so mais abrangentes do que as padronizaes para classes. O modelo de componentes define o empacotamento, ciclo de vida, conectores, interfaces providas e requeridas, etc. Componentes tambm tm uma gama maior de mecanismos de intercomunicao, como eventos e workflow, alm das mensagens da orientao a objetos. Mesmo estando em nveis de abstrao diferentes, por simplificao do discurso, costuma-se chamar a(s) classe(s) que implementam o componente de componente.
Marco A. Gerosa
28 / 53
IME / USP
Biblioteca x Componente
Biblioteca de funes outro termo que costuma causar confuso com componente. Uma biblioteca tambm prov servios coesos para um sistema, auto-contida, reutilizvel e substituvel. Uma biblioteca eventualmente tambm disponibilizada na forma binria e pode ser orientada a objetos. Entretanto, uma biblioteca normalmente no pressupe uma padronizao, instalao e configurao (deploy), e nem a existncia de uma plataforma especfica de execuo.
Marco A. Gerosa
29 / 53
IME / USP
API x Componente
API (Application Program Interface) - que representa parte do contrato de utilizao de um pedao de cdigo. Uma API expe o conjunto de operaes, procedimentos, funes, tipos e constantes que podem ser utilizados externamente. Respeitando a API e os requisitos no-funcionais, possvel trocar o componente ou a infra-estrutura, sem impactar o cdigo cliente. Exemplo: API do Windows, que compatvel entre suas diversas verses. O usurio pode compor o seu ambiente de trabalho instalando e configurando os componentes que julgar necessrios.
Marco A. Gerosa
30 / 53
IME / USP
O que chamar de componente?

Muitas vezes, o termo componente usado com pouco rigor em diversos nveis de abstrao, o que pode causar alguma confuso. Chama-se de componente:
a especificao do componente a implementao (component source code) o executvel que implementa a especificao (deployable component) a instalao em particular daquele executvel (deployed unit) a execuo especfica daquele executvel a instncia do componente
Marco A. Gerosa
31 / 53
IME / USP
Granularidade de um componente
Com relao a granularidade, um componente pode ser to simples como uma nica classe ou to complexo como um subsistema. O que caracteriza uma unidade de software como componente que ela deve ser passvel de implementar e manter independentemente, no-trivial e com uma funo clara no contexto da arquitetura, bem como passvel de separao, distribuio e reutilizao.
Marco A. Gerosa
32 / 53
IME / USP
Benefcios e Dificuldades da Componentizao
Marco A. Gerosa
33 / 53
IME / USP
Benefcios
Manutenabilidade Adaptabilidade Prototipao Flexibilidade extensvel ao usurio final Encapsulamento do conhecimento do domnio e das complexidades tcnicas Reuso Favorece o ciclo iterativo
Marco A. Gerosa
34 / 53
IME / USP
Dificuldades
Esforo inicial no projeto e implementao
aumenta a necessidade de flexibilidade, documentao, estabilidade e abrangncia do software O software deve ser bem documentado, testado e validado, e deve ter um esquema robusto de validao
Curva de aprendizagem A programao de alto nvel possibilitada pela componentizao, muitas vezes leva a uma perda de flexibilidade, por encapsular as funcionalidades de baixo nvel. Uso de componentes de terceiros:
possibilidade de introduo de bugs desconhecidos pode ser necessrio reimplementar uma grande quantidade de cdigo esforo continuado de atualizao de verses e de reconfigurao dos sistemas
Desenvolvimento baseado em componentes tambm demanda uma adaptao no processo de desenvolvimento
Marco A. Gerosa
35 / 53
IME / USP
Papis
Desenvolvedores Integradores Usurios Intermedirios (brokers) Avaliadores/certificadores Fornecedores de ferramentas
Marco A. Gerosa
36 / 53
IME / USP
Componentes para o usurio final

Mesmo utilizando uma arquitetura de componentes, a interface da aplicao pode ocultar dos usurios finais que o sistema foi desenvolvido baseado em componente. A componentizao fica disponvel apenas aos desenvolvedores, que podem liberar diferentes verses da aplicao alterando a configurao e o conjunto de componentes. Quando for necessrio prover flexibilidade para o usurio final, pode-se disponibilizar a ele o conceito de componente, bem como os mecanismos para colocar e retirar componentes da aplicao. Estes componentes muitas vezes so do estilo plug & play, que imediatamente se tornam disponveis para uso aps o deploy.
Marco A. Gerosa
37 / 53
IME / USP
Termos relacionados
Marco A. Gerosa
38 / 53
IME / USP
Porta
Uma porta um meio identificvel de conexo, por onde um componente oferece seus servios ou acessa os servios dos outros.
Operao, propriedade e evento so exemplos de tipos de portas de um componente. Cada porta tem uma identificao (nome ou nmero pelo qual a porta acessada) H portas de entrada e de sada de dados. Cada porta define os tipos de valores que so transmitidos ou recebidos [Catalysis, pg 415]. Uma porta normalmente implementada por uma operao.
Marco A. Gerosa
39 / 53
IME / USP
Conector
Ao meio por onde acontece a conexo entre duas ou mais portas dado o nome de conector. O conector pode ser implementado por invocao explcita de funo, envio de mensagens sncronas ou assncronas, propagao de eventos, stream de dados, workflow, cdigo mvel, dilogo atravs de uma API, transferncia de arquivo, pipe, propagao de eventos, buffer, sinalizao, compartilhamento de arquivo via ftp, etc. Os tipos de conectores variam para cada tecnologia e ferramenta adotada. Por exemplo, JavaBeans oferece um conjunto de conectores diferentes dos oferecidos pelo COM+. Tipicamente, os componentes interagem entre si atravs de chamadas de mtodos, em um estilo cliente/servidor ou publicador/ouvinte.
Interface
A interface representa o contrato de utilizao do componente. Respeitando-se este contrato, pode-se alterar a implementao interna do componente ou substitu-lo por outro, sem modificar quem o utiliza. O contrato pode cobrir aspectos funcionais e no funcionais. Aspectos funcionais incluem a sintaxe e a semntica da interface. Os no funcionais incluem os aspectos referentes qualidade de servio. A interface de um componente de software funciona como a especificao dos pinos de um circuito integrado. Para usar o circuito, basta conhecer o funcionamento de sua interface externa e prever na arquitetura do circuito, o encaixe para ele. No necessrio o conhecimento dos detalhes internos de funcionamento do componente (abordagem caixa preta). A interface separa a especificao e a implementao do componente.
Interfaces Fornecidas e Requeridas

As interfaces podem ser classificadas em dois tipos: interfaces fornecidas (provided interfaces) e interfaces requeridas (required interfaces). Um componente d suporte a uma interface fornecida se o componente contm uma implementao de todas as operaes definidas por aquela interface. Um componente possui uma interface requerida se o componente usa uma operao definida naquela interface. Componentes se conectam por meio da interface requerida de um com a interface fornecida de outro.
Se um componente for totalmente auto-contido, ele no possui interface requerida. Um componente pode requerer mais de uma interface e estar em conformidade com mais de uma interface fornecida. As dependncias de contexto so definidas pelas interfaces requeridas
Interfaces Fornecidas e Requeridas

Componente A Aplicao
interface fornecida interface requerida
Componente B
Componente D
interface requerida
interface fornecida
Componente C
interface fornecida
Marco A. Gerosa
43 / 53
IME / USP
Implementao de interface
Pode-se utilizar a estrutura de interface da orientao a objetos para implementar o conceito de interface de componente. Propriedade e eventos so mapeados na forma de mtodos, porm, no possvel representar alguns aspectos da interface, como os aspectos no-funcionais e as interfaces requeridas. Uma interface passa a ser um conjunto de operaes que podem ser invocadas pelos clientes.
Marco A. Gerosa
44 / 53
IME / USP
Adaptador
Cdigo adicional, conhecido como conector, pode ser inserido entre componentes para realizar converses simples de modo a compatibilizar interfaces nos casos em que a substituio de tipos no suficiente.
Componente A Aplicao
Componente B
Componente D
interface requerida
interface fornecida
Componente C
interface fornecida
Marco A. Gerosa
45 / 53
IME / USP
Instncia de Componente
Chama-se de instncia de componente, o conjunto de objetos pelos quais se manipula o componente. Estes objetos so a manifestao do componente em tempo de execuo.
Marco A. Gerosa
46 / 53
IME / USP
Deployment
Para utilizar um componente necessrio instal-lo (deployment) em uma infra-estrutura de execuo. Esta instalao no pressupe a modificao do componente. Entretanto, ele pode ser customizado externamente.
Marco A. Gerosa
47 / 53
IME / USP
Customizao de componentes
A customizao a habilidade de adaptar um componente antes da instalao ou do uso. Pode-se construir componentes genricos e oferecer mecanismos para o utilizador especializar seu comportamento. Como normalmente componentes so desenvolvidos no estilo black box, revelando o mnimo de sua implementao, as maneiras mais comuns de customizar um componente atravs da modificao de propriedades ou da composio com outros componentes que especializam determinados comportamentos.
Marco A. Gerosa
48 / 53
IME / USP
Customizao de um componente
Na customizao por composio, um componente passa a conter uma referncia a outro e repassa a ele as chamadas das operaes. Outra maneira de customizar o comportamento de um componente modificando suas propriedades. Tcnicas para isto incluem passagem de parmetros para seus mtodos, tabelas lidas pelo componente, configurao e opes no deploy.
Uma abordagem comum associar um arquivo descritor a um componente. O arquivo descritor possibilita que o componente seja configurado sem que seja necessrio recompil-lo.
Marco A. Gerosa
49 / 53
IME / USP
Implementao dos Componentes

Desde que sejam mantidas as funcionalidades e as caractersticas visveis externamente (contrato de utilizao), o componente pode ser desenvolvido internamente utilizando procedimentos, funes, orientao a objetos, outros componentes e/ou frameworks, ou qualquer outra tecnologia ou ferramenta. Entretanto, a maior parte dos componentes desenvolvida utilizando-se metodologias e linguagens orientadas a objetos. A orientao a objetos uma das melhores maneiras de implementar componentes.
Marco A. Gerosa
50 / 53
IME / USP
Modelo de objetos
As primeiras APIs para componentes disponibilizavam apenas um conjunto de funes que componentes externos poderiam invocar, enxergando o componente com um bloco nico. Atualmente, as APIs possibilitam acessar os objetos que compe o modelo do componente. Referncias a objetos criados em um componente deixam as fronteiras do componente e se tornam visveis aos clientes do componente.
Marco A. Gerosa
51 / 53
IME / USP
Empacotamento
Um componente composto de vrios elementos atmicos que so instalados sempre em conjunto. O empacotamento do componente pode conter arquivos, mdulos, cdigo executvel, cdigo fonte, cdigo de validao, especificaes, testes, documentaes, etc. Os mecanismos para este empacotamento diferem de tecnologia para tecnologia. Por exemplo, componentes Java so empacotados em arquivos JAR, que incluem as classes que implementam os servios do componentes, as classes adicionais, etc.
Marco A. Gerosa
52 / 53
IME / USP
Modelagem
Marco A. Gerosa
53 / 53
IME / USP
Modelo de Componentes
Marco A. Gerosa
54 / 53
IME / USP
Padronizao
Ao comprar um eletrodomstico, podemos plug-lo na tomada de uma casa porque a tomada, o plug e a energia disponveis so aderentes a uma padronizao. Para os componentes serem interoperveis e para favorecer a reutilizao e substitutibilidade, eles devem ser aderentes a um padro, que na literatura chamado de modelo de componentes (component model*). Assim como h mais de um padro para tomada, h mais de um modelo para componentes de software. Um programador pode criar seu prprio modelo, eventualmente sendo uma especializao de um modelo disponvel. Para compatibilizar componentes de um modelo para outro, pode-se desenvolver adaptadores. * O termo component model equivalente ao termo component architecture definido por [DSouza & Wills, 1998].
Marco A. Gerosa
55 / 53
IME / USP
Component Model
Um component model define vrios aspectos sobre a construo de um componente e sobre a interao entre os componentes, abordando, entre outros fatores:
como especificar o componente, como instanciar o componente, quais os tipos de conectores e portas disponveis, qual o modelo de dados que entendido por todos os componentes, como os objetos so representados, como as ligaes entre os objetos pertencentes a componentes diferentes so realizadas, como so feitas transaes distribudas, quais so os tipos de interface, as interfaces obrigatrias, como so tratados o catlogo e a localizao dos componentes, o despacho das requisies e respostas, a segurana, o repositrio, o formato, a nomeao, os meta dados, a interoperabilidade, a documentao, os mecanismos de customizao, a composio, a evoluo, o controle de verses, a instalao e a desinstalao, os servios de execuo, o empacotamento, etc.
Marco A. Gerosa
56 / 53
IME / USP
Exemplos de component models

A Microsoft definiu um padro para seus componentes de interface com o usurio (widgets), disponibilizados atravs da linguagem Visual Basic. O modelo introduzido foi o VBX, que posteriormente foi substitudo pelo OCX, pelo ActiveX e depois pelo COM. Atualmente, o modelo de componentes do .NET unifica toda a tecnologia de componentes da Microsoft. A Borland desenvolveu seu prprio modelo de componentes de interface. O CLX (Component Library for Cross Platform) possibilita o desenvolvimento de aplicaes para o Microsoft Windows e para o Linux atravs dos ambientes Kylix, Delphi e C++ Builder. O CORBA (Common Object Request Broker Architecture) fornece um modelo de componentes que possibilita a comunicao entre componentes distribudos. O CORBA utiliza a IDL (Interface Definition Language) para descrever a interface pblica de seus servios. O cliente no dependente da localizao do objeto que est sendo invocado, da linguagem que o mesmo foi programado ou do sistema operacional que est sendo utilizado.
Marco A. Gerosa
57 / 53
IME / USP
Exemplos de component models

Webservices um padro para comunicao entre componentes atravs da tecnologia Web. A aplicao utiliza os servios destes componentes atravs do protocolo SOAP, que encapsula as chamadas dos servios e os retornos em pacotes XML. Enterprise Java Beans o modelo da Sun Microsystems para a interconexo de componentes remotos em aplicaes corporativas. Recentemente a Sun lanou o modelo de componentes para interface com o usurio Java Server Faces (JSF). Tambm recentemente, a Sun Microsystems lanou o modelo Portlets (JSR 168) para a reutilizao de componentes em portais na web. Utilizando este modelo possvel reutilizar um componente desenvolvido para um portal em outro de modo que uma instituio pode montar seu portal buscando ou adquirindo componentes de terceiros.
Marco A. Gerosa
58 / 53
IME / USP
Exemplo de Portlet
Componente: descritor + cdigo que chamado pela infraestrutura de execuo:
Marco A. Gerosa
59 / 53
IME / USP
Component Model Especializados

Os component models genricos no provem um modelo de negcio especfico para um domnio. Ao especializar um component model utiliza-se os servios de infra-estrutura transversais aos diversos domnios e acrescenta-se servios especficos a um determinado domnio. Por exemplo, a Object Management Architecture (OMA), definida pela Object Management Group (OMG), prev CORBAservices, que define a padronizao voltada para servios gerais de sistemas distribudos, enquanto CORBAfacilities define a padronizao dos servios horizontais (comuns a vrios domnios).
Marco A. Gerosa
60 / 53
IME / USP
Infra-estrutura de execuo
Marco A. Gerosa
61 / 53
IME / USP
Container
Um container um software, normalmente desenvolvido por terceiros, com o objetivo de hospedar e gerenciar componentes de um determinado modelo, provendo a eles servios de infra-estrutura de execuo.
O acesso remoto, o gerenciamento de transaes distribudas, o pooling de recursos, o acesso concorrente, o clustering, a tolerncia a falhas, a autenticao, a persistncia, a configurao, o gerenciamento de permisses e de sesso, etc., so exemplos de servios providos por containers
O container libera o desenvolvedor de implementar servios tcnicos de sistema de baixo nvel, direcionando seus esforos para as regras de negcio e para a composio do sistema. Em alguns casos, o uso de container tambm possibilita alterar aspectos no relacionados com a lgica do negcio sem ter que alterar a aplicao, bastando re-configurar o container para alterar aspectos como segurana, permisses, logging, banco de dados, etc.
Marco A. Gerosa
62 / 53
IME / USP
Container
A mquina virtual Java um container para executar componentes Java (arquivos .class ou .jar). Algumas arquiteturas estendem o container para gerenciar componentes mais especializados como servlets ou applets. Outros exemplos de containers: Tomcat, JBoss, Webspheare, Pluto, JetSpeed, etc. O container define uma interface que estabelece a dependncia entre os componentes e ele. Esta interface chamada de lifecycle interface [http://www.adass.org/adass/proceedings/adass03/O8-1/] Esta interface acessada pelo container para gerenciar a inicializao, execuo e desativao do componente.
Marco A. Gerosa
63 / 53
IME / USP
Container
Figure 2: The Container/Component environment.

Component Frameworks
Marco A. Gerosa
65 / 53
IME / USP
Component framework* o conjunto de elementos de software, regras e contratos que governam a execuo de componentes que esto em conformidade com um modelo de componentes [Szyperski, 1997 pg 369]. O component framework define as invariantes e os protocolos de conexo entre os componentes, estabelece as condies ambientais para as instncias dos componentes e regula as interaes entre elas. O component framework normalmente roda no topo do container, juntamente com os componentes. Frameworks de classes e component frameworks so bastante diferentes. Um component framework um conjunto de interfaces e regras de interao que governam como os componentes plugados no framework interagem. * Component Framework equivalente ao conceito de component model implementation definido por [CBSE, pg 7].
Marco A. Gerosa
66 / 53
IME / USP
O component framework segue e d suporte a um modelo de componentes oferecendo uma infra-estrutura para apoiar a sua execuo. O framework fornece uma base para a integrao dinmica dos componentes, at de diferentes fabricantes, de acordo com as necessidades e preferncias dos usurios e desenvolvedores. O component framework oferece servios de runtime como: criao de objetos, gerenciamento de ciclo de vida, persistncia de objetos, licenciamento, acesso a dados, gerenciamento de transaes, balanceamento de cargas, etc. Component frameworks para sistemas distribudos oferecem servios adicionais, como formas de conexo e comunicao remota, notificao de eventos, localizao de servios, segurana, etc. Eventualmente, a interface ou o componente precisam ser registrados no component framework antes de serem utilizados [CBSE, pg 12].
component framework gerencia os componentes, cuidando de seu ciclo de vida:
Instalao e registro dos componentes Inicializao Localizao Liberao Configurao Etc.
O component framework e o componente seguem modelos de componentes compatveis.
Marco A. Gerosa
68 / 53
IME / USP
Component Framework
Marco A. Gerosa
69 / 53
IME / USP
Component Kits
Marco A. Gerosa
70 / 53
IME / USP
Component Kit
Um component kit uma coleo de componentes que foram projetados para trabalhar em conjunto.
Ex: Kit de componentes de GUI (Graphical User Interface) so utilizados para construir interfaces grficas para as aplicaes, fornecendo componentes para botes, formulrios, listas, etc.
De um kit de componentes gera-se uma famlia de aplicaes, fazendo diferentes arranjos e eventualmente desenvolvendo alguns sob medida.
Ex: Component kits com circuitos integrados e componentes eletrnicos. Com os mesmos componentes, pode-se desenvolver circuitos para os mais variados propsitos. Exemplo do Lego.
Um kit de componentes projetado para um component model especfico, o que possibilita a interoperabilidade entre eles. Um kit no necessariamente possui um conjunto fixo de componentes, podendo ser adicionado novos, respeitando a arquitetura definida.
Marco A. Gerosa
71 / 53
IME / USP
Toolkits
Um toolkit um tipo de SDK (Software Development Kit), que apresenta, alm dos componentes, um conjunto de ferramentas para criar aplicaes para uma determinada plataforma, sistema ou framework. Os toolkits so mais comumente encontrados para componentes de interface com o usurio, tambm chamados de widgets. Alguns exemplos de toolkits de widgets para a linguagem Java so o AWT (Abstract Windowing Toolkit), Swing e SWT (Standard Widget Toolkit).
Marco A. Gerosa
72 / 53
IME / USP
Frameworks e Componentes
Software components are building blocks of frameworks [Govoni, 1999].
Marco A. Gerosa
73 / 53
IME / USP
Arquitetura de Software
Marco A. Gerosa
74 / 53
IME / USP
Arquitetura de Software
As conexes entre os componentes abstraem como eles de fato interagem, como por exemplo, chamada de mtodo, compartilhamento de dados, pipes, RPCs (Remote Procedure Calls), sockets, etc. [Clements, 1994]. Apesar da arquitetura ser nica, pode-se fornecer vrias vises sobre ela. Cada viso enfoca um determinado aspecto da arquitetura, omitindo os demais. Algumas vises so mais apropriadas para o desenvolvimento do sistema, outras para o reuso, outras para o teste e implantao.
Marco A. Gerosa
75 / 53
IME / USP
Arquitetura de Aplicao e Tcnica

Duas vises da arquitetura: arquitetura de aplicao e arquitetura tcnica [D'Souza & Wills, 1999].
Na arquitetura de aplicao, a preocupao com a estrutura dos componentes do domnio, representando um projeto lgico de alto nvel independente da tecnologia de suporte. Nesta arquitetura so mostradas a funo de cada componente no contexto do sistema e a interao entre eles. A arquitetura de aplicao consiste de um conjunto de decises sobre a plataforma, um conjunto de component frameworks e os mecanismos de interoperao entre os component frameworks. A arquitetura tcnica considera os detalhes da tecnologia de componentes a ser utilizada e totalmente independente do domnio da aplicao. A arquitetura tcnica retrata as tecnologias de comunicao entre os componentes (TCP/IP, ODBC, etc.), e aspectos referentes escalabilidade e performance.
Marco A. Gerosa
76 / 53
IME / USP
Representao da Arquitetura
Representa-se a arquitetura para facilitar o entendimento, implementao, reuso e evoluo do sistema [Catalysis, pg 483]. Para isto utiliza-se uma ADL (Architecture Description Language). Algumas vantagens do uso de uma descrio formal da arquitetura so:
melhoria da comunicao entre os envolvidos, que passam a contar com uma descrio precisa; pode-se identificar similaridades entre diversas arquiteturas; facilita as decises de projeto, visto que as caractersticas e propriedades das arquiteturas ficam explcitas; facilita a manuteno, dada a documentao e possibilidade de identificar dependncias e inter-relacionamentos.
ADL (Architecture Description Language): Ex: Wright (developed by CMU), Acme (developed by CMU), C2 (developed by UCI), Darwin (developed by Imperial College London)
Marco A. Gerosa
77 / 53
IME / USP

Tecnologias de Reuso

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tecnologias de Reuso

Загружено:

Авторское право:

Доступные форматы

Desenvolvimento de Sistemas Colaborativos

MAC0434 e MAC5798 Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Algumas Formas de Reuso

Desenvolvimento de Sistemas Colaborativos

Em caso do reuso de design:

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento Baseado em Componentes

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Definio de Componente de Software

Para o DBC as caractersticas de projeto so relevantes (reuso, encapsulamento, etc.)

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Caractersticas dos componentes de sw

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Diferenciao com outras tecnologias

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

O que chamar de componente?

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Benefcios e Dificuldades da Componentizao

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento baseado em componentes tambm demanda uma adaptao no processo de desenvolvimento

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Componentes para o usurio final

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

Interfaces Fornecidas e Requeridas

Desenvolvimento de Sistemas Colaborativos

Interfaces Fornecidas e Requeridas

interface fornecida interface requerida

interface fornecida interface requerida

Desenvolvimento de Sistemas Colaborativos

Desenvolvimento de Sistemas Colaborativos

interface fornecida interface requerida

interface fornecida interface requerida

Desenvolvimento de Sistemas Colaborativos