UNIVERSIDADE ESTADUAL DO CEARÁ
CENTRO DE CIÊNCIA E TECNOLOGIA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
ANTÔNIO MÁRCIO SOUSA MARTINS
CONCEPÇÃO DE UMA LINGUAGEM DE DEFINIÇÃO DE RELATÓRIOS
BASEADO EM NAKED OBJECTS
FORTALEZA – CEARÁ
2012
ANTÔNIO MÁRCIO SOUSA MARTINS
CONCEPÇÃO DE UMA LINGUAGEM DE DEFINIÇÃO DE RELATÓRIOS
BASEADO EM NAKED OBJECTS
Monografia de apresentada ao Curso de
Ciência da Computação do Centro de Ciência
e Tecnologia da Universidade Estadual do
Ceará, como requisito para obtenção do grau
de Bacharel em Ciência da Computação.
Orientador: Prof. Dra. Mariela Inés Cortés.
Co-orientador: Prof. Me. Marcius Gomes
Brandão.
FORTALEZA – CEARÁ
2012
Dados Internacionais de Catalogação na Publicação
Universidade Estadual do Ceará
Biblioteca Central Prof. Antônio Martins Filho
Bibliotecário Responsável – Francisco Welton Silva Rios – CRB-3/919
M386d
Martins, Antonio Márcio Sousa
Definição de uma linguagem de descrição de relatórios baseados em
NakedObjects / Antonio Márcio Sousa Martins. – 2013.
CD-ROM. 40f. ; il. (algumas color.) : 4 ¾ pol.
“CD-ROM contendo o arquivo no formato PDF do trabalho
acadêmico, acondicionado em caixa de DVD Slim (19 x 14 cm x 7 mm)”.
Monografia (graduação) – Universidade Estadual do Ceará, Centro de
Ciências e Tecnologia, Curso de Ciência da Computação, Fortaleza, 2012.
Orientação: Profa. Dra. Mariela Inês Cortés.
Co-orientação: Prof. Me. Marcius Gomes Brandão.
1. Nakedobjects. 2. Programação orientada a objetos. 3. Linguagem
de descrição de relatórios. I. Título.
CDD: 005.1
AGRADECIMENTOS
Agradeço primeiramente a Deus, que sendo o meu centro, permitiu e me deu toda a sorte de
graças para caminhar na faculdade, lugar em que pude contemplá-lo em outras faces e de
onde vou tirar remas para os próximos dias.
Dedico também essa vitória a meus pais, Maria Auricilene e Antônio Martins, que muito
influenciaram na formação de meu caráter. Não é exagero dizer e são literalmente essas as
palavras: eles deram tudo o que tinham por mim.
Agradeço a meu irmão de sangue, Marcelo, que sempre me inspirou a ser melhor. Agradeço
aos meus irmãos em Cristo, em especial aos pertencentes à Comunidade Católica Shalom, que
confirmaram a minha fé e minha faculdade.
Não me esqueço de meus tios e primos, pois, embora eu tenha me privado de convívio mais
intenso por conta da própria faculdade, sempre me acolheram com muito carinho, chegando
até a não poucas vezes me ajudar financeiramente.
Grato por meus avós que intercedem por mim junto a Deus. Grato por meus avós que
intercedem por mim ainda neste mundo.
Não poderia deixar de passar por meus amigos de curso. Alguns passaram muito rápido,
outros exigem menos para serem lembrados. Obrigado a todos pelos momentos de distração
entre um stress e outro, assim como pela partilha de material e lições de vida.
Professores, muito obrigado. Não apenas pelo conteúdo ministrado, mas por tudo o que me
faz dizer que professor é professor vinte e quatro horas por dia, sete dias por semana.
No fim, agradeço a toda a família DI. Como não citar em meu TCC o nome do professor
Clécio Thomaz, o qual considero meu padrinho. Paulo Aguiar, Wilda Fernandes, Hélio
Moura, Marcos Eduardo, Bruno Garcia, Pablo Nóbrega, Alandson Mendonça, Luanna Falcão,
Francisco Alves e todos que não apenas me ofereceram uma oportunidade, mas sua sincera
amizade. De uma maneira especial, agradeço a Marcius Brandão, que muito contribuiu para
minha formação e inspirou esse trabalho.
Combati o bom combate, terminei a minha
carreira, guardei a fé.
São Paulo Apóstolo
II Tim 4,7
RESUMO
Relatórios são ferramentas úteis para apresentar informações, sejam elas conclusões ou
apenas o levantamento de uma situação. Assim, relatórios comumente passam a ser
ferramentas-chave no processo de comunicação e tomada de decisão em ambientes
corporativos de qualquer natureza ou estatura. Por conta disso, principalmente tratando-se de
grandes organizações, observa-se a demanda de um considerável número de relatórios
diferentes, o que abre uma demanda para a obtenção de um meio a partir do qual, não
importando a complexidade dos relatórios, sejam esses criados rapidamente e dentro de um
padrão de qualidade, levando em conta facilidades para a edição e formatação desses
relatórios. Atualmente, o mercado oferece diversas ferramentas que proporcionam
considerável agilidade e eficácia aos desenvolvedores na tarefa de criar e manter relatórios,
porém, ainda é possível melhorar essas ferramentas ou mesmo criar outras mais eficientes. O
presente esforço vem oferecer a Naked Objects Report Language (NORL), que é uma
linguagem concebida para a descrição de layout de relatórios a ser absorvida por frameworks
baseados em Naked Objects para desenvolvimento de softwares. A ideia é dar suporte à
criação de relatórios como uma responsabilidade de frameworks baseados em Naked Objects,
que passam a ser capazes de criar automaticamente os relatórios, cabendo ao desenvolvedor
apenas descrever o layout dos relatórios, que serão criados automaticamente.
Palavras-chave: Naked objects; Programação orientada a objetos; Linguagem de descrição
de relatórios.
ABSTRACT
Reports are useful tools for presenting information, whether conclusions or just lifting a
situation. Thus, reports commonly become key tools in the process of communication and
decision making in corporate environments of any nature or stature. Because of that,
especially in the case of large organizations, there is a demand for a considerable number of
different reports, which opens a demand for obtaining a medium from which, no matter the
complexity of the reports, these are created quickly and within a quality standard, taking into
account facilities for editing and formatting of these reports. Currently, the market offers
several tools that provide significant speed and efficiency to developers in the task of creating
and maintaining reports, however, it is still possible to improve these tools, or even create
more efficient ones. This effort has to offer Naked Objects Report Language (NORL), which
is a language designed to describe the layout of reports to be absorbed by Naked Objects
based frameworks for software development. The idea is to support the creation of reports as
a liability based frameworks Naked Objects, which are then able to automatically create
reports, leaving the developer only describe the layout of the reports, which will be created
automatically.
Keywords: Naked objects; Object-oriented programming; Description language reports.
LISTA DE FIGURAS
Figura 1–
Arquitetura do padrão MCV........................................................................... 16
Figura 2–
Exemplo de tabela de um relatório plano....................................................... 17
Figura 3–
Ilustração da operação média.......................................................................... 18
Figura 4–
Exemplo de tabela em relatório de referência cruzada................................... 18
Figura 5 –
Ilustração de operação em relatório de referencia cruzada............................. 19
Figura 6–
Relatório de duas colunas............................................................................... 19
Figura 7–
Descrição da tela de produtos do restaurante................................................. 23
Figura 8–
Tela de produtos do restaurante..................................................................... 24
Figura 9 –
Diagrama do termo digit................................................................................. 26
Figura 10 –
Diagrama do termo number............................................................................ 26
Figura 11 –
Diagrama do termo character......................................................................... 27
Figura 12 –
Diagrama do termo atribute............................................................................ 27
Figura 13 –
Diagrama do termooperation_descriptor...................................................... 28
Figura 14 –
Diagrama do termo operation......................................................................... 28
Figura 15 –
O diagrama do elemento field_table............................................................... 29
Figura 16 –
Diagrama do termo table................................................................................ 29
Figura 17 –
Diagrama do termo cross_table...................................................................... 30
Figura 18 –
Diagrama do termo list....................................................................................31
Figura 19 –
Diagrama que descreve o termo detail............................................................ 31
Figura 20 –
Diagrama do termo layout.............................................................................. 32
Figura 21 –
Modelagem do domínio fictício...................................................................... 33
Figura 22 –
Exemplo de um relatório plano descrito em NORL....................................... 34
Figura 23 –
Exemplo de um relatório de referência cruzada descrito em NORL............. 35
Figura 24 –
Exemplo de um relatório com lista descrito em NORL................................. 36
Figura 25 –
Exemplo de um relatório de múltiplas colunas descrito em NORL............... 37
SUMÁRIO
1
INTRODUÇÃO...................................................................................................... 11
1.1
MOTIVAÇÃO.......................................................................................................... 11
1.2
OBJETIVOS............................................................................................................. 12
1.2.1
Geral........................................................................................................................ 12
1.2.2
Específicos............................................................................................................... 12
1.3
ESTRUTURA DESSE TRABALHO....................................................................... 13
2
FUNDAMENTAÇÃO TEÓRICA........................................................................ 14
2.1
NAKED OBJECTS.................................................................................................... 14
2.2
FRAMEWORKS........................................................................................................ 14
2.3
MVC......................................................................................................................... 15
2.4
RELATÓRIOS......................................................................................................... 16
2.4.1
Tipos de relatório.................................................................................................... 17
2.4.1.1 Relatórios planos...................................................................................................... 17
2.4.1.2 Relatório de referência cruzada................................................................................ 18
2.4.2
Relatórios com várias colunas............................................................................... 19
2.5
METALINGUAGEM EXTENDED BACKUS-NOUR FORM (EBNF)................... 19
3
TRABALHOS RELACIONADOS....................................................................... 22
3.1
FERRAMENTAS PARA CRIAÇÃO DE RELATÓRIOS...................................... 22
3.2
ENTITIES E LLE...................................................................................................... 23
4
DESCRIÇÃO DA LINGUAGEM DE DEFINIÇÃO DE RELATÓRIOS........ 25
4.1
DESCRIÇÃO DA LINGUAGEM NORL................................................................ 25
4.1.1
Digit.......................................................................................................................... 25
4.1.2
Number.................................................................................................................... 26
4.1.3
Character..................................................................................................................27
4.1.4
Attribute....................................................................................................................27
4.1.5
Operation_descriptor............................................................................................... 27
4.1.6
Operation................................................................................................................. 28
4.1.7
Field_table............................................................................................................... 29
4.1.8
Table......................................................................................................................... 29
4.1.9
Cross_table............................................................................................................... 30
4.1.10
List............................................................................................................................ 30
4.1.11
Detail........................................................................................................................ 31
4.1.12
Layout...................................................................................................................... 31
5
ESTUDO DE CASO DE LAYOUTS DESCRITOS EM NORL......................... 33
5.1
PROTÓTIPOS DE DEFINIÇÃO DE UM RELATÓRIO PLANO........................ 33
5.2
PROTÓTIPO DA DEFINIÇÃO DE UM RELATÓRIO COM REFERÊNCIA
CRUZADA.............................................................................................................. 34
5. 3
PROTÓTIPO DA DESCRIÇÃO DE UM RELATÓRIO COM LISTA................. 35
5.4
PROTÓTIPO DA DESCRIÇÃO DE UM RELATÓRIO DE MÚLTIPLAS
COLUNAS.............................................................................................................. 36
6
CONCLUSÃO E TRABALHOS FUTUROS...................................................... 38
REFERÊNCIAS..................................................................................................... 39
11
1 INTRODUÇÃO
A cada dia que passa, a ciência avança e consegue oferecer mais recursos
tecnológicos à sociedade. Em resposta, a sociedade espera por novidades tecnológicas que
não apenas facilitem o trabalho e multipliquem o lazer, mas que também otimizem a
utilização de recursos, sejam eles tempo, mão-de-obra ou qualquer outro (PIRRO, 2008).
Nesse contexto, percebe-se que o desenvolvimento de softwares tem destaque.
Um número expressivo de organizações procuram adquirir softwares, para aumentara
eficiência ao realizar atividades ou mesmo tornar a execução dessas tarefas possível.
Dentre essas tarefas, a elaboração de relatórios é muito comum, pois o
levantamento e avaliação de informações devidamente ordenadas geralmente é um fator
importante no processo de tomada de decisão. Porém, à medida que determinada organização
exige do software uma maior quantidade de relatórios diferentes, levanta-se o problema da
criação manualde relatórios.
Acriação manual de relatórios tende a ser um fator que agrega complexidade e
queda de qualidade aos softwares, pois, por si só, não promove padronização, agilidade
eflexibilidade para aderir a mudanças de requisitos. Não o bastante, por estar
fortementeligado à habilidade do desenvolvedor, todo o processo terá maior propensão à
falhas e será mais difícil mensurar o tempo necessário para concluir a tarefa de programar ou
dar manutenção à geração de relatórios.
Procurando minimizar esse problema, o presente trabalho vem propor uma
linguagem de definição de layoutde relatóriosa partir da qual o processo possa ser
automatizado através de uma ferramenta para frameworks de desenvolvimento de softwares
baseado em Naked Objects (PAWSON, 2004).
1.1 MOTIVAÇÃO
A demanda por softwares cresceu nos últimos anos e o mercado está aquecido
(INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2011). Muitas
organizações corporativas têm procurado sistemas computacionais adequados para otimizar o
andamento de suas diversas tarefas, dentre elas, a criação de relatórios, a qual é o foco desse
trabalho.
Considerando esses fatos, é preciso pensar não só em aumentar o número de
desenvolvedores encarregados da criação de relatórios, mastambém tornar mais eficiente o
12
trabalho desses no que diz respeito à promoção de padronização, confiabilidade, agilidade no
processo de desenvolvimento e, dentre mais pontos, flexibilidade para acomodar mudanças
nas regras de negócio.
Algo que pode promover essa maior eficiência da equipe de desenvolvimento na
tarefa de criar relatórios é a disponibilização de adequadas ferramentas de trabalho. Há muitas
ferramentas no mercado que se propõem a colaborar na criação de relatórios como iReport
(TOFFOLI, 2002), BIRT (THE ECLIPSE FOUNDATION, 2011) e outras, mas nenhuma
delas o resolve os problemas aderentes a criação manual de relatórios de maneira satisfatória.
Desse modo, contribuir para o aperfeiçoamento das ferramentas dedicadas a
criação de relatórios é algo significante.
1.2 OBJETIVOS
1.2.1 Geral
Há uma grande diversidade de frameworks no mercado, atendendo às equipes de
desenvolvimento nas mais variadas necessidades, tais como: aplicação de padrões de projeto,
garantia de compatibilidade entre diferentes plataformas, etc.
A contribuição desse trabalho para o avanço na área de desenvolvimento de
sistemas consiste em oferecer base para o aperfeiçoamento de frameworks de
desenvolvimento de softwares baseados em Naked Objects (PAWSON, 2004), a exemplo do
framework Entities (ENTITIES framework, 2010). No presente trabalho encontram-se uma
contribuição para o aprimoramento desses frameworks no que diz à agregação
dafuncionalidade decriação de relatórios.
1.2.2 Específicos
Entre os objetivos específicos do presente trabalho tem-se:
 Definição da sintaxe da linguagem de definição de relatórios Naked Objects
Report Language (NORL);
 Ilustração do uso da linguagem para a geração de relatórios a partir de layouts
exemplo.
13
1.3 ESTRUTURA DESSE TRABALHO
Os capítulos a seguir são estruturados da seguinte forma. O capítulo 2 traz toda a
fundamentação teórica necessária ao entendimento do problema e da solução em questão. Na
seção 2.1 vê-se Naked Objects. A seção 2.2 define frameworks, seguida da Seção 2.3, que
apresenta o padrão arquitetural Model View Controller (MVC). A seção 2.4 expõe a natureza
dos relatórios e, então, a seção 2.5 mostrar a meta-linguagem Extended Backus-Naur Form
(EBNF). No terceiro capítulo encontra-se os trabalhos relacionados. A seção 3.1 trata de
algumas ferramentas oferecidas pelo mercado para criação de relatórios, a seção 3.2 trata do
framework Entities e da Linguagem de Layout Entities (LLE). O quarto capítulo contem a
contribuição proposta, que é a descrição da linguagem de definição de layout de relatórios. A
seção 4.1 apresenta uma família de anotações necessárias à manipulação da linguagem
proposta e a seção 4.2 apresenta essa linguagem. O capítulo cinco traz estudos de caso. Por
fim, o Capítulo seis dá a conclusão do trabalho epropõe trabalhos futuros.
14
2 FUNDAMENTAÇÃO TEÓRICA
2.1 NAKED OBJECTS
Basicamente, o conceito de Naked Objects afirma que, escrevendo o aplicativo do
negócio, o desenvolvedor deve criar somente os objetos de negócio que modelam o domínio
(Naked Objects) e suas lógicas de negócio encapsuladas (PAWSON, 2004).
Neste cenário, o ambiente é projetado de forma a deixar claro para o usuário os
objetos que estão sendo manipulados e também as ações que estão sendo executadas, como
por exemplo, a execução de algum método de um objeto, a edição dos valores das
propriedades desse, chegando até a sua criação e destruição. Os objetos provenientes das
entidades definidas em Naked Objects possuem todos os métodos que concretizam o seu
comportamento (PAWSON, 2004).
O maior benefício de se desenvolver usando Naked Objects é o fato de que o
esforço fica concentrado na camada de domínio, ou seja, na definição das entidades. Isso
porque, a partir da definição das entidades, o framework utilizado para aplicação da
metodologia de Naked Objects se torna responsável por implementar as outras camadas como
a de persistência, visão, validação e as demais.Isso é possível porque muitos dos serviços
requeridos pela camada de negócio podem ser implementados de forma genérica. Porém, os
frameworks podem ser enriquecidos com mecanismos de forma a permitir alguma
customização na camada de acordo com as necessidades (PAWSON, 2004).
Pawson (2004) destaca ainda outros benefícios adquiridos com a utilização de
Naked Objects, como por exemplo, ganha-se flexibilidade para atender a mudanças nos
requisitos de negócio, melhora-se a comunicação entre desenvolvedores e usuários e, além
disso, acelera-se o processo de desenvolvimento.
Por outro lado, Naked Objects apresenta desvantagens no que diz respeito às
interfaces gráficas geradas, pois o layout das mesmas não podem ser customizadas e temos
apenas uma visão para cada modelo (PAWSON, 2004).
2.2 FRAMEWORKS
O termo framework está presente em outras áreas do conhecimento além da
Ciência da Computação. Fazendo uma análise etimológica da palavra framework temos o
termo “frame” que significa quadro ou estrutura e o termo “work” que, por sua vez, significa
15
trabalho. Assim, em uma definição simplista, diremos que framework é uma estrutura abstrata
de trabalho (FERREIRA, 2010).
Em desenvolvimento de software, entende-se um framework como um conjunto
de classes que resolvem determinado problema comum ao desenvolvimento de sistemas
diferentes, porém, dentro de um domínio específico. Geralmente avalia-se a necessidade de
criar ou não um framework de acordo com o nível de intercessão de uma atividade (aplicação)
para outra (FAYAD, 1997).
Uma vez implementados de forma genérica, os frameworks precisam ser
configurados segundo a necessidade da aplicação durante a fase de implementação do
software, podendo então atender por completo a um requisito para um domínio específico
(FAYAD, 1997).
Vale dizer também que, diferente de uma biblioteca, o framework determina o
fluxo de controle da aplicação fazendo uso de um mecanismo conhecido comoinversão de
controle (FAYAD, 1997).
2.3 MVC
O padrão Model-View-Controller (MVC) é utilizado para separar as atribuições
das camadas do software, permitindo que cada uma delas se preocupe apenas com as suas
próprias designações (FOWLER; RICE; FOEMMEL, 2003).
No modelo MVC, a camada modelo (Model) é responsável pelas regras de
negócio que modificam e gerenciam o acesso aos dados, que o próprio modelo representa. O
modelo também fornece ao controlador meios de acessar as funcionalidades da aplicação,
mantendo o estado persistente do negócio (PAWSON, 2004).
Por outro lado, a camada de visualização (View) reflete uma parcela ou a totalidade
do modelo de forma legível ao usuário do software. Essa camada envia mensagens ao modelo
por meio da camada de controle, originando eventos que modificarão o estado do modelo. Por
sua vez, quando o modelo é modificado, sempre notifica as visões que dele dependem, através
do estabelecimento de um protocolo de inscrição/notificação (PAWSON, 2004).
Finalmente o controlador (Controller), interpreta as ações do usuário e as mapeia
para chamadas ao modelo, definindo o fluxo da aplicação. A partir das ações do usuário e da
resposta do modelo, o controlador ativa processos de negócios, altera estado do modelo e,
além disso, seleciona a visualização a ser exibida (PAWSON, 2004).A figura abaixo ilustra o
relacionamento entre as camadas do MVC.
16
Figura 1 – Arquitetura do padrão MCV
Fonte: Fowler, Rice e Foemmel (2003).
2.4 RELATÓRIOS
Segundo o dicionário de língua portuguesa,relatório pode ser definido como a
exposição e relação dos principais fatos colhidos por uma comissão ou pessoa encarregada de
estudar determinado assunto (FERREIRA, 1986).
Pode-se considerar também a definição do Michaelis Moderno Dicionário da
Língua Portuguesa: “Qualquer exposição pormenorizada de circunstâncias, fatos ou objetos.
R. em coluna, Inform: forma de visualização dos dados em colunas, em que cada coluna é um
campo de um registro, e cada linha, um registro separado” (WEISZFLOG, 2004).
Como é muito comum os relatórios terem caráter oficial ou mesmo pela simples
possibilidade de terem alto valor no apoio a tomada de decisões, é aconselhável que cada
instituição adote padrões para formato seus relatórios. Nesse padrão são descritas informações
tais como fonte, alinhamento, conteúdo de cabeçalho, estilo de numeração de página etc.
A padronização torna os relatórios mais legíveis, assegura a qualidade dos
documentos e contribui na caracterização da face da instituição frente ao cliente e também
internamente. No entanto, a flexibilidade na construção do layout dos relatórios pode ser
importante em uma situação específica, ou em algum caso, a padronização pode não ser uma
política da instituição.
Quanto ao grau de dificuldade da construção dos relatórios, esta pode ser
medida levando em conta a diversidade de dados a serem apresentados. Além disso, a
complexidade e amplitude do assunto abordado pode também influenciar. Em muitos casos,
são usados sub-relatórios para tornar mais simples a construção de relatórios complexos
(PEOPLESOFT, 2003).
17
2.4.1 Tipos de relatório
A literatura descreve muitos tipos de relatórios. Nesse trabalho, os esforços foram
concentrados sobre aqueles mais comumente empregados (PEOPLESOFT, 2003; OFFICE,
2011; SQLSERVER, 2011).
2.4.1.1 Relatórios planos
São relatórios em que as informações são dispostas em uma tabela, onde cada
coluna traz os valores de uma determinada variável e cada linha da mesma representa um
registro.
A partir daí, muitas vezes identifica-se a necessidade de agrupar os dados de
acordo com um ou mais campos, sendo que cada um desses define um nível de agrupamento.
Além de agrupar, é comum classificar em ordem crescente ou decrescente a
disposição dos registros segundo um ou mais campos, sendo necessário definir a prioridade
desses campos, caso sejam mais de um.
Para melhor ilustrar, abaixo é exposta uma figura representando um relatório
plano. A primeira coluna traz as matrículas dos alunos, a segunda vem com as disciplinas e a
terceira com as situações dos alunos nas disciplinas.
Figura 2 – Exemplo de tabela de um relatório plano
18
Por último, valedizer que se pode efetuar operações com os dados de cada coluna.
Exemplos de operações são: soma, média, variância, mínimo, etc. Abaixo temos um figura
que ilustra a operação média, aplicada sobre as notas do aluno.
Figura 3 – Ilustração da operação média
2.4.1.2 Relatório de referência cruzada
Relatórios de referência cruzada conseguem expor de maneira simples, compacta
e legível os dados de um determinado campo que diz respeito, simultaneamente, a dois outros
campos do mesmo registro. Ou seja, um relatório de referência cruzada é uma tabela em que
os títulos das colunas indicam os valores de um campo e os títulos das linhas se referem aos
valores de outro campo. Por fim, os valores das células da tabela são valores do campo que
estamos relacionando com os campos que estão fazendo as linhas e colunas.
Para dar um exemplo e comprovar a utilidade de referências cruzadas, a tabela do
tópico anterior (2.4.1.1) foi reconstruída para caracterizar um relatório de referência cruzada
para obter a situação dos alunos de acordo com sua matrícula e disciplina (Figura 4).
Figura 4 – Exemplo de tabela em relatório de referência cruzada
Fazendo comparação com o relatório plano, o relatório de referência cruzada é bem
mais eficiente, uma vez que torna as informações mais legíveis e ocupa menor volume de
espaço. Da mesma forma que relatórios planos, é possível classificar e executar operações com
os dados das linhas e colunas, como ilustrado na figura abaixo, onde temos um relatório de
referência cruzada expondo a quantidade de alunos aprovadose reprovados em cada disciplina.
19
Figura 5 – Ilustração de operação em relatório de referencia cruzada
2.4.2 Relatórios com várias colunas
No termo “Relatório com Várias Colunas”, a palavra “colunas” tem um sentido
diferente do que teria no termo “coluna da tabela”. O layout de um relatório de várias colunas
é semelhante ao de um jornal. Normalmente, relatórios têm uma só coluna, enquanto jornais
têm várias colunas. Para deixar mais claro, a figura abaixo ilustra um recorte de jornal, que
pode ser visto como um relatório de duas colunas.
Figura 6 – Relatório de duas colunas
Fonte: O Povo (2011).
Concluindo, esse tipo de relatório é comumente usado para criar etiquetas, porém,
é possível acomodar qualquer tipo de relatório dentro de um relatório de várias colunas,
considerando como se cada coluna fosse uma página.
2.5 METALINGUAGEM EXTENDED BACKUS-NOUR FORM (EBNF)
Em computação, EBNF é uma família de notações meta-sintáticas criadas para
descreverem linguagens livres de contexto. Por exemplo, pode-se recorrer a EBNF para
descrever a sintaxe de uma linguagem de programação. Extended Backus-Nour From (EBNF),
20
definida no padrão ISO/IEC 14977, é uma extensão da Backus-Nour From (BNF). No presente
trabalho, a EBNF será empregada para definir a sintaxe da linguagem de definição de relatórios
aqui proposta. A seguir, há dois quadros listando os meta-caracteres da EBNF:
Quadro 1 – Meta-caracteres EBNF em ordem decrescente de precedência
Meta-caracteres em ordem decrescente de precedência
*
Repetição
Exceção
,
Concatenação
|
Escolha
=
Definição
;
Terminação
Quadro 2 – Meta-caracteres EBNF de agrupamento e quebra de precedência
Meta-caractere de agrupamento e quebra de precedência
[...]
Opcional
{...}
Repetição (zero ou mais)
(...)
Agrupamento
“...”
Cotação dupla
„...‟
Cotação simples
(*...*)
Comentário
?...?
Definição especial (simples)
Basicamente, a EBNF define regras de construção da seguinte maneira:
Identificador_da_regra = definição_da_regra ;
Identificadores, que são termos não-terminais (variável), podem ser definidos com
mais de uma palavra separadas por espaço, porém, pelo menos nesse trabalho, evitar-se-á
escrever assim para conservar a legibilidade.
Os símbolos terminais, que são uma sequência de um ou mais caracteres que
formam uma unidade irredutível da linguagem, ficam entre aspas ou apóstrofes e são os
elementos marcadores das linguagens definidas em EBNF. Como exemplo, verifica-se a
definição dos números inteiros:
numeros_nao_nulos =
"1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
numeros = "0" | numeros_nao_nulos ;
integer = [ "-" , numeros ] , {numeros} ;
21
A maioria dos padrões de linguagem de programação usa alguma variante da
EBNF para definir a gramática da língua, possibilitando a construção de compiladores, uma
vez que o analisador para o compilador pode ser gerado automaticamente com um gerador de
analisador sintático como YACC.
22
3 TRABALHOS RELACIONADOS
3.1 FERRAMENTAS PARA CRIAÇÃO DE RELATÓRIOS
O mercado oferece muitas ferramentas às quais desenvolvedores podem recorrer
quando incumbidos da tarefa de criar relatórios. IReport (TOFFOLI, 2002) é um programa
open sourcecriado para ajudar os desenvolvedores a criar relatórios usando a biblioteca Jasper
Report. Seus códigos fontes sãodistribuídos gratuitamente segundo a licença General Public
License (GNU).
Contando com uma interface gráficaintuitiva, o desenvolvedor se vê capaz de
criar relatórios de variados modelos para aplicações Java. O iReport, já atualmente em sua
versão 4.5.0, pode ser considerada uma ferramenta madura.
Outra ferramenta vocacionada à tarefa de criação de relatórios é o BIRT (THE
ECLIPSE FOUNDATION, 2011), um projeto sem fins lucrativos dentro da Eclipse
Foundation, sendo um sistema de código aberto. Baseado no Eclipse, esta voltado para
aplicações web, dando especial suporte as baseadas em Java e J2EE.
BIRT tem dois componentes principais. O primeiro deles é o designer de
relatórios que se encontra dentro da IDE Eclipse, onde se cria os relatórios. O segundo
componente é responsável pela geração dos relatórios em tempo de execução, podendo ser
implantado no servidor de aplicação e em qualquer ambiente Java. Atualmente, BIRD está na
versão 3.7.2 e já é capaz de criar relatórios bem elaborados.
Porém, ambas ferramentas possuem como principal limitação ao uso o fato de que
a qualidade dos produtosgerados depende em muito da habilidade do desenvolvedor, o que
compromete significativamente o aspecto de confiabilidade do produto.
As ferramentas acima também não facilitama incorporação das adaptações
necessárias por conta de mudanças de requisitos, embora um desenvolvedor experiente
consiga criar relatórios de forma relativamente ágil, se considerarmos o tempo necessário para
desenvolver os mesmos relatórios sem nenhuma ferramenta semelhante. Assim como iReport
e BIRD, há outros projetos como Quick Report, Cristal Report e outros, porém compartilham
limitações similares.
Concluindo, mesmo que todas essas ferramentas tenham representado um grande
avanço no tratamento do problema da criação de relatórios, ainda há muito a fazer para se
garantir eficiência no processo.
23
3.2 ENTITIES E LLE
Entities (ENTITIES framework, 2010)é um framework Java que, sendo baseado
em Naked Objects, tem como finalidade gerar a camada de interface gráfica a partir da
camada de negócio, simplificando o processo de desenvolvimento, contribuindo para a
qualidade do software e sua produção em curto espaço de tempo.
A Linguagem de Layout Entities (LLE) foi criada especialmente para ser usada no
desenvolvimento com o framework Entities (ENTITIES framework, 2010).Na concepção do
Entities, quando se pensou em prover a customização das telas dos sistemas, descartou-se a
ideia de utilizar estruturas sofisticadas como as de XML. Em lugar disso, e com foco em obter
a simplicidade para a rápida implementação e interpretação da parte do desenvolvedor foi
concebida uma linguagem de layout que simplesmente faz uso de texto simples (String).
O framework Entities utiliza da LLE para descrever o layout das telas usadas para
expor objetos ao usuário, segundo o conceito de Naked Objects. Para que fique mais claro o
funcionamento da LLE, a figura abaixo apresenta o exemplo da descrição de uma tela a partir
da LLE. Essa telaseria o ambiente de cadastro e manutenção de produtos utilizados em um
restaurante:
Figura 7 – Descrição da tela de produtos do restaurante
24
A partir dessa descrição encontrada na entidade, o Entities gera a seguinte tela:
Figura 8 – Tela de produtos do restaurante
Considerando que o framework Entities ainda não possui um mecanismo
automatizado para a geração de relatórios, e tendo em vista as deficiências detectadas em
outras ferramentas para a geração de relatórios, este trabalho visa contribuir no sentido
depropor uma linguagem que defina relatórios, similarmente a como a LLE define as telas dos
sistemas Entities.
25
4 DESCRIÇÃO DA LINGUAGEM DE DEFINIÇÃO DE RELATÓRIOS
No presente capítulo é apresentada a linguagem de definição de relatórios, que
recebeu o nome de Naked Objects Report Linguage (NORL).
Durante o processo de desenvolvimento da NORL,optou-se por conceber uma
linguagem que usasse de texto simples (String) para descrever layouts.
Frameworks baseados em Naked Objects conseguem identificar as propriedades
dos objetos de modelo, o que garante a seleção acertada dos componentes visuais que as
representarão na interface apresentada ao usuário. Assim, uma vez que NORL possui total
aderência à metodologia do Naked Object, ela é capaz de levar o framework a expor os
objetos aos usuários em formato de relatórios, seguindo uma estratégia semelhante a da LLE
(seção 3.2), ao expor os objetos aos usuários em formato detelas.
4.1 DESCRIÇÃO DA LINGUAGEM NORL
A seguir, a linguagem NORL é descrita segundo a notação EBNF. Convém dizer
que os diagramas que a frente ilustram da linguagem foram criados utilizando-se do sistema
Railroad Diagram Generator (RADEMACHER, 2013).
4.1.1 Digit
Digit é o termo que representa um digito.
digit = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' |
'8' | '9' ;
Segue o diagrama do termo digit:
26
Figura 9 – Diagrama do termo digit
4.1.2 Number
Para representar um número, temos o termo number.
number = digit , {digit} ;
O diagrama abaixo descreve o termonumber:
Figura 10 – Diagrama do termo number
27
4.1.3 Character
Character agrega qualquer caractere apresentável.
character = ? Qualquer caractere apresentável ? ;
O diagrama de character está logo abaixo:
Figura 11 – Diagrama do termo character
4.1.4 Attribute
O attribute agrega qualquer conjunto de caracteres apresentáveis ao layout
referente a um atributo da entidade que o acomoda.
attribute = character , { character } ;
A seguir temos o diagrama de attribute:
Figura 12 – Diagrama do termo attribute
4.1.5 Operation_descriptor
O termo operation_descriptor sinaliza qualquer uma das operações suportadas,
como soma, média, variância etc.
operation_descriptor = 'COUNT' | 'DISTINCT_COUNT' | 'SUM'
| 'AVERAGE' | 'LOWEST' | 'HIGHEST' | 'STANDARD_DEVIATION'
| 'VARIANCE' ;
28
A lista das operações suportadas poderá mudar de acordo com as necessidades e
disposições da equipe que implementar a máquina de criar relatórios.
Agora temos o diagrama do termo operation_descriptor:
Figura 13 – Diagrama do termo operation_descriptor
4.1.6 Operation
O termo operationsinaliza qualquer uma das operações suportadas especificando
as colunas a serem computadas com o termo attribute.
operation = operation_descriptor ,
'(' , attribute , { ',' , attribute } , ')' ;
Odiagrama de operation vem a seguir:
Figura 14 – Diagrama do termo operation
29
4.1.7 Field_table
Field_table define as colunas de uma tabela simples com o termo attribute, ou
seja, define os dados que serão visualizados na coluna e, além disso, o título da coluna.
field_table = attribute , { ',' , attribute } ;
O diagrama do elemento field_table vem a seguir:
Figura 15 – O diagrama do elemento field_table
4.1.8 Table
Table contem a descrição de uma tabela simples.
Os termos HORIZONTAL e VERTICAL definem a disposição horizontal ou vertical
dos objetos na tabela, sendo opcionais, pois deverá ser adotado um deles como valor default.
Os termos operationefield_table descrevem a tabela segundo sua atribuição, como
explicado nas secções 4.1.6 e 4.1.7 respectivamente.
table = '[' , [ 'HORIZONTAL' | 'VERTICAL' ] ,
'[' , field_table , ']' ,
[ operation , { ',' , operation } ] ']' ;
O digrama a seguir descreve o termo table:
Figura 16 – Diagrama do termo table
30
4.1.9 Cross_table
Cross_table define uma tabela de referência cruzada.
Como em table, os termos operatione field_table descrevem a tabela segundo sua
atribuição, como explicado nas secções 4.1.6 e 4.1.7, respectivamente.
cross_table = ‘[’ , '[' field_table ']' , 'x' , '['
field_table ']' , 'x' '[' field_table ']' ,
[ operation , { ‘,’ , operation } ] , ‘]’ ;
A seguir, temos o diagrama do termo cross_table:
Figura 17 – Diagrama do termo cross_table
4.1.10 List
List descreve em formato de lista uma lista pertencente à entidade que o acomoda.
Pode-se definir uma lista numérica com o termo NUMBER ou uma lista com
marcadores com o termo MARKER, mas esses são opcionais, cabendo definir um valor
default.
O termo attribute descreve os itens a serem listados.
List = ‘<’ , attribute , [ ';' , 'NUMBER' | 'MARKER' ] '>'
;
O diagrama a seguir descreve o termo list:
31
Figura 18 – Diagrama do termo list
4.1.11 Detail
Detail define a exata disposição dos dados em forma de lista (list), tabela simples
(table) ou tabela de referência cruzada (cross_table).
detail = [ list | table | cross_table ] ;
Abaixo temos o diagrama que descreve o termo datail:
Figura 19 – Diagrama que descreve o termo detail
4.1.12 Layout
Um layout é composto por ao menos um datail ou um atribute. Então, poderá
suceder uma sequência contendo detaile attribute em qualquer ordem ou quantidade.
Opcionalmente, é possível também definir a quantidade de colunas de um layout
com o termo number, agregado a MULT_COLUMN. Para valor default, o mais conveniente é
que tenhamos apenas uma coluna.
layout
=
‘[‘ , ['MULT_COLUMN;' , number ] ,
(attribute | datail) ,
{ { attribute } , { detail } } , ‘]’ , [ ',' , layout ] ;
32
A seguir temos o diagrama do termo layout:
Figura 20 – Diagrama do termo layout
A partir da sintaxe definida para a linguagem NORL é possível a criação dos
relatórios mais comumente utilizados.NORL atendeao Relatório Plano, ao Relatório de
Referência Cruzada e, também, ao Relatório de Varias Colunas. Essa linguagem também
propicia fazer agrupamentos e a realizar operações com os dados das tabelas.
33
5ESTUDO DE CASO DELAYOUTS DESCRITOS EM NORL
Neste capítulo são apresentados alguns protótipos para ilustrar a utilização da
NORL para a criação de relatórios. Abaixo temos o diagrama de classes que modela o
domínio o qual se vai considerar:
Figura 21 – Modelagem do domínio fictício
5.1 PROTÓTIPOS DE DEFINIÇÃO DE UM RELATÓRIO PLANO
Abaixo é descrito o layout de um relatório plano com o seguinte código:
[relatorio.img_estado, relatorio.titulo, relatorio.img_uece,
relatorio.corpo,
[[aluno.matricula,disciplina,situacao]cresc(aluno.matricula)],
relatorio.assinatura]
Essa definição seria aplicada em um objeto da classe Historico. „relatorio‟, é um
membro de Historico e também uma referência para o objeto da classe Relatorio. Por meio
dessa referência, temos acesso aos atributos da classe Relatorio. Da mesma forma, temos as
referencias e acesso aos atributos da classe Aluno, Disciplina e SituacaoDisciplina.
A partir daí, o framework deverá selecionar o componente visual mais adequado
de acordo com o tipo do atributo referenciado na descrição. Por exemplo, o atributo
„relatorio.img_estado‟, que é um array de bytes, é apresentado como uma imagem.
34
A definição da tabela está em negrito na descrição de relatório dada acima.
Estamos também usando da operação „cresc‟, que aqui classifica em ordem crescente os
registros segundo a matrícula do aluno.
A seguir, mostra-se a figura que ilustra o relatório gerado pelo framework a partir
da descrição feita acima:
Figura 22 – Exemplo de um relatório plano descrito em NORL
5.2 PROTÓTIPO DA DEFINIÇÃO DE UM RELATÓRIO COM REFERÊNCIA CRUZADA
O código para a geração de um relatório com referência cruzada é descrito da
seguinte forma:
[relatorio.img_estado,
relatorio.img_uece,
relatorio.corpo,
[
[aluno.matricula,aluno.nome]x
[disciplina.descricao]x
[situação.descricao]
cresc(aluno.matricula,aluno.nome)
],
relatorio.assinatura]
relatorio.titulo,
35
O presente relatório de referência cruzada para apresentar os mesmos dados que o
relatório plano, acrescentando também o nome dos alunos.
A seguir, mostramos o relatório gerado pelo framework a partir dessa definição:
Figura 23 – Exemplo de um relatório de referência cruzada descrito em NORL
5.3 PROTÓTIPO DA DESCRIÇÃO DE UM RELATÓRIO COM LISTA
O código para a geração de um relatório com lista é descrito da seguinte forma:
[relatorio.img_estado,
relatorio.titulo,
relatorio.img_uece,
relatorio.corpo,
<aluno.selecionados>,relatorio.assinatura]
Como resultado da interpretação do código acima, temos um relatório que lista o
conteúdo do atributo „selecionados‟, que é do tipo lista e pertence a um objeto da classe
Aluno.
Abaixo temos o relatório que seria gerado pelo framework a partir da descrição
acima:
36
Figura 24 – Exemplo de um relatório com lista descrito em NORL
5.4 PROTÓTIPO DA DESCRIÇÃO DE UM RELATÓRIO DE MÚLTIPLAS COLUNAS
O código para a geração de um relatório com múltiplas colunas é descrito da
seguinte forma:
[relatorio.img_estado,
relatorio.titulo,
relatorio.img_uece,
relatorio.corpo,
[MULT_COLUNM:2:<aluno.selecionados>],relatorio.assinatura]
O relatório gerado a partir do código acima é semelhante ao da seção 5.3. A
diferença é que a lista é mostrada em duas colunas, como é descrito no código em negrito.
Então, temos o relatório que seria gerado pelo framework a partir da descrição
anterior:
37
Figura 25 – Exemplo de um relatório de múltiplas colunas descrito em NORL
38
6 CONCLUSÃO E TRABALHOS FUTUROS
O fruto desse trabalho é a Naked Object Repor tLinguage (NORL). Uma
linguagem capaz de descrever o layout de relatórios, o que possibilita a automatização da
construção de relatórios de forma aderente ao padrão Naked Objects. Por conta disso,
qualquer framework baseado em Naked Objects pode implementar uma máquina de criação
de relatórios capaz de interpretar a linguagem NORL e com base nela gerar seus próprios
relatórios.
Vale ressaltar que se trata de uma linguagem simples, o que propicia um rápido
aprendizado por parte do desenvolvedor e consequentemente, um baixo custo de manutenção
dos relatórios.Assim, depois da implementação da máquina de criação de relatórios,espera-se
que tal tarefa não mais seja um fator que agrega tanta complexidade ao processo de
desenvolvimento.
A NORL foi concebida de forma genérica para que toda a comunidade se
beneficiasse dela, mas a motivação inicial foi atender às necessidades do setor de
desenvolvimento da UECE. Agora, a instituição conta com mais um recurso para otimizar o
seu desempenho.
Como trabalho futuro pretende-se implementar o modelo aqui proposto no
framework Entities.
39
REFERÊNCIAS
ENTITIES framework. UECE tira segundo lugar no Prêmio Ceará de Cidadani@
Eletrônica 2012. Postado por Marcius Brandão. Fortaleza, 2010. Disponível em:
<http://entitiesframework.blogspot.com/>. Acesso em: 15 jun. 2011.
FAYAD, M. Building application frameworks: object-oriented application frameworks.
New York: [s.n.], 1997.
FERREIRA, A. B. H. Novo dicionário Aurélio da língua portuguesa. 2. ed. Rio de Janeiro:
Sem Fronteira, 1986.
FERREIRA, A. G. Frameworks baseados em Domain Driven Design e Naked Object: um
estudo de caso. 2010. 70 f. Monografia (Curso de Graduação em Sistemas de Informação) –
Faculdade 7 de Setembro, Fortaleza, 2010.
INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA. Disponível em:
<http://www.ibge.gov.br/home/ presidencia/noticias/noticia_visualiza.php?id_noticia=1860>.
Acesso em: 03 mar. 2011.
O POVO. Disponível em: <http://www.opovo.com.br/app/opovo/jornaldoleitor/2011/01/15/
noticiasjornaljornaldoleitor,2088637/a-medicina-natural.shtml>. Acesso em: 2 fev. 2011.
OFFICE, M. Tipos de relatórios que você pode criar no access. Disponível em:
<http://office.microsoft.com/pt-br/access-help/tipos-de-relatorios-que-voce-pode-criar-noaccess-HA001045080.aspx>. Acesso em: 28 jul. 2011.
OWLER, M.; RICE, D.; FOEMMEL, M. Patterns of enterprise application architecture.
[S.l.]: Addison-Wesley, 2003. 512 p.
PAWSON, R. Naked object. [S.l.: s.n.], 2004.
PEOPLESOFT. Enterpriseone, P. 8. 9. Geração de relatórios empresariais. [S.l.: s.n.], set.
2003. Disponível em: <http://docs.oracle.com/cd/E12293_01/jded/acrobat/AC89POR0309.
pdf>. Acesso em: 20 jun. 2011.
PIRRO, W. Alguns impactos sociais do desenvolvimento científico e tecnológico. Revista
Cientifica Digital da Faetec, 2008.
RADEMACHER, G. Welcome to Railroad Diagram Generator!. Railroad Diagram
Generator, v. 1.25.661, 30 May 2013. Disponível em: <http://railroad.my28msec.com/
rr/ui>. Acesso em: 15 ago. 2012.
SQLSERVER, M. Tipos de relatórios (Construtor de Relatórios 2.0). Disponível em:
<http://technet.microsoft.com/pt-br/library/dd207050%28v=sql.100%29.aspx>. Acesso em:
20 jun. 2013.
THE ECLIPSE FOUNDATION. BIRD Project: business intelligence and reporting tools.
Disponível em: <http://www.eclipse.org/birt/phoenix/>. Acesso em: 15 ago. 2011.
40
TOFFOLI, G. A design tool iReport for Jasper Reports: documentation and tutorial.
Manual for iReport>= 0.2.0 (pure java version of iReport). [S.l: s.n.], 2002. Disponível em:
<http://ireport.sourceforge.net/manual0.2.0.html#1.0>.
WEISZFLOG, W. Michaelis moderno dicionário da lingua portuguesa. São Paulo:
Melhoramentos, 2004.