PROCESSO DE GERAÇÃO DE CÓDIGO EM JAVA A PARTIR DE UM DIAGRAMA DE CLASSES

Transcrição

1 UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE SISTEMAS DE INFORMAÇÃO (BACHARELADO) MARIANA CARDOSO DE BEM CASTELLO BRANCO PROCESSO DE GERAÇÃO DE CÓDIGO EM JAVA A PARTIR DE UM DIAGRAMA DE CLASSES LAGES (SC) 2008

2 MARIANA CARDOSO DE BEM CASTELLO BRANCO PROCESSO DE GERAÇÃO DE CÓDIGO EM JAVA A PARTIR DE UM DIAGRAMA DE CLASSES Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com o nome equivalente no curso de Sistemas de Informação - Bacharelado. Orientação: Prof. Alexandre Perin de Souza, M.Sc. LAGES (SC) 2008

3 MARIANA CARDOSO DE BEM CASTELLO BRANCO PROCESSO DE GERAÇÃO DE CÓDIGO EM JAVA A PARTIR DE UM DIAGRAMA DE CLASSES ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO, DO 8º. SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM SISTEMAS DE INFORMAÇÃO Lages (SC), 01 de Dezembro de 2008 Prof. Alexandre Perin de Souza, M.Sc. Orientador BANCA EXAMINADORA: Prof. Marcos André Pisching, M.Sc. UNIPLAC Prof. Daiana Petry, M.Sc. UNIPLAC Prof. Wilson Castello Branco Neto, Dr. Professor de TCC Prof. Ângelo Augusto Frozza, M.Sc. Coordenador de Curso

4 Dedico este trabalho aos meus pais Édson e Arlete, meu irmão Eduardo, minha filha Beatriz e meu esposo Wilson, que sempre me apóiam direta ou indiretamente.

5 Agradeço a Deus e aos bons guias por toda luz e proteção. Agradeço ao meu esposo Wilson por todo ensinamento, paciência e amor despendidos. Agradeço ao meu orientador Perin por toda paciência e dedicação.

6 Quando você quer alguma coisa, todo o universo conspira para que você realize o seu desejo. (Paulo Coelho)

7 LISTA DE ILUSTRAÇÕES FIGURA 1 - Ambiente Hipotético de Produção de Software alicerçado por uma ferramenta CASE FIGURA 2 - Interface da ferramenta CASE JUDE FIGURA 3 - Interface da ferramenta CASE Enterprise Architect FIGURA 4 - Interface da ferramenta CASE Rational Rose FIGURA 5 - Interface da ferramenta CASE Umbrello FIGURA 6 - Interface da ferramenta CASE ArgoUML FIGURA 7 - Interface da ferramenta CASE UML Modeling para NetBeans FIGURA 8 - Mapeamento da classe Aluno para Java FIGURA 9 - Mapeamento da classe Aluno e seus atributos para Java FIGURA 10 - Classe com associação unidirecional para FIGURA 11 - Classe com associação unidirecional para FIGURA 12 - Classe com associação unidirecional para * FIGURA 13 - Classe com associação ordenada FIGURA 14 - Classe com associação qualificada FIGURA 15 - Classe de associação FIGURA 16 - Classe com associação bidirecional FIGURA 17 - Agregação FIGURA 18 - Agregação compartilhada FIGURA 19 - Agregação por composição FIGURA 20 - Classes Professor e Técnico Administrativo herdando da classe Funcionário FIGURA 21 - Exemplo de hierarquia de herança FIGURA 22 - Polimorfismo de sobreposição FIGURA 23 - Operação e consulta de sistema e método delegado FIGURA 24 - Interface FIGURA 25 - Barra de ferramentas para geração de código FIGURA 26 - Configuração da linguagem em que o código será gerado FIGURA 27 - Definição dos objetos FIGURA 28 - Diagrama de classe de um laboratório de exames clínicos FIGURA 29 - Diagrama de classe de um laboratório de exames clínicos para pessoa/animal QUADRO 1 - Requisitos de sistema para funcionamento do JUDE... 22

8 QUADRO 2 - Requisitos de sistema para funcionamento do EA no Windows QUADRO 3 - Requisitos de sistema para funcionamento do EA no Linux QUADRO 4 - Requisitos de sistema para funcionamento do Rational Rose QUADRO 5 - Requisitos de sistema para funcionamento do ArgoUML QUADRO 6 - Requisitos de sistema para funcionamento do UML Modeling para NetBeans QUADRO 7 - Resumo das ferramentas CASE QUADRO 8 - Mapeamento de Sets e Gets da classe Aluno para Java QUADRO 9 - Mapeamento da classe com associação unidirecional para 1 em Java. 36 QUADRO 10 - Mapeamento da classe com associação unidirecional para 0..1 em Java QUADRO 11 - Mapeamento da classe com associação unidirecional para * em Java QUADRO 12 - Método para consultar um subconjunto específico de alunos QUADRO 13 - Mapeamento da classe com associação ordenada para Java QUADRO 14 - Mapeamento da classe com associação qualificada para Java QUADRO 15 - Mapeamento de classe de associação em Java QUADRO 16 - Mapeamento da classe com associação bidirecional em Java para a classe Aluno QUADRO 17 - Mapeamento da classe com associação bidirecional em Java para a classe Curso QUADRO 18 - Agregação compartilhada e seu código em Java QUADRO 19 - Agregação por composição e seu código em Java QUADRO 20 - Mapeamento das classes Professor e Técnico Administrativo herdando da classe Funcionário em Java QUADRO 21 - Polimorfismo de sobreposição e seu código em Java QUADRO 22 - Implementação da operação de sistema e do método delegado QUADRO 23 - Interface e seu código em Java QUADRO 24 - Código da classe Enfermeiro gerado no EA QUADRO 25 - Código da classe Enfermeiro corrigido para compilar QUADRO 26 - Código da classe Paciente gerado no EA QUADRO 27 - Código da classe Paciente corrigido para compilar QUADRO 28 - Código da classe Equipamento gerado no EA QUADRO 29 - Código da classe Equipamento corrigido para compilar QUADRO 30 - Código da classe Equipamento gerado no UML Modeling para NetBeans QUADRO 31 - Código da classe Sala gerado no EA QUADRO 32 - Código da classe Sala corrigido para compilar QUADRO 33 - Código da classe Sala gerado no UML Modeling para NetBeans QUADRO 34 - Código da classe Espera gerado no EA QUADRO 35 - Código da classe Recuperação gerado no EA QUADRO 36 - Código da classe Espera corrigido para compilar QUADRO 37 - Código da classe Recuperação corrigido para compilar QUADRO 38 - Código da classe Espera gerado no UML Modeling para NetBeans... 70

9 QUADRO 39 - Código da classe Recuperação gerado no UML Modeling para NetBeans QUADRO 40 - Código da interface Paciente gerado no EA QUADRO 41 - Código da classe PacienteAnimal gerado no EA QUADRO 42 - Código da classe PacienteAnimal corrigido para compilar QUADRO 43 - Código da classe PacienteAnimal gerado no UML Modeling para NetBeans... 72

10 LISTA DE ABREVIATURAS E SIGLAS CASE DER DFD EA ER IBM JPA JUDE JVM KDE UML XMI XML - Computer-Aided Software Engineering - Diagrama de Entidade e Relacionamento - Diagrama de Fluxo de Dados - Enterprise Architect - Entidade Relacionamento - International Business Machine - Java Persistence API - Java and UML Developer Environment - Java Virtual Machine - K Desktop Environment - Unified Modeling Language - XML Metadata Interchange - extensible Markup Language

11 RESUMO Este trabalho trata da geração de código orientado a objetos em Java a partir de um diagrama de classes. Ele apresenta um breve estudo sobre as ferramentas CASE JUDE, Enterprise Architect, Rational Rose, Umbrello UML Modeler, Argo UML e UML Modeling para NetBeans, descrevendo suas principais características, com o objetivo de ressaltar as semelhanças e diferenças existentes entre as ferramentas mais usadas atualmente. Além disto, detalha como deve ser desenvolvido o código em Java a partir de um diagrama de classes, visando explicar como cada conceito do diagrama deve ser representado na linguagem Java. De posse deste conhecimento é possível verificar a consistência dos códigos gerados automaticamente pelas ferramentas, que é o objetivo central deste trabalho. Para isto, foram desenvolvidos dois diagramas de classes sobre um mesmo contexto, um laboratório de exames clínicos. O primeiro diagrama mostra conceitos mais simples, como classes, atributos e métodos, e o segundo conceitos mais complexos, como herança, interface e polimorfismo. Partindo dos diagramas, o código foi gerado no Enterprise Architect para o primeiro exemplo e no Enterprise Architect e no UML Modeling para NetBeans para o segundo exemplo. A escolha por estas duas ferramentas deve-se ao fato delas representarem situações bem distintas: enquanto a primeira é proprietária e visa exclusivamente à modelagem - não está diretamente integrada a nenhum ambiente de programação - a segunda é uma ferramenta livre e integrada ao NetBeans IDE, que consiste em uma das ferramentas mais usadas no desenvolvimento Java. Os códigos gerados nas duas ferramentas foram analisados e incluídos em um projeto no NetBeans para serem compilados, com o intuito de verificar se eles estavam corretos e completos. A partir da análise dos códigos gerados pelas duas ferramentas verificou-se a existência de problemas, pois ambas falharam em alguns pontos da geração. Ressalta-se como principal problema a não criação de métodos para manipular as associações entre classes. Isto leva à conclusão que as ferramentas CASE são úteis para agilizar o trabalho de codificação, mas ainda não são capazes de realizar integralmente o trabalho, sem a intervenção de um programador. Palavras-chave: Ferramenta CASE; Programação Orientada a Objetos; Geração Automática de Código; Java.

12 ABSTRACT This job deals with the code generation in Java, based on class diagrams. It presents a brief study about CASE tools such as JUDE, Enterprise Architect, Rational Rose, Umbrello UML Modeler, Argo UML and UML Modeling to NetBeans, and shows the main features about CASEs aiming at showing similarities and differences between tools used nowadays. Furthermore, this work presents details about how Java code must be written based on class diagrams. This process has as goal to explain how each diagram s concept should be represented in Java language. Based on this knowledge it is possible to verify the automatically generated code consistence, which is the main goal of this job. For this, two class diagrams about the same context, a laboratory of clinic exams, were developed. The first diagram displays basic oriented object concepts such as: class, attributes and methods and the second one shows complex concepts: inheritance, interface and polymorphism. Based on such diagrams, the code were generated using Enterprise Architect tool to the first example and Enterprise Architect and UML Modeling to NetBeans to the second one. The choice by these two tools is based on fact that they represent different contexts: while the first is owner and has as objective just the modeling it is not integrated with programming environment the second one is a free tool and is integrated to NetBeans IDE, which is quite used in the Java development. The code generated were analyzed and inserted into NetBeans project to be compiled, aiming at verifying if the codes were correct and complet or not. The code generated analysis showed some problems, because both tools don t work correctly in code generation process. The main problem of this process is not creating methods to handle associations between classes. So, the conclusion is that CASE tools are important to speed up the implementation job, although the tools are not able to accomplish completely the generation code without the human intervention. Keywords: CASE Tools; object-oriented programming; automatic code generation; Java.

13 SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia FERRAMENTAS CASE Ferramentas CASE JUDE Enterprise Architect Rational Rose Umbrello UML Modeller ArgoUML UML Modeling para Netbeans Resumo das ferramentas estudadas Conclusão GERAÇÃO DE CÓDIGO Classes e atributos Associações Associação unidirecional com multiplicidade Associação unidirecional com multiplicidade Associação unidirecional com multiplicidade * Associação unidirecional com multiplicidade ordenada Associação unidirecional qualificada Associação unidirecional com classe de associação Associação unidirecional com multiplicidade 1 na origem Associação bidirecional Agregação Herança Hierarquias de herança Polimorfismo Métodos delegados e operações/consultas de sistema... 50

14 3.7 Interface Conclusão ANÁLISE DE CÓDIGO GERADO A PARTIR DE DIAGRAMA DE CLASSES Geração de código na ferramenta CASE Enterprise Architect Exemplo Sumário executivo Requisitos funcionais Diagrama de classes Análise dos códigos gerados Exemplo Diagrama de Classes Análise dos Códigos Gerados Conclusão CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS BIBLIOGRAFIA COMPLEMENTAR APÊNDICES... 82

15 14 1 INTRODUÇÃO 1.1 Apresentação A Engenharia de Software é uma disciplina que integra processos, métodos e ferramentas para o desenvolvimento de software (PRESSMAN, 2001), buscando resolver os problemas com eficácia para criar softwares com qualidade. Ela foi dividida em várias áreas para melhor atingir seus objetivos. Uma destas áreas é a de Ferramentas e Ambientes de Desenvolvimento de Software, a qual tem recebido especial atenção nos últimos anos, devido a sua natural evolução. Sua finalidade está em agilizar e organizar a produção e manutenção dos diversos artefatos envolvidos na elaboração de um software. Para que o desenvolvimento do sistema ocorra com maior eficiência, existem diversas ferramentas que auxiliam neste processo, chamadas de ferramentas CASE (Computer-Aided Software Engineering). Uma atividade possível de ser feita através do uso de uma ferramenta CASE é a criação de diagramas com base na notação UML (Unified Modeling Language). Dentro da UML, que é uma linguagem de modelagem para visualizar, especificar, documentar e desenvolver sistemas, existem diversos diagramas, dentre eles, está o diagrama de classes que, segundo Barnes e Kölling (2004), mostra as classes de uma aplicação e os relacionamentos entre elas, fornece as informações sobre o código-fonte e apresenta a visualização estática de um programa. A partir do diagrama de classes, que foi criado a partir de um exemplo fictício de um laboratório de exames clínicos, é possível gerar o código do sistema em

16 15 diversas linguagens através de uma ferramenta CASE, que suporte desde a especificação e análise dos requisitos, até o projeto e implementação do sistema. Ferramentas CASE têm se mostrado cada vez mais importantes e poderosas, auxiliando o desenvolvedor na maximização de suas habilidades intelectuais e criativas (BARRÉRE, PRADO e BONAFE, 2008). A análise dos códigos gerados a partir do diagrama de classes torna possível corrigir aqueles gerados de forma inadequada e faz com que o usuário conheça melhor os aspectos positivos e negativos do gerador de código disponível nas ferramentas CASE. Por isso, um estudo que ofereça um melhor entendimento de como o processo de geração automática de código ocorre é essencial para a produção de sistemas com qualidade. Além desta apresentação, o restante do trabalho está organizado da seguinte maneira: no capítulo 2 é feito um estudo sobre ferramentas CASE, apresentando suas principais características; o capítulo 3 trata o processo de tradução de diagrama de classes para código na linguagem Java; a consistência dos códigos gerados pela ferramenta CASE Enterprise Architect e UML Modeling para NetBeans e as soluções para os códigos inconsistentes são apresentadas no capítulo 4. Por fim, o capítulo 5 mostra as considerações finais sobre o trabalho. 1.2 Descrição do problema Em virtude de uma maior inserção dos computadores na vida das pessoas, criar software tornou-se uma tarefa complexa, seja pelo aparecimento de novas necessidades, ou pela complexidade intrínseca das aplicações. Uma forma de contornar esta situação ou minimizar o seu impacto está no uso de ferramentas CASE. Uma vez definido o diagrama de classes, realiza-se a geração de código automática para uma determinada linguagem de programação usando uma ferramenta CASE. Em alguns casos, o resultado deste processo é insatisfatório, pois nem sempre há consistência entre ambos.

17 16 Diante do exposto, o desafio deste trabalho está em descobrir os motivos que levam à criação de classes incompletas ou inconsistentes a partir da geração automática de código realizada por uma ferramenta CASE, como a figura 1 apresenta. FIGURA 1 - Ambiente Hipotético de Produção de Software alicerçado por uma ferramenta CASE 1.3 Justificativa O tema de pesquisa abordado neste trabalho inspira-se em um objetivo primordial da área de Engenharia de Software: produzir sistemas com qualidade. Em função disso, surgiu a necessidade de realizar um estudo sobre o processo de geração de código orientado a objetos através de ferramentas CASE. Outro ponto de destaque e que ratifica a importância deste estudo, refere-se ao avanço da tecnologia, principalmente dos computadores. Estas máquinas estão inseridas cada vez mais na vida das pessoas, criando novas necessidades e desafios para Engenheiros de Software. Assim, para acompanhar o avanço da tecnologia e o surgimento de novas necessidades, engenheiros de sistemas precisam adotar novos

18 17 paradigmas, ferramentas, linguagens, etc. A programação orientada a objetos é um paradigma que vem conquistando cada vez mais a preferência dos programadores. Dentre alguns motivos que levam a esta escolha, estão a simplificação de requisitos, projetos e implementação (GUSTAFSON, 2003). Para poder programar orientado a objetos é necessário criar também um projeto orientado a objetos, cujo o núcleo é composto por um diagrama de classes (WAZLAWICK, 2004). Para agilizar o desenvolvimento do projeto, programadores estão buscando recursos, como ferramentas CASE, para auxiliar nas suas tarefas. Essas ferramentas CASE proporcionam o aumento da utilização da geração automática de código, diminuindo assim o tempo de desenvolvimento do software e aumentando a sua qualidade, o que facilita o trabalho dos desenvolvedores. Mas, para ter certeza de que esses códigos são gerados de maneira correta, é necessário entender como deve ser e como é feita a tradução do diagrama de classes pelas ferramentas CASE para determinada linguagem de programação orientada a objetos e verificar se há consistência entre ambos. 1.4 Objetivo geral Analisar a geração de código a partir de diagrama de classes através de ferramenta CASE para a linguagem de programação Java. 1.5 Objetivos específicos São objetivos específicos deste trabalho: a) Explorar as principais ferramentas CASE do mercado de forma a apresentar suas características mais importantes; b) Explicitar como se dá o processo de tradução de diagrama de classes para Java; c) Análise e ajuste dos códigos gerados pelas ferramentas CASE.

19 Metodologia Segundo Silva e Menezes (2005), existem várias formas de classificar as pesquisas. A forma tradicional prevê: i) quanto a natureza; ii) quanto aos objetivos; iii) quanto a abordagem do problema; e, iv) quanto a procedimentos técnicos para sua execução. Em função da classificação mencionada, este trabalho de conclusão de curso se enquadra metodologicamente da seguinte maneira: Do ponto de vista da sua natureza, o mesmo caracteriza-se como de natureza aplicada. Do ponto de vista da forma de abordagem do problema, este trabalho classifica-se como sendo de pesquisa qualitativa. Em relação aos objetivos, trata-se de uma pesquisa exploratória e também explicativa. Já sob o ponto de vista dos procedimentos técnicos, este trabalho classifica-se como sendo de pesquisa bibliográfica. O trabalho foi realizado da seguinte forma: primeiro, foi feito um estudo sobre algumas ferramentas CASE em livros e materiais disponíveis na Internet. O objetivo deste estudo foi compreender as principais características das mesmas. Em seguida, foi apresentado o processo de tradução de um diagrama de classes para Java. A execução deste passo foi baseada na proposta de geração de código descrita por Wazlawick (2004). Concluída a fundamentação teórica do trabalho, o passo seguinte foi a elaboração de dois exemplos de diagramas de classes, um mais simples e outro mais complexo, a geração de código de forma automática através de uma ferramenta CASE para o primeiro exemplo e duas ferramentas para o segundo exemplo, e este mesmo código colocado no Netbeans para a verificação da sua consistência. Nesta etapa foram utilizadas as ferramentas CASE proprietária - Enterprise Architect (SPARX SYSTEMS, 2008) e livre - UML Modeling para NetBeans. As ferramentas foram

20 19 utilizadas para gerar os códigos dos exemplos propostos anteriormente. Após a geração de código, os resultados foram verificados em relação à propriedade de consistência de código. Ainda nesta etapa, soluções para os modelos inconsistentes foram propostas. O trabalho foi finalizado com a elaboração de um artigo, do relatório de TCC e da apresentação do trabalho em banca.

21 20 2 FERRAMENTAS CASE Este capítulo apresenta um apanhado geral sobre algumas das ferramentas CASE (Computer-Aided Software Engineering) mais utilizadas e importantes do mercado, a fim de compreender suas principais características. O capítulo inicia com uma breve introdução sobre CASEs, partindo para a apresentação de aspectos importantes de cada uma das ferramentas CASE estudadas. 2.1 Ferramentas CASE Juntamente com a evolução da Engenharia de Software surgiram as ferramentas CASE, que auxiliam os desenvolvedores no processo de criação de software, melhorando, assim, a qualidade dos mesmos. As ferramentas CASE dão suporte computacional ao desenvolvedor ao longo do ciclo de vida da criação de sistemas, reduzindo o tempo total de desenvolvimento (SILVA e ROCHA, 1998). Elas são de suma importância também para a manutenção do software, auxiliando, assim, em todo o processo de desenvolvimento (Gerência, Análise, Projeto, Implementação, Teste e Manutenção) (PELOSO, 2004). Através das ferramentas CASE é possível modelar o sistema antes de escrever o seu código, o que possibilita a detecção de falhas de projeto no seu início, sendo este o período mais fácil para corrigí-las (BOGGS e BOGGS, 2002). Existem diversas ferramentas CASE no mercado, cada uma com características próprias, como a linguagem de modelagem utilizada, linguagem para a geração de código e diagramas que podem ser criados. Nas subseções a são apresentadas as principais características de seis destas ferramentas, após instalação e

22 21 uso das mesmas JUDE O JUDE (Java and UML Developer Environment), fabricado pela Change Vision (JUDE, 2007), desde sua primeira versão, é uma das ferramentas livres mais poderosas disponíveis para modelagem UML (Unified Modeling Language). Possui características que não são encontradas em outras ferramentas gratuitas, como a possibilidade de adicionar métodos no diagrama de seqüência, alterando automaticamente o diagrama de classes (PORTAL JAVA, 2008). O JUDE possui uma versão livre que é incentivada pela JUDE Community e a versão proprietária, chamada JUDE Professional, a qual possui uma versão trial por 20 dias. Uma das diferenças encontradas em ambas, é que alguns recursos da versão proprietária não são disponibilizados para a versão gratuita, como a possibilidade de criar Diagramas de Entidade Relacionamento (DER) e Diagramas de Fluxo de Dados (DFD), de converter DER em modelos UML, além do suporte ao XMI (XML Metadata Interchange) (JUDE, 2007). O XMI é um modelo para definir, trocar, manipular e integrar dados e objetos XML (extensible Markup Language), cujos padrões são usados para integrar ferramentas, repositórios, aplicações, etc. Este padrão é usado para troca de informações entre diferentes aplicativos para modelagem de sistemas que fazem uso da UML (OMG, 2008). O JUDE possuía, em 2006, 60 mil usuários e, segundo a empresa responsável pelo seu desenvolvimento, 5 mil novos usuários estavam aderindo à ferramenta a cada mês (JUDE, 2007). Os diagramas suportados pelo JUDE na fase de análise são os de Caso de Uso, Seqüência e Atividade. Na fase do projeto ele possibilita o desenvolvimento dos diagramas de Classes, Colaboração, Componentes, Distribuição e Estados. A figura 2 apresenta uma interface desta ferramenta. Na parte superior fica localizado o menu principal, que permite criar, salvar, abrir arquivos, pacotes, elementos, selecionar diagramas, etc. À esquerda, uma barra de ferramentas mostra a

23 22 estrutura do diagrama criado, a herança, o mapa, os diagramas que foram desenvolvidos e uma opção de busca. À direita, na parte principal da interface, apresentam-se os diagramas criados, com seus atributos, métodos e associações. FIGURA 2 - Interface da ferramenta CASE JUDE O JUDE é voltado para a linguagem de programação Java e pode ser utilizado em todos os sistemas operacionais que possuam a Máquina Virtual Java (JVM Java Virtual Machine). Além de gerar código nesta linguagem ele também é capaz de realizar engenharia reversa, transformando códigos Java em diagramas. Os requisitos mínimos para o funcionamento da ferramenta são descritos no quadro 1. QUADRO 1 - Requisitos de sistema para funcionamento do JUDE Sistema Operacional Windows 2000, XP, Vista Quantidade Recomendada de 256MB Memória Espaço em Disco Disponível 128MB Processador Pentium III de 700MHz Outros J2SE1.4.1_07 ou superior, ou J2SE1.4.2_05 ou superior ou JDK5.0 Versão JUDE Community e JUDE Professional 5.2.1

24 Enterprise Architect O Enterprise Architect (EA) é uma ferramenta de análise e projeto UML, que possibilita o desenvolvimento de software a partir de um conjunto de requisitos, análise de estágios, modelos de projeto, testes e manutenção. O EA é uma ferramenta multi-usuário, projetada para auxiliar na construção de softwares robustos e eficazes (KATÁLOGO, 2008). O EA é uma ferramenta proprietária, fabricada pela Sparx Systems (SPARX SYSTEMS, 2008) e tem uma versão trial que pode ser usada por 30 dias. O EA suporta os 13 diagramas UML, entre outros. Na fase de análise: Caso de Uso, Seqüência, Atividade e Objeto. Na fase de Projeto: Classe, Distribuição, Componente e Estado. Além disso, possui suporte ao XMI. A figura 3 apresenta uma interface da ferramenta com o menu principal na parte superior, que possíbilita criar, salvar, abrir arquivos, pacotes, diagramas, elementos, etc. À esquerda encontram-se duas barras de ferramentas. Na primeira (Toolbox), estão os elementos que podem ser usados nos diversos diagramas, como Classes, Associações, Atores e Casos de Uso. Na segunda (Project Browser), encontram-se os diagramas que fazem parte do projeto, os quais são definidos no momento da sua criação. À direita, está a parte principal da interface, onde os diagramas são desenvolvidos. O Enterprise Architect possui versões para Windows e Linux a qual possibilita a geração de código e a engenharia reversa em várias linguagens de programação, como Java, C#, C++, Visual Basic, VB.Net, Delphi e PHP. Por ser de fácil utilização, esta ferramenta possui mais de usuários (licenças pagas) em mais de 60 países, entre eles: Estados Unidos, Canadá, Reino Unido, Espanha, Alemanha, Japão, Escandinávia, França, Holanda entre outros. Apresenta forte suporte na Austrália, Brasil, México, Nova Zelândia, Coréia, África do Sul, Argentina, Chile, etc. (MOMBACH, 2005).

25 24 FIGURA 3 - Interface da ferramenta CASE Enterprise Architect Os requisitos mínimos para o funcionamento da ferramenta no Windows e no Linux são descritos nos quadros 2 e 3. QUADRO 2 - Requisitos de sistema para funcionamento do EA no Windows Sistema Operacional Windows Quantidade Recomendada de 128 MB Memória Espaço em Disco Disponível 70 MB Processador Pentium Outros Versão 7.1 QUADRO 3 - Requisitos de sistema para funcionamento do EA no Linux Sistema Operacional Linux Quantidade Recomendada de 64MB Memória Espaço em Disco Disponível 70 MB Processador Pentium II Outros Linux Operating System (kernel 2.4) Versão Rational Rose Rational Rose é uma ferramenta que auxilia os desenvolvedores nos

26 25 processos de construção de um software, utilizada por diversos profissionais e grandes empresas. Foi criada pela Rational, posteriormente adquirida pela IBM (International Business Machine), sendo uma ferramenta proprietária, com versão trial por 30 dias (IBM, 2008). Ela viabiliza aos analistas de sistemas a realização de diversas tarefas, que vão desde a criação dos modelos, configuração e criação dos diagramas da UML, tais como o de Caso de Uso, Seqüência e Atividade, na fase de análise; Classe, Objetos, Colaboração, Componentes, Distribuição e Estados, na fase de projeto (BOGGS e BOGGS, 2002). A figura 4 apresenta uma interface da ferramenta com o menu principal na parte superior, sendo possível criar, salvar, abrir arquivos, pacotes, diagramas, elementos, etc. À esquerda encontram-se os diagramas que fazem parte do projeto e os elementos que podem ser usados nos diversos diagramas, como Classes, Associações, Atores e Casos de Uso. À direita, está a parte principal da interface, onde os diagramas são desenvolvidos. FIGURA 4 - Interface da ferramenta CASE Rational Rose

27 26 O Rational Rose gera código em várias linguagens disponíveis no mercado, como C++, Ada, CORBA, Java, Visual Basic e XML, e também pode aplicar engenharia reversa ao código destas mesmas linguagens. Esta ferramenta é executada no sistema operacional Windows (IBM, 2008). Atualizações como o CASE Tools XMI Update (ESRI, 2008) e o XMI Toolkit (IBM, 2008) permitem que o Rational Rose importe e exporte arquivos no formato XMI. Os requisitos mínimos para o funcionamento da ferramenta são descritos no quadro 4. QUADRO 4 - Requisitos de sistema para funcionamento do Rational Rose Quantidade Recomendada de 256 MB Memória Espaço em Disco Disponível 450 MB Processador Pentium II de 450MHz Outros Versão Umbrello UML Modeller O Umbrello UML Modeller é uma ferramenta criada com o apoio da comunidade de software livre, cujo projeto é liderado por Jonathan Riddell (UMBRELLO UML MODELLER, 2008). É uma ferramenta de domínio público, que possibilita a criação de diagramas UML para auxiliar no processo de desenvolvimento de software, ajudando a obter um produto de qualidade, especialmente durante as fases de análise e projeto (VIEIRA, 2008). Ele suporta os seguintes diagramas UML: Caso de Uso, Seqüência e Atividade, na fase de análise, e de Classes, Colaboração, Componente, Estados e Distribuição, na fase de projeto. Esta ferramenta salva seus arquivos no formato padronizado XMI, que também é utilizado e compatível com vários outros softwares do gênero. A figura 5 apresenta a tela principal da ferramenta com o menu principal na parte superior, sendo possível criar, salvar, abrir arquivos, pacotes, diagramas, elementos, etc. À esquerda, encontra-se uma barra de ferramentas (Tree View) que

28 27 contém as opções dos diagramas que podem ser criados. À direita, na parte principal da interface, é apresentado o diagrama que está sendo desenvolvido pelo usuário. FIGURA 5 - Interface da ferramenta CASE Umbrello O Umbrello é capaz de gerar o código a partir dos diagramas UML nas linguagens: ActionScript, Ada, C++, IDL (CORBA), Java, JavaScript, Perl, PHP, Python, Ruby, SQL, TCL, XMLSchema. Também é possível importar código para gerar diagramas (engenharia reversa), a partir das linguagens C++, Java e Python. Os sistemas operacionais em que a ferramenta pode ser executada são o Linux, Unix, FreeBSD e Solaris. A ferramenta acompanha o KDE (K Desktop Environment), ou seja, está presente em todas as distribuições do GNU/Linux, sendo que os requisitos mínimos para instalação dependem das exigências da distribuição do Linux que está instalada (UMBRELLO UML MODELLER, 2008).

29 ArgoUML O ArgoUML é uma ferramenta desenvolvida pela Tigris.org Open Source Software Engineering Tools (Ferramentas Livres para Engenharia de Software), que é uma comunidade focada em construir ferramentas com melhor qualidade para o desenvolvimento de software colaborativo (TIGRIS.ORG, 2008). Da versão 0.24 aconteceram mais de 120 mil downloads desde que foi disponibilizada em Considerando todas as versões, o número de downloads chega a 500 mil, demonstrando assim, uma estimativa do número de usuários desta ferramenta (TIGRIS.ORG, 2008). O ArgoUML é uma ferramenta CASE em Java para projetos orientados a objetos, que inclui os mesmos recursos de edição e geração de códigos encontrados em ferramentas CASE comerciais, inclusive o suporte a XMI (GOMES, 2008). Ela é uma ferramenta gratuita que permite modelar diagramas da UML como de Caso de Uso, Seqüência e Atividade, na fase de análise; Classe, Colaboração, Distribuição e Estados, na fase de projeto. A interface principal da ferramenta é apresentada na figura 6, com um menu na parte superior que possibilita criar, salvar, abrir arquivos, pacotes, diagramas, elementos, etc. Na esquerda encontram-se os diagramas que fazem parte do projeto, os quais são definidos no momento da sua criação. À direita, está a parte principal da interface, onde os diagramas são desenvolvidos. Essa ferramenta pode gerar código nas linguagens de programação C++, C#, Java, PHP e faz engenharia reversa. Pode ser utilizado em todos os sistemas operacionais que possuam a JVM. Outra característica é o suporte à internacionalização, ou seja, o programa é adaptado para que seja traduzido para diversos idiomas. Um dos pontos negativos é que ainda não suporta todas as características da UML, como, por exemplo, não oferece total suporte a alguns diagramas como o diagrama de seqüência. Os requisitos mínimos para o funcionamento da ferramenta são descritos no quadro 5.

30 29 FIGURA 6 - Interface da ferramenta CASE ArgoUML QUADRO 5 - Requisitos de sistema para funcionamento do ArgoUML Sistema Operacional Windows Quantidade Recomendada de 64MB Memória Espaço em Disco Disponível 10MB Processador Intel Pentium de 200MHz, AMD K6 ou um processador semelhante Outros Java 2 JRE ou JDK instalado Versão UML Modeling para Netbeans O NetBeans é um projeto Open Source, com diversos usuários e uma comunidade crescente, com aproximadamente 100 parceiros pelo mundo. A Sun Microsystem fundou este projeto em junho de 2000 e continua sendo seu principal patrocinador (NETBEANS, 2008). O NetBeans possui além de outros recursos, a modelagem UML, facilitando o trabalho de desenvolvedores, pois permite o desenvolvimento da modelagem e a

31 30 geração do código em uma mesma ferramenta. É uma ferramenta gratuita que permite modelar 8 diagramas da UML, como de Caso de Uso, Seqüência e Atividade, na fase de análise; Classe, Colaboração, Componente, Implantação e Estado, na fase de projeto. Essa ferramenta gera código na linguagem Java, faz engenharia reversa e pode ser utilizada pelos sistemas operacionais Windows, Linux, Mac OS e Solaris. Um dos pontos negativos é não possuir suporte à XMI, nem à internacionalização. A interface principal da ferramenta é apresentada na figura 7, com um menu na parte superior que possibilita criar, salvar, abrir arquivos, pacotes, elementos, etc. Na esquerda encontram-se os elementos que fazem parte do projeto. Ao centro está a parte principal da interface, onde os diagramas são desenvolvidos, e à direita uma paleta com os elementos que podem ser usados nos diversos diagramas. FIGURA 7 - Interface da ferramenta CASE UML Modeling para NetBeans Os requisitos mínimos para o funcionamento da ferramenta no Windows são

32 31 descritos no quadro 6. QUADRO 6 - Requisitos de sistema para funcionamento do UML Modeling para NetBeans Sistema Operacional Windows Quantidade Recomendada de 512MB Memória Espaço em Disco Disponível 750MB Processador Pentium III, 800MHz Outros JDK instalado Versão Resumo das ferramentas estudadas No quadro 7, encontra-se um resumo das ferramentas CASE estudadas. O mesmo foi organizado levando em consideração características gerais que uma ferramenta CASE deve prover. Tais aspectos se justificam na perspectiva de que um desenvolvedor possa compreendê-los e, assim, ter uma visão abrangente de uma determinada ferramenta CASE. Características JUDE Enterprise Architect Distribuição Faz Engenharia Reversa Sistema Operacional Quais Linguagens de Modelagem Utiliza Diagramas UML Suportados QUADRO 7 - Resumo das ferramentas CASE Rational Rose Umbrello ArgoUML UML Modeling para NetBeans Proprietária Proprietária Proprietária Livre Livre Livre e Livre Sim Sim Sim Sim Sim Sim Todos Windows (9x, NT, ME, 2000, XP), Linux Windows (9x, NT, ME, 2000, XP) Linux, Unix, FreeBSD, e Solaris Windows 95, 98, 2000, NT Windows, Linux, Mac OS e Solaris UML UML UML UML UML UML Caso de Uso, Classes, Seqüência, Colaboração, Atividade, Componente, Desenvolvimento e Caso de Uso, Classes, Seqüência, Atividade, Objeto, Componente, Distribuição e Estado Casos de Uso, Classes, Componente, Desenvolvimento, Objetos, Seqüência, Colaboração, Estado Caso de Uso, Classes, Seqüência, Colaboração, Atividade, Componente, Estado e Distribuição Caso de Uso, Seqüência, Atividade, Classes, Colaboração, Distribuição e Estado Caso de Uso, Seqüência, Atividade, Classes, Colaboração, Componente, Implanta-

33 32 Gera Código em quais Linguagens de Programação Estado e Atividades ção e Estado Java C++, Java, C#, Visual Basic, PHP, VB.Net, Delphi C++, C#, Ada, CORBA, Java, PHP, Visual Basic, XML, Net Suporte a XMI Sim 1 Sim Sim, com o uso de ferramentas complementares Suporte a Internacionalização Versão Trial Sim, na versão Professional ActionScript, Ada, C++, IDL (CORBA), Java, JavaScript, Perl, PHP, PHP5, Python, Ruby, SQL, TCL, XML Schema Sim Sim Não se aplica C++, C#, Java, PHP Java Sim Sim Não Sim Não se aplica Não Não se aplica 2.2 Conclusão Neste capítulo foi realizado um estudo sobre ferramentas CASE, apontando suas principais características, tais como: modo de distribuição, realização de engenharia reversa, suporte a XMI, entre outras; as quais foram resumidas e organizadas em um quadro. Este quadro é a principal contribuição deste capítulo, pois para desenvolvê-lo foi necessário um estudo das ferramentas através de várias referências bibliográficas e, também, através do uso de cada uma delas. Além disso, ele é importante porque apresenta de forma sucinta as semelhanças e diferenças entre as ferramentas estudadas sob vários aspectos, permitindo que um usuário possa facilmente identificar aquela que possui os recursos que ele necessita. Percebeu-se com este estudo que, embora existam diferenças entre as ferramentas proprietárias e as livres, todas possuem características parecidas, tanto no layout como nos recursos disponíveis. Isto permite concluir que o conhecimento 1 Apenas na versão JUDEProfessional.

34 33 adquirido em uma ferramenta possa ser usado de forma a permitir a um Engenheiro de Software usar qualquer outra sem grandes dificuldades. Outro ponto a destacar é o suporte ao XMI, uma novidade que está presente em todas as ferramentas estudadas, tendo como principal objetivo, fornecer as empresas uma forma fácil de integrar artefatos escritos em diferentes sistemas computacionais, ou seja, conforme documentação de cada CASE estudada, é possível a migração de um trabalho desenvolvido em uma das ferramentas CASE estudadas para outra ferramenta, devido as suas semelhanças.

35 34 3 GERAÇÃO DE CÓDIGO Este capítulo apresenta os principais conceitos de orientação a objetos necessários para o entendimento do trabalho. Cada conceito é representado através de um diagrama de classes que por sua vez é convertido em código expresso na linguagem Java. A modelagem e o processo de geração de código foram baseados em Wazlawick (2004), que explica como ocorre todo esse processo. 3.1 Classes e atributos Uma classe, segundo Barnes e Kölling (2004), descreve um objeto de um tipo em particular. A figura 8 mostra como uma classe do diagrama de classes é convertida em uma classe na linguagem de programação Java. FIGURA 8 - Mapeamento da classe Aluno para Java Os atributos armazenam dados para um objeto (BARNES e KÖLLING, 2004). Os atributos das classes são transformados em variáveis de instância privadas da classe como mostra a figura 9.

36 35 FIGURA 9 - Mapeamento da classe Aluno e seus atributos para Java As variáveis que armazenam os atributos, neste caso privadas, devem implementar métodos para acessar e alterar os valores de seus atributos. O quadro 8 mostra a implementação dos métodos assessores Getter e Setter que, respectivamente, fazem alteração e consulta nos atributos da classe da figura 9. Esses métodos não estão presentes no diagrama porque fazem parte dos atributos da classe. QUADRO 8 - Mapeamento de Sets e Gets da classe Aluno para Java package tccquadros; public class Aluno { private float altura; private String nome; private boolean pne; //portadores de necessidades especiais private char sexo; public void setaltura(float altura) {this.altura = altura;} public void setnome(string nome) {this.nome = nome;} public void setpne(boolean pne) {this.pne = pne;} public void setsexo(char sexo) {this.sexo = sexo;} public float getaltura(){return altura;} public String getnome(){return nome;} public boolean ispne(){return pne;} public char getsexo(){return sexo;} } public Aluno() {} 3.2 Associações As associações do diagrama de classes são transformadas em variáveis de instância no código em Java e têm métodos para modificação e consulta. Elas geram tipos e variáveis que são classes de objetos ou estruturas de dados, além de haver algumas distinções a fazer quanto aos métodos associados. De modo geral, cada associação deve implementar no mínimo três métodos:

37 36 um para criar a associação, um para destruir a associação e um para consultar os elementos associados. Esses métodos variam de acordo com a multiplicidade de cada associação, como mostram as subseções a Associação unidirecional com multiplicidade 1 A associação unidirecional para 1 deve ser armazenada em uma variável de instância na classe de origem da associação e seu tipo deve ser a classe de destino. Uma associação unidirecional para 1 de BoletoBancario para Aluno corresponde a uma variável de instância na classe BoletoBancario declarada com tipo Aluno. Como a associação é para 1, não é possível destruí-la, sendo que esse método não deve ser implementado. O método criador da classe deve ter como parâmetro o elemento a ser associado, para que todas as instâncias da classe na origem da associação estejam consistentes desde o início. A consulta, nesse caso, baseia-se no nome da classe no lado oposto da associação, sem parâmetros. A figura 10 mostra uma classe com associação unidirecional para 1 e o quadro 9 apresenta o código a ser implementado. FIGURA 10 - Classe com associação unidirecional para 1 QUADRO 9 - Mapeamento da classe com associação unidirecional para 1 em Java package tccquadros; public class BoletoBancario { private Aluno aluno; public BoletoBancario(Aluno alu) { this.setaluno(alu);} public void setaluno(aluno alu){ this.aluno = alu;} public Aluno getaluno(){ return this.aluno;} }

38 Associação unidirecional com multiplicidade 0..1 O procedimento de geração de código é semelhante ao da associação para 1, sendo que a consulta e a criação da associação são implementadas exatamente como no caso anterior. A diferença é que nesse caso é possível destruir a associação. Na figura 11 é mostrado uma classe com associação unidirecional para 0..1 e seu código é apresentado no quadro 10. FIGURA 11 - Classe com associação unidirecional para 0..1 QUADRO 10 - Mapeamento da classe com associação unidirecional para 0..1 em Java package tccquadros; public class BoletoBancario { private Pagamento pagamento; public BoletoBancario(){} public void setpagamento(pagamento pag){ this.pagamento = pag;} public void removepagamento(){ this.pagamento = null;} public Pagamento getpagamento(){ return this. pagamento;} } Associação unidirecional com multiplicidade * A associação unidirecional para * corresponde à implementação de um conjunto, constituindo-se pela implementação de uma variável do tipo Conjunto (Set em inglês), ou de acordo com as especificações da JPA (Java PersistenceAPI), pode ser uma Collection. Nesse caso, a variável que contém a associação tem seu nome no plural e seu tipo é Set. A classe Set, que representa o conjunto, possui um método add para associar elementos no conjunto e um método remove para desassociar elementos no conjunto. A figura 12 apresenta a classe com associação unidirecional com

39 38 multiplicidade para * e seu respectivo código é mostrado no quadro 11. A operação de consulta é getaluno, que retorna o Set com todos os alunos da turma. É possível implementar métodos de consulta para retornar alunos específicos ou subconjuntos de alunos, sendo que cada consulta seria um método distinto. Já na classe Aluno, não existe atributo que permita identificar um aluno, não sendo possível implementar uma consulta para retornar um aluno específico. Mas é possível implementar uma consulta que retorne o conjunto de todos os alunos que pertencem a uma turma num determinado tempo, conforme mostra o quadro 12. FIGURA 12 - Classe com associação unidirecional para * QUADRO 11 - Mapeamento da classe com associação unidirecional para * em Java package tccquadros; public class Turma { private Set alunos = new Set(); } public Turma() {} public void addaluno(aluno alu){ this.alunos.add(alu);} public void removealuno(aluno alu){ this.alunos.remove(alu);} public Set getaluno(){ return this.alunos;} QUADRO 12 - Método para consultar um subconjunto específico de alunos public Set getalunosdaturma(string turma){ Set alutur = new Set(); Aluno atual; alunos.start(); while(alunos.hasnext()){ atual = alunos.next(); if (atual.turma().equalsignorecase(turma)){ alutur.add(atual);} } return alutur;}}

40 Associação unidirecional com multiplicidade ordenada Quando a multiplicidade para * for ordenada, na implementação deve-se usar uma lista como estrutura de dados e não um conjunto. A associação ordenada é implementada de maneira semelhante à associação simples com multiplicidade *, com a diferença de ter dois métodos para desassociar. Além da forma de remoção usada no conjunto, também é possível desassociar um objeto indicando a posição em que ele se encontra. O método para associação de um elemento deve indicar a posição em que o elemento é inserido e podem ser implementadas variações do método de associação como addfirst e addlast. Uma forma de evitar alguns problemas como, por exemplo, associação ou desassociação em uma posição inválida, é tratar a lista como uma fila ou pilha, com métodos de associação e desassociação mais comportados que a lista, acessando assim, somente as extremidades dessas estruturas. A figura 13 mostra a associação ordenada entre Turma e Aluno, sendo muito semelhante à associação simples com multiplicidade *. Sua implementação é apresentada no quadro 13. FIGURA 13 - Classe com associação ordenada QUADRO 13 - Mapeamento da classe com associação ordenada para Java package tccquadros; import java.util.arraylist; public class Turma { private ArrayList alunos = new ArrayList(); public Turma() {} public void addaluno(aluno alu, int posicao){ this.alunos.add(posicao, alu);} public void removealuno(aluno alu){ this.alunos.remove(alu);} public void removealunonaposicao(int posicao){

41 40 } this.alunos.remove(posicao);} public ArrayList getalunos(){ return this.alunos;} public Aluno getalunonaposicao(int posicao){ return (Aluno) this.alunos.get(posicao);} Associação unidirecional qualificada Esta associação é implementada de forma muito parecida com a associação com multiplicidade *. Mas, ao invés de conjunto, é utilizada uma estrutura de dicionário (Map), associando o atributo qualificador ao objeto. Assim, é possível implementar um método de consulta que retorne um objeto da coleção se for dado um valor para o qualificador, como mostram a figura 14 e o quadro 14. O mapeamento é feito de String(nome) para Aluno, sendo que o conjunto de nomes é cadastro.get e o conjunto de alunos é cadastro.value. A operação de desassociação pode ser implementada de duas formas: pela chave e pelo valor. FIGURA 14 - Classe com associação qualificada QUADRO 14 - Mapeamento da classe com associação qualificada para Java package tccquadros; import java.util.map; public class Universidade { private Map cadastro = new Map(); public Universidade(){} public void addnocadastro(aluno alu){ this.cadastro.put(alu.getnome(), alu);} public void removedocadastro(aluno alu){ this.cadastro.remove(alu);} public void removedocadastropornome(string nome){ this.cadastro.remove(nome);} public Set getcadastro(){ return (Set) this.cadastro.values();} public Aluno getaluno(string nome){ return (Aluno) this.cadastro.get(nome);} }

42 Associação unidirecional com classe de associação Neste caso, é necessário implementar a criação e a remoção de instâncias da classe de associação, cada vez que uma associação é criada ou removida. Classes de associação podem existir em associações com qualquer multiplicidade, mas o mais comum é ser utilizada em associações de * para *. A implementação consiste em um Map, que associa instâncias do destino da associação a instâncias da classe de associação. Ao adicionar uma nova associação de Aluno com Curso, automaticamente é adicionado uma nova Matrícula na associação, sendo possível desassociar um elemento da associação por referência ao Curso (keyset) ou por Matrícula (values). A figura 15 mostra uma classe de associação e o quadro 15 mostra a implementação da associação na classe de origem. No último método do quadro 15 é apresentado como obter uma Matrícula específica a partir de um Curso. FIGURA 15 - Classe de associação QUADRO 15 - Mapeamento de classe de associação em Java package tccquadros; import java.util.map; public class Aluno { private Map cursos = new Map(); public Aluno() {} public void addcurso(curso curso){ this.cursos.put(curso, new Matricula());} public void removecurso(curso curso){ this.cursos.remove(curso);} public void removematricula(matricula matricula){

43 42 } this.cursos.remove(matricula);} public Set getcursos(){ return (Set) this.cursos.keyset();} public Set getmatriculas(){ return (Set) this.cursos.values();} public Matricula getmatriculanocurso(curso curso){ return (Matricula) this.cursos.get(curso);} Associação unidirecional com multiplicidade 1 na origem É necessário sempre observar se a multiplicidade na origem é 1 para todos os tipos de associação unidirecional definidos. Se for o caso, a destruição da associação só é possível quando o objeto também destrói o objeto no destino da associação, senão o objeto fica inconsistente, pois necessita estar associado a um elemento. O mesmo cuidado deve ser tomado em associações de 1 para 0..1 ou de 1 para Associação bidirecional Se a associação for bidirecional, ela deve ser implementada em ambas as classes, independente de a multiplicidade ser para 1, para 0..1 ou para *, sendo que cada lado da associação é implementado de acordo com as regras definidas anteriormente. Os métodos de criação e destruição da associação são uma das grandes diferenças da associação bidirecional com relação à unidirecional, devendo existir em cada uma das classes um método auxiliar para criar e destruir a associação e outro método para chamar esse método auxiliar. Se, em uma associação bidirecional, um dos lados tiver multiplicidade 1, não é possível implementar o método de destruição da associação, pois como já foi visto, uma associação para 1 não pode ser destruída. Por exemplo, se um Curso criar associação com um Aluno a e depois com um Aluno b, o Aluno a mantém uma referência inconsistente com o Curso, pois é necessário remover a associação que já existe antes de criar uma nova associação, sendo que esta situação também deve ser tratada no código.

44 43 Os métodos auxiliares associacursoaux, adicionacursoaux e removecursoaux, não devem ser públicos, mas exportados exclusivamente para a classe associada. Esses métodos não podem ser usados em outro lugar além dos métodos associaaluno e adicionaaluno. A figura 16 mostra uma associação de 1 para *, sendo este o caso mais comum. Sua implementação é apresentada nos quadros16 e 17. FIGURA 16 - Classe com associação bidirecional QUADRO 16 - Mapeamento da classe com associação bidirecional em Java para a classe Aluno package tccquadros; import java.util.set; public class Aluno { private Set cursos = new Set(); public Aluno() {} } public void addcursoaux(curso curso){ cursos.add(curso);} public void removecursoaux(curso curso){ cursos.remove(curso);} public void addcurso(curso curso){ if(curso.getaluno()!=null){ curso.getaluno().removecursoaux(curso); }; this.addcursoaux(curso); curso.addalunoaux(this);} public void removecurso(curso curso){ this.removecursoaux(curso); curso.destroi();} public Set getcursos(){ return (Set) this.cursos;} QUADRO 17 - Mapeamento da classe com associação bidirecional em Java para a classe Curso package tccquadros; public class Curso { private Aluno aluno; public Curso(Aluno aluno){

45 44 } this.addaluno(aluno); } public void addalunoaux(aluno aluno){ this.aluno = aluno;} public void addaluno(aluno aluno){ if(this.aluno!=null){ this.aluno.removecursoaux(this);} this.addalunoaux(aluno); aluno.addcursoaux(this);} public Aluno getaluno(){ return this.aluno;} 3.3 Agregação Uma agregação é um relacionamento do tipo todo-parte. Por exemplo, salas de aula são partes de um bloco. Se os blocos forem modelados por uma classe e as salas por outra classe, o relacionamento entre essas classes é uma agregação. Essas partes e o todo devem ser de mesma natureza fisica, para efetivamente ser considerado uma agregação. Na UML (Unified Modeling Language), uma agregação é identificada por uma linha que une as classes que fazem parte da agregação com um losango sem preenchimento em uma de suas extremidades, como mostra a figura 17. O losango é posicionado na extremidade que liga a classe que compõe o todo. Na agregação, a parte pode ou não pertencer a mais de um todo. Quando pertence a mais de um, há uma agregação compartilhada. Quando não puder pertencer a mais de um, há uma composição. FIGURA 17 - Agregação Na agregação compartilhada, por exemplo, a disciplina de Matemática pode pertencer aos cursos de Administração e de Sistemas de Informação. O mesmo

46 45 acontece com aluno: o aluno a pode pertencer a um curso ou mais. Uma agregação compartilhada é identificada na UML por um losango sem preenchimento, como mostra a figura 18. Seu código é apresentado no quadro 18. Na composição, quando o todo é destruído, as partes são também destruídas. Por exemplo, bloco e suas salas é uma composição, pois quando o bloco é destruído, suas salas também são destruídas. Uma composição é identificada na UML por um losango sólido, como mostra a figura 19 e seu código é apresentado no quadro 19. (ALBUQUERQUE, 1999). FIGURA 18 - Agregação compartilhada QUADRO 18 - Agregação compartilhada e seu código em Java package tccquadros; import java.util.set; public class Curso { private Set Disciplinas = new Set(); public Curso(){} public void adddisciplinas(disciplina disc){ this.disciplinas.add(disc);} public void removedisciplinas(disciplina disc){ this.disciplinas.remove(disc);} public Set getdisciplinas(){ return this.disciplinas;} } FIGURA 19 - Agregação por composição QUADRO 19 - Agregação por composição e seu código em Java package tccquadros; import java.util.set; public class Bloco {

47 46 private Set Salas = new Set(); } public Bloco() {} public void addsalas(sala sal){ this.salas.add(sal);} public void removesalas(sala sal){ this.salas.remove(sal);} public Set getsalas(){ return this.salas;} 3.4 Herança A herança é um mecanismo que fornece uma solução para problemas de duplicação: em vez de definir as classes Professor e TecnicoAdministrativo de forma completa e independente, primeiro define-se uma classe que contém tudo que essas duas classes têm em comum, que é exemplificada como Funcionario. Assim, Professor é um Funcionario e TecnicoAdministrativo é um Funcionario. Por fim, são adicionados detalhes extras necessários às classes Professor e TecnicoAdministrativo. A principal vantagem desta técnica é descrever os recursos comuns entre as classes somente uma vez. A figura 20 mostra as classes para essa estrutura, com a classe Funcionario na parte superior, definindo todos os atributos comuns para todos os funcionários (professor e técnico administrativo). Na parte inferior, estão as classes Professor e TecnicoAdministrativo, armazenando somente os atributos que são únicos para cada classe em particular. Cada classe (Professor e TecnicoAdministrativo) pode definir seus próprios métodos, como é exemplificado posteriormente. O mapeamento dessas classes de herança é apresentado no quadro 20. As setas no diagrama de classe (sem preenchimento) representam o relacionamento de herança. Em Java, utiliza-se a palavra extends para definir este mesmo relacionamento. A classe Funcionário é chamada superclasse, que é a classe da qual as outras classes herdam suas características. As classes Professor e TecnicoAdministrativo são as subclasses, ou seja, as classes que herdam a superclasse.

48 47 A herança permite criar duas classes que são semelhantes, ao mesmo tempo em que evita escrever a parte idêntica duas vezes (BARNES E KÖLLING, 2004). FIGURA 20 - Classes Professor e Técnico Administrativo herdando da classe Funcionário QUADRO 20 - Mapeamento das classes Professor e Técnico Administrativo herdando da classe Funcionário em Java public class Funcionario { private int cpf; private String endereco; private String nome; //construtores e metodos} public class Professor extends Funcionario { private float cargahoraria; private String departamento; private float valorhoraaula; //construtores e metodos} public class TecnicoAdministrativo extends Funcionario{ private float salariobase; private String setor; //construtores e metodos} Hierarquias de herança A herança pode ser utilizada de maneira mais geral do que foi mostrado na seção 3.4, na qual mais de duas subclasses podem herdar da mesma superclasse e uma subclasse pode ser uma superclasse para outras subclasses. Formando, assim, uma hierarquia de heranças. A figura 21 mostra um exemplo com uma pequena parte de hierarquia de heranças, sendo que um mestre é um professor, que é um funcionário. A herança é uma técnica de abstração que permite categorizar as classes de

49 48 objetos sob certos critérios e ajuda a especificar características dessas classes (BARNES e KÖLLING, 2004). FIGURA 21 - Exemplo de hierarquia de herança 3.5 Polimorfismo Polimorfismo é um código que pode ser aplicado a várias classes de objetos, sendo que a mesma mensagem é enviada a objetos de classes distintas, podendo elas reagirem de maneiras diferentes. O polimorfismo também permite que uma operação de uma mesma classe possa ser implementada por mais de um método. O usuário não precisa saber quantas implementações existem para uma operação, ou explicitar qual método deve ser utilizado, pois a linguagem de programação deve ser capaz de selecionar o método correto a partir do nome da operação, classe do objeto e argumentos para a operação. Desta forma, novas classes podem ser adicionadas sem a necessidade de modificação de código já existente, pois cada classe apenas define os seus métodos e atributos. (BLANCO, 2008). Segundo Novatec (2008), existem três formas de polimorfismo: inclusão, paramétrico e sobreposição. O polimorfismo de inclusão, também chamado de polimorfismo puro, permite a criação de métodos capazes de receber parâmetros de várias classes

50 49 diferentes, se pertencerem a uma árvore de herança. Também permitem que em um método, um parâmetro do tipo de uma classe base possa ser utilizado para receber objetos do tipo das classes especializadas. O polimorfismo paramétrico permite que se criem métodos e tipos genéricos. Pode-se, com ele, retirar das declarações de atributos, parâmetros de métodos e tipos de retorno de métodos, referências ao tipo de dado. A definição do tipo é adiada para o momento da execução. Esse tipo de polimorfismo não é suportado pelas linguagens de orientação a objetos, não tendo suporte na versão atual do Java. O polimorfismo de sobreposição dá suporte para que seja possível a especialização de classes. Esse tipo de polimorfismo permite redefinir um método em uma classe especializada, como mostra a figura 22, implementando um novo comportamento, apresentado no quadro 21. FIGURA 22 - Polimorfismo de sobreposição QUADRO 21 - Polimorfismo de sobreposição e seu código em Java public class abstract Funcionario{ private int cpf; private String endereco; private String nome; abstract public double calculesalariobruto(); } public class Professor extends Funcionario { private float cargahoraria; private String departamento; private float valorhoraaula;

51 50 public double calculesalariobruto(){ return ((this.cargahoraria * 4.5) * this.valorhoraaula);} } public class TecnicoAdministrativo extends Funcionario { private float salariobase; private String setor; public double calculesalariobruto(){ return ((this.salariobase)} } 3.6 Métodos delegados e operações/consultas de sistema As operações de sistema são métodos ativados a partir de um evento de sistema, ou seja, como resposta a uma ação do usuário, indicando um fluxo de informações do exterior para o interior do sistema, alterando assim, as informações do sistema. Consultas de sistema são métodos que correspondem à verificação de informação que já está armazenada, não podendo inserir, remover ou alterar essas informações. Os métodos delegados são usados para chamar os métodos de outros objetos e devem ser tratados da mesma forma que as operações de sistema (WAZLAWICK, 2004). A figura 23 mostra a classe Universidade (controlador) que possui a operação de sistema MatriculaAlunoNoCurso, a consulta de sistema RetorneFormandosDoCurso e a classe Curso com o método delegado MatriculaAluno. Na implementação da operação de sistema, como mostra o quadro 22, percebe-se a chamada ao método delegado por meio de uma instância da classe Curso. FIGURA 23 - Operação e consulta de sistema e método delegado QUADRO 22 - Implementação da operação de sistema e do método delegado

52 51 package tccquadros; public class Universidade { Curso cursoatual; public void matriculaalunonocurso(string nomealuno){ cursoatual.matriculaaluno(nomealuno);} public Set retorneformandosdocurso(){ return cursoatual.retorneformandos;} } 3.7 Interface Interface é um mecanismo simplificado de implementação de herança múltipla em Java que permite que mais de uma interface determine os métodos que uma classe herdeira deve implementar. As interfaces especificam formas de acesso e não como algo deve ser implementado, aumentando assim, a coesão. Isto permite ao desenvolvedor criar implementações específicas para interfaces de forma a não infligir uma especificação prévia (SANTOS, 2003). Se uma classe não tiver nenhum método não-abstrato, pode-se criá-la como uma interface, que possui um modo de declaração diferente do utilizado para classes, mas tem a mesma funcionalidade de classes abstratas. A sintaxe para definição de uma interface é semelhante à utilizada na definição de classes. Todos os métodos em uma interface são implicitamente abstratos e públicos. Interfaces não podem ter atributos, mas podem possuir constantes definidas. Uma vez definida, a interface é compilada normalmente (um arquivo.class é gerado, como se fosse uma classe qualquer). Uma classe pode ainda implementar mais de uma interface, neste caso, elas são colocadas lado a lado, separadas por vírgula juntamente com a cláusula implements. Quando uma classe implementa uma interface, ela deve obrigatoriamente implementar os métodos definidos nesta interface (BARTH, 2008). As interfaces são declaradas com a palavra-chave interface e não com a palavra class (SANTOS, 2003), como mostra a figura 24. Seu código é apresentado no quadro 23.

53 52 FIGURA 24 - Interface QUADRO 23 - Interface e seu código em Java package tccquadros; public interface BancodeDados{ public void consultar(); public void alterar(); public void excluir(); public void incluir();} public class BancodeDadosA implements BancodeDados { public void inserir(){} public void excluir(){} public void alterar(){} public void consultar(){}} public class BancodeDadosB implements BancodeDados { public void inserir(){} public void excluir(){} public void alterar(){} public void consultar(){}} 3.8 Conclusão Como existem regras bem definidas para a tradução de um diagrama de classes para código orientado a objetos, é possível criar um algoritmo com as regras ou passos a serem realizados para que esta tradução seja feita de forma correta. A partir dessas regras, pode-se gerar um código, diminuindo a complexidade da programação. Além disso, com o código resultante, pode-se verificar se os códigos gerados pela ferramenta CASE a partir de um dado diagrama de classes estão corretos ou não.

54 53 Caso esses códigos não estejam corretos, é possível identificar o erro, sendo este o principal objetivo do capítulo 4. Apesar de Wazlawick (2004) ser a base para a elaboração do capítulo 3, muitos conceitos de orientação a objetos necessitaram de uma abordagem em outras referências. Isto foi necessário para facilitar o entendimento dos conceitos, tanto do ponto de vista da modelagem quanto da implementação orientada a objetos, e para realizar o aprofundamento necessário para geração de código. O entendimento destes conceitos constitui-se em uma das maiores dificuldades enfrentadas na elaboração do capítulo, tornando complexa também a elaboração de exemplos relacionados aos conceitos, dentro de um mesmo estudo de caso.

55 54 4 ANÁLISE DE CÓDIGO GERADO A PARTIR DE DIAGRAMA DE CLASSES Este capítulo mostra como realizar a geração de código na ferramenta CASE (Computer-Aided Software Engineering) Enterprise Architect, a partir de exemplos de diagramas de classes desenvolvidos nesta mesma ferramenta, apresentando diversos conceitos de orientação a objetos abordados no capítulo 3 deste trabalho. Além disso, apresentam-se algumas sugestões para corrigir os códigos gerados de forma inconsistente. 4.1 Geração de código na ferramenta CASE Enterprise Architect No EA (Enterprise Architect), após a conclusão do diagrama de classes, a etapa de geração deve passar pelos seguintes passos: Ao criar uma classe, deve-se escolher a linguagem em que o código deve ser criado, através da opção Language, neste caso, Java; Verificar se a opção View Toolbars Code Generation está habilitada para que o usuário tenha acesso aos ícones de geração de código, como apresenta a figura 25; FIGURA 25 - Barra de ferramentas para geração de código Através da janela Local Options, no menu Tools Options, seleciona-se Java Specifications. É necessário configurar a linguagem que será utilizada, indicando qual sua extensão, o tipo de atributo padrão e os prefixos de get e set, como mostra a figura 26;

56 55 FIGURA 26 - Configuração da linguagem em que o código será gerado Ainda na janela Local Options, é necessário clicar em Collection Class para definir qual o tipo de objeto será utilizado nas associações para *. Neste caso, utiliza-se Set, HashMap e ArrayList, como mostra a figura 27. Caso estes tipos de objetos não sejam definidos, será gerada uma instância da classe origem e não uma coleção de instâncias; FIGURA 27 - Definição dos objetos Para que no código gerado apareçam os métodos get e set, que fazem parte dos