Componentes e Frameworks Alcides Calsavara

Referências Bibliográficas Grant Larsen, Component-Based Enterprise Frameworks, Communications of the ACM, 43(10), pp. 25-26, October 2000. Jon Hopkins, Component Primer, Communications of the ACM, 43(10), pp. 27-30, October 2000. Cris Kobryn, Modeling Components and Frameworks with UML, Communications of the ACM, 43(10), pp. 31-38, October 2000.

Referências Bibliográficas Michael Sparling, Lessons Learned through Six Years of Component-based Development, Communications of the ACM, 43(10), pp. 47-53, October 2000. Clemens Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley, 1998.

Soluções de software: abordagens típicas turnkey solutions prontas para o uso requerem alguma configuração custom development solutions grande parte do sistema é integralmente construída component-based framework solutions abstrações para identificar, discutir, resolver e implementar sistemas implementações parciais extensíveis de forma segura

Exemplos de framework para objetos distribuídos SUN J2EE Microsoft .NET OMG CORBA Specification

Exemplos de Modelos de Componentes SUN Enterprise JavaBeans - EJB Microsoft DCOM (COM+) OMG CORBA Specification

Exemplos de Componentes Componentes GUI (Graphical User Interface) - “widgets” : ActiveX Java Beans Componentes de negócio: objetos CORBA Aplicações inteiras: Excel, PowerPoint

Definição de Grady Booch para Componente “uma parte física e substituível de um sistema que está de acordo com e provê a realização de um conjunto de interfaces”

Definição de Jon Hopkins para componente “Um componente de software é um empacotamento físico de software executável com uma interface pública bem definida.”

Definição de D’Souza e Wills para componente “Um pacote coerente de artefatos de software que podem ser independentemente desenvolvidos e entregues como uma unidade e que pode ser composto, sem modificação, com outros componentes para construir algo maior”

Definição de Szyperski para componente “Um componente de software é uma unidade de composição com interfaces especificadas de forma contratual e com dependências apenas de contexto e explícitas. Um componente de software pode ser distribuído independentemente e fica sujeito a composição por terceiros”

Definição de Michael Sparling para componente Pacote de serviços de software implementado independentemente e netro com relação a linguagem. Distribuído como um contâiner encapsulado e substituível, acessado via uma ou mais interfaces públicas. Pode modificar uma base de dados, mas não deve manter informação de estado. Não é restrito a uma plataforma e nem a uma aplicação.

Definição de Grady Booch para Framework “Um padrão arquitetural que provê um ‘template’ extensível para aplicações dentro de um certo domínio”

Definição de Desmond D’Souza para Framework baseado em Componentes “De maneira geral, um framework baseado em componentes é uma colaboração na qual todos os componentes são especificados através de modelos de tipos; alguns deles podem vir com suas próprias implementações. Para se usar o framework, conectam-se componentes que satisfazem as especificações”

Frameworks & Aplicações Elementos fundamentais Relacionamentos Integridade estrutural e dinâmica Pontos de extensão e modificação

Componentes & Frameworks Cada framework deve prover especificações de pontos de extensão. Em cada ponto de extensão deve ser conectado um componente que seja compatível com a correspondente especificação.

Construção de Frameworks baseados em Componentes Considerar modelos estáticos que ilustram a estrutura dos componentes; Considerar modelos dinâmicos que ilustram a colaboração entre componentes; Considerar a tecnologia que implementa o framework; Considerar o que já se conhece do domínio da aplicação: experiências e tecnologias.

Diretrizes para Sistemas baseados em Componentes Reuso : A habilidade de reusar componentes existentes para criar sistemas mais complexos. Evolução : Um sistema altamente componentizado é de mais fácil manutenção. Em um sistema bem projetado, as alterações serão localizadas, e essas poderão ser feitas no sistema com pouco ou nenhum efeito nos componentes restantes.

Necessidades de um Sistema baseado em Componentes Biblioteca de componentes Modelo de componentes: Montagem Interação “Backplane”: lugar de existência e comunicação entre componentes Processo de desenvolvimento Arquitetura de software

Componentes e Orientação a Objetos Bertrand Meyer: um componente é uma manifestação física de um objeto que tem uma interface bem definida e um conjunto de implementações para esta interface. Um componente não precisa ser desenvolvido através de ferramentas orientadas a objetos. É mais “natural” modelar sistemas usando orientação a objetos quando se tem a perspectiva de componentização do sistema.

Modelo de comunicação entre componentes Mecanismo para que dois componentes se achem e se comuniquem. Modelo de referência para: definição de interfaces passagem de mensagens transferência de dados Tendência: emprego de XML freqüência baixa de trocas de mensagens necessidade de muita semântica nas mensagens

Exemplos de Modelos de Componentes SUN Enterprise JavaBeans - EJB Microsoft DCOM (COM+) OMG CORBA Specification

Componentes e Sistemas Distribuídos Subsistemas fracamente acoplados que, quando agregados, provêem alto poder de comportamento (semântica). Internet tem um mecanismo de transporte "neutro": integra componentes heterogêneos. Troca de informação: XML (Web Services) Troca de mensagens: IP, HTTP, RMI, ...

Granularidade de Componentes Comunicação entre componentes é dispendiosa em termos de tempo e recursos da plataforma de execução. Componentes muito grandes possuem interfaces mais complexas e representam uma oportunidade maior de serem afetados por uma alteração. Quanto maiores os componentes, menor é a flexibilidade do sistema. Equilíbrio é necessário! minimização do acoplamento tende a prejudicar a boa coesão

Exemplos de Componentes Componentes GUI (Graphical User Interface) - “widgets” : ActiveX Java Beans Componentes de negócio: objetos CORBA Aplicações inteiras: Excel, PowerPoint

Lições aprendidas (Michael Sparling) Desenvolvimento baseado em um modelo de referência para componentes Desenvolvimento paralelo Prós e contras de reuso Imutabilidade e componentes Prototipagem cedo e freqüente Gerenciamento de exceções Estratégias de teste diferenciadas