Universidade de Brasília UnB
Faculdade UnB Gama FGA
Curso de Engenharia de Software
Documentação Framework 0MQ.
Autores: Cleiton da Silva Gomes
Hebert Douglas de Almeida
Thiago Silveira Honorato
Vanessa Barbosa Martins
Orientador: Fabricio Braz
Brasília, DF
2014
Sumário
1. Componentes 1.1. Definição 1.2. Modelo de Componentes 1.2.1. Exemplos de Modelos de Componentes 2. Framework 2.1. Definição 2.2. Classificação 2.3. Pontos de Variação 2.3.1. Frozen spots 2.3.2. Hot spots 3. Sobre o ZeroMQ 3.1 Classificação do framework 3.1.1 Classificação quanto ao contexto 3.1.2 Classificação caixa preta/caixa branca 4. Modelo de Estrutura do Framework 4.1 Diagrama de Classes 4.2 Pontos de Variação 4.2.1 Critérios para FrozenSpot 4.2.2 Critérios para HotSpot 4.3 Classes Principais 4.4 Detalhamento de classes 5. Evidências de Hot Spots no protótipo 6. Referências Bibliográficas1. Componentes
1.1. Definição
Um componente de software é um elemento que está em conformidade com um modelo de componentes e pode ser instalado independentemente e composto sem modificações Councill & Heineman (2001, p.7).
O termo componente também é comparado com outros termos e conceitos utilizados no desenvolvimento de software. Para alguns autores um componente de software é qualquer elemento reusável: código binário, código fonte, estruturas de projeto, especificações e documentações (Krueger, 1992).
1.2. Modelo de Componentes
Para obter o reuso e substitutibilidade de componentes de software, eles também
devem ser aderentes a um padrão, que na literatura é chamado de modelo de componentes. Assim como há mais de um padrão para uma tomada, há mais de um modelo para componentes de software. Um programador pode criar seu próprio modelo, eventualmente sendo uma especialização de um modelo disponível. Para compatibilizar componentes de um modelo para outro, adaptadores podem ser desenvolvidos. Councill & Heineman (2001, p.7)
Um modelo de componentes 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 tipos de conectores e portas disponíveis, qual o modelo de dados padrão, 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 tipos 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 metadados, 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. [Councill & Heineman, 2001, p.7, p.11; Weinreich & Sametinger, 2001, p.37;Szyperski,1997, p.32; D’Souza & Wills, 1998, p.396, p.411].
1.2.1. Exemplos de Modelos de Componentes
O OLE(Object Linking and Embedding) é um modelo de componentes proposto pela Microsoft cujo propósito inicial era integrar em um documento objetos gerados por diversas
aplicações. Ao instalar no sistema operacional aplicações compatíveis com o modelo, elastornamse disponíveis para receber e oferecer conteúdos. O editor de documento passa a ser um container que carrega conteúdos disponibilizados pelas demais ligações, como gráficos, sons, vídeo, figuras. Councill & Heineman (2001, p.7)
COM, DCOM e ActiveX são outros modelos de componentes utilizados pela Microsoft que vieram da evolução das idéias do modelo original OLE [Brockschmidt, 1996]. Os modelos oferecem suporte a diversos níveis de complexidade de componentes e possibilitam a integração de aplicações desenvolvidas por diferentes fabricantes. A solução enfoca componentes binários interoperáveis. Councill & Heineman (2001, p.7)
O CORBA(Common Object Request Broker Architecture) fornece um modelo de componentes que possibilita a comunicação entre componentes distribuídos. O CORBA utiliza a IDL (Interface Definition Language) para descrever a interface pública de seus serviços. O cliente não é dependente da localização do objeto que está sendo invocado, da linguagem que o mesmo foi programado ou do sistema operacional que está sendo utilizado. Councill & Heineman (2001, p.7)
Web Services é um padrão para comunicaçãoentre componentes através da web. A aplicação utiliza os serviços dos componentes através do protocolo SOAP, que encapsula as chamadas dos serviços e os retornos em pacotes XML. Councill & Heineman (2001, p.7)
JavaBeans é o modelo básico de componentes da Sun, a partir do qual são feitas diversas extensões. O JavaBeans define como tratar no componente eventos, propriedades, introspecção, reflexão, customização e empacotamento [Szyperski,1997].Enterprise Java Beans é o modelo para a interconexão de componentes remotos em aplicações corporativas.
2. Framework
2.1. Definição
Conforme a complexidade do sistema aumenta, começam a surgir dificuldades para o gerenciamento de todos os arquivos e objetos envolvidos. Fazse necessário o uso de soluções semiprontas, como frameworks, para agilizar e tornar mais rápido o desenvolvimento de projetos.
Os frameworks são soluções que, na maioria dos casos, seguem padrões de projeto bem definidos. Tais padrões permitem que sejam reutilizadas soluções para problemas que outros desenvolvedores já enfrentaram (FIORINI, 2001).
Segundo, Alexandre Leite (Leite, 2014), framework é uma técnica da Orientação a Objetos, voltada para a reutilização que se beneficia de três características das linguagens de programação orientada a objetos: abstração, polimorfismo e herança.
Um framework descreve a arquitetura de um sistema orientado a objetos, os tipos de objetos e as interações entre os mesmos. Ele pode ser vislumbrado como o esqueleto – template – de uma aplicação que pode ser customizado pelo programador e aplicado a um conjunto de aplicações de um mesmo domínio. Com frameworks não se busca apenas reutilizar simples componentes de software, mas subsistemas, aumentando assim o grau de reutilização e contribuindo para uma melhor qualidade do produto – software (Leite, 2014) .
Para (Johnson, 1997), a visão original de reutilização de software estava baseada em componentes. Os frameworks possuem interfaces mais complexas, mas são de mais fácil customização de que os componentes. O autor percebe frameworks e componentes como técnicas diferentes, mas que cooperam entre si, pois um framework pode facilitar a construção de novos componentes e fornecer uma interface padrão para os mesmos trocarem dados, manipularem erros e chamarem operações.
Segundo (Fayad, 1999), a utilização de frameworks apresenta os seguintes benefícios: I. Melhora a modularização – encapsulamento dos detalhes voláteis de implementação através de interfaces estáveis.
II. Aumenta a reutilização – definição de componentes genéricos que podem ser replicados para criar novos sistemas.
III. Extensibilidade – favorecida pelo uso de métodos hooks que permitem que as aplicações estendam interfaces estáveis.
IV. Inversão de controle – IoC – o código do desenvolvedor é chamado pelo código do framework. Dessa forma, o framework controla a estrutura e o fluxo de execução dos programas.
2.2. Classificação
Os frameworks podem ser classificados em caixabranca e caixapreta (Fayad 97) . Os frameworks caixabranca baseiamse nos mecanismos de herança e ligação dinâmica (dynamic binding) presentes em orientação a objetos. Os recursos existentes em um framework caixabranca são reutilizados e estendidos a partir de: herança de classes do framework e sobrecarga (overriding) de métodos "hook" prédefinidos. Métodos "hook" são definidos em interfaces ou classes abstratas e devem necessariamente ser implementados por uma aplicação. Um exemplo de método hook na linguagem Java é o actionPerformed(Action Event e) pertencente à interface ActionListener do framework AWT (Abstract Window Toolkit). Este método é chamado sempre que ocorre um evento ActionEvent correspondendo, por
exemplo, a um clique de botão. Os padrões de projeto (design patterns) utilizados são o Command, o Observer e o Template Method [Gamma 94].
Frameworks caixapreta são baseados em componentes de software. A extensão da arquitetura é feita a partir de interfaces definidas para componentes. Os recursos existentes são reutilizados e estendidos por meio de: definição de um componente adequado a uma interface específica e integração de componentes em um framework que utiliza padrões de projeto como o Strategy (Gamma 94).
Quanto ao contexto de utilização do framework há uma classificação proposta em (Fayad 97), segundo a qual os frameworks são classificados em: "Framework de Infraestrutura de Sistema", "Framework de Integração de Middleware" e "Framework de Aplicação".
Frameworks de infraestrutura de sistema tratam de questões de projeto como sistemas operacionais, comunicação, interfaces gráficas e linguagens de programação. O framework AWT seria classificado como um framework de infraestrutura de sistema.
Frameworks de integração de middleware são responsáveis por integrar aplicações distribuídas e componentes em uma mesma arquitetura. Exemplos de frameworks de middleware são os ORB (Object Request Broker) como o CORBA Common ORB Architecture, e o RMI Remote Method Invocation.
Frameworks de aplicação tratam de questões de projeto de domínios de aplicação, como telecomunicações, finanças, produção e educação.
2.3. Pontos de Variação
2.3.1. Frozen spots
Frozen spots são as partes fixas de um framework, também conhecidos como hook points. São serviços já implementados pelo framework. Normalmente realizam chamadas indiretas aos hotspots (Leite, 2014).
Os frozen spots não foram projetados para adaptação e em um projeto podem ser encontrados sendo as classes concretas e as que seguem alguns padrões de projeto propostos por Gamma, como o método template entre outros. Os frozenspots definem a arquitetura geral de um sistema, ou seja, seus componentes básicos e os relacionamentos entre eles.
2.3.2. Hot spots
Hotspots são as partes flexíveis de um framework. São pontos extensíveis, necessitam de complementação por funcionalidades/serviços que devem ser implementados. (Leite, 2014).
Segundo Alexandre Leite, Hotspots são partes nos quais os programadores que usam o framework adicionam o seu código para especificar uma funcionalidade de sua aplicação. São invocados pelo framework classes (implementadas pelo programador da aplicação) recebem mensagens de uma classe do framework (frozenspot). Isso geralmente é implementado através de herança e de métodos abstratos; (Leite, 2014)
Os pontos de extensão caixa branca são formados por classes incompletas.Ou seja, as classes apresentam apenas a assinatura de seus métodos e precisam que esses métodos sejam implementados na herança.
Nos pontos de extensão caixa preta, as instanciações são feitas por componentes adaptados, e não por herança. Os componentes fazem ligações com as demais partes do framework. Esse ponto de extensão pode ser considerado um conjunto de classes concretas com uma funcionalidade definida e baixo acoplamento em relação aos outros pontos de extensão. O ponto de extensão, nesse caso, já está implementado e, assim, não precisa que sejam feitas adições às suas definições.
3. Sobre o ZeroMQ
0mq é um sistema de mensagens, ou "middleware orientado a mensagem". É usado em ambientes tão diversos como serviços financeiros, desenvolvimento de jogos, sistemas embarcados, pesquisa acadêmica e na área aeroespacial.
Sistemas de mensagens funcionam basicamente como mensagens instantâneas para aplicações. Uma aplicação decide comunicar um evento para outro aplicativo (ou múltiplas aplicações), ele reúne os dados a serem enviados, clicar no botão "enviar" e lá vamos nós, o sistema de mensagens cuida do resto.
Ao contrário de mensagens instantâneas, porém, sistemas de mensagens não têm GUI. 0mq foi originalmente concebido como um sistema de mensagens ultrarápido para a negociação de ações e por isso o foco foi a otimização extrema. O primeiro ano do projeto foi gasto elaboração de metodologia de benchmarking para tentar definir uma arquitetura que fosse o mais eficiente possível.
3.1 Classificação do framework
3.1.1 Classificação quanto ao contexto
O ZeroMQ é um framework de integração de middleware, pois busca prover a troca de mensagens entre componentes de uma determinada aplicação.
3.1.2 Classificação caixa preta/caixa branca
O ZeroMQ é um framework caixa preta, pois o processo de instanciação do framework se apoia em relações de composição entre classes concretas. As relações de composição ficam claras no diagrama de classes abaixo. O que faz com que seus hot spots tenham o perfil de variação caixa preta, pois não se apoiam em herança e sobreescrita de métodos. Para usar o framework basta usar as funcionalidades já prontas, não precisando implementar métodos incompletos. Essa característica torna o framework mais fácil de ser usado em relação a um framework caixa branca, pois não são necessários conhecer detalhes da arquitetura para o uso do framework.
4. Modelo de Estrutura do Framework
4.1 Diagrama de Classes
Imagem 1 Diagrama de Classes do zeroMQ4.2 Pontos de Variação
A partir do diagrama de Classes é possível identificar os pontos de extensão.
4.2.1 Critérios para FrozenSpot
● Ser Classe Mãe (super classe) de alguém. ● Ser Interface ou Classe Abstrata de alguém.
● Ser Composto em uma relação de composição, mas não ser componente de um composto.
4.2.2 Critérios para HotSpot
● Ser subclasse de alguém (relações de herança). ● Ser subclasse de uma classe abstrata (relação de herança). ● Implementar uma interface (relação de dependência). ● Ser componente em uma relação de composição.Podem ser identificadas as seguintes classes como hotspots/frozenspots de acordo com a tabela 1.
Classes HotSpot FrozenSpot É componente Perfil de Variação object_t X não i_poll_events X não array_item_t X não i_writer_events X não i_reader_events X não
socket_base_t X sim caixa preta
session_t X não caixa preta
i_inout X não
own_t X sim caixa preta
io_object_t X sim caixa preta
i_engine_t X
pooller_base_t X sim
reader_t X sim caixa preta
decoder_base_t X não
decoder_t X não caixa preta
io_thread_t X sim caixa preta
pgm_receiver_t X sim caixa preta
zmq_init_t X sim caixa preta
x_rep_t X sim caixa preta
pair_t X sim caixa preta
x_pub_t X sim caixa preta
x_sub_t X sim caixa preta
transient_session_t X sim caixa preta
connect_session_t X sim caixa preta
named_session_t X sim caixa preta
swap_t X não ypipe_t X não signaler_t X não
y_queue_t
X caixa preta Tabela 1: Classificação de pontos de Variação para algumas classes do ZeroMQ4.3 Classes Principais
A tabela 2 evidencia as classes principais do framework zeromq e suas funcionalidades. Classe Função
ctx.cpp A lista de soquetes que foram fechados, mas ainda perduram na memória por causa de mensagens não enviadas é realizada por esta classe.
own.cpp Está ligada ao object, é responsável por controlar a comunicação entre os processos .
command.hpp Ele define todos os comandos disponíveis.
mailbox.cpp É uma fila para armazenar os comandos enviados a qualquer objeto que vivem nessa thread.
socket_base.cpp É usado para a comunicação com o usuário.
decoder_t.cpp É responsável por tratar a decodificação das mensagens.
req_t.cpp É responsável pelas requisições que ocorrem durante as trocas de mensagem. signaler_t.cpp Faz o controle de sinais na comunicação entre os processos. Tabela 2: classes principais do framework zeromq e suas funcionalidades
4.4 Detalhamento de classes
5. Evidências de Hot Spots no protótipo
No protótipo desenvolvido pelo grupo, alguns métodos foram utilizados para que a comunicação entre o cliente e o servidor fosse realizada. Esses métodos são apresentados na tabela a seguir, nela também é evidenciado qual hot spot é exercitado ao se utilizar tal método. A tabela 3 revela o método do zeromq utilizado e o hot spot exercitado. Método do 0MQ usado Hot Spot exercitado zmq_socket() socket_base_t.cpp zmq_ctx_new () zmq.cpp
ZMQ_REQ() req_t.cpp , socket_base_t.cpp zmq_connect() zmq_connecter_t.cpp zmq_recv() zmq.cpp zmq_close() socket_base_t.cpp, zmq.cpp zmq_bind() zmq.cpp zmq_ctx_destroy() zmq.cpp Tabela 3: método e hot spot exercitado.
6. Referências Bibliográficas
Councill, B. & Heineman, G.T. (2001) Definition of a Software Component and Its Elements, in: ComponentBased Software Engineering: Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds), AddisonWesley, ISBN 0201704854.
Krueger, C.W. (1992) Software Reuse, ACM Computing Surveys, Volume 4 Issue 2 p131183.
Weinreich, R. & Sametinger, J. (2001) Component Models and Component Services: Concepts and Principles, in: ComponentBased Software Engineering: Putting the Pieces Together, Hineman, G.T. & Councill, W.T. (eds), AddisonWesley, ISBN 0201704854.
Szyperski, C. (1997) Component Software: Beyond ObjectOriented Programming, AddisonWesley, ISBN 0201178885
D’Souza, D.F. & Wills, A.C. (1998) Objects, Components and Frameworks with UML: The Catalysis Approach. Addison Wesley, ISBN 0201310120, 1998.
Brockschmidt, K. (1996) What OLE Is Really About, MSDN Archive, Microsoft Comporation. msdn.microsoft.com/archive/en
us/dnarolegen/html/msdn_aboutole.asp
LEITE, Alessandro F. Padrões de projetos. Disponível online – http://www.devmedia.com.br/frameworksepadroesdeprojeto/1111 última visita em 21 Junho de 2014.
FIORINI, S. T. Arquitetura para Reutilização de Processos de Software. 2001. Pontifícia Universidade Católica do Rio de Janeiro, Rio de Janeiro.
FAYAD, Mohamed; SCMIDT, Douglas; JOHNSON, Ralph. Building Applications Frameworks. John Willey, 1999.
JOHNSON, Ralph E. Frameworks = (Components + Patterns). Communications of the ACM, Vol. 40. No 10, Outubro 1997, p. 39 – 42.
