Baixe o app para aproveitar ainda mais
Prévia do material em texto
PROGRAMAÇÃO III PROFESSORES Dr. Edson Alves de Oliveira Junior Me. Andre Abdala Noel Me. Márcia Cristina Dadalto Pascutti Me. Rafael Alves Florindo Esp. Janaina Aparecida de Freitas Esp. Victor de Marqui Pedroso EXPEDIENTE C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Distância. NOEL, Andre Abdala; OLIVEIRA JR, Edson Alves de; FREITAS, Janaina Aparecida de; PASCUTTI, Márcia Cris- tina Dadalto; FLORINDO, Rafael Alves; PEDROSO, Victor de Marqui. Programação III. Andre Abdala Noel, Edson Alves de Oliveira Junior, Janaina Apa- recida de Freitas, Márcia Cristina Dadalto Pascutti, Rafael Alves Florindo e Victor de Marqui Pedroso. Maringá - PR.: UniCesumar, 2020. 216 p. “Graduação - EaD”. 1. Programação 2. Software 3. Sistema. EaD. I. Título. FICHA CATALOGRÁFICA NEAD - Núcleo de Educação a Distância Av. Guedner, 1610, Bloco 4 Jd. Aclimação - Cep 87050-900 | Maringá - Paraná www.unicesumar.edu.br | 0800 600 6360 Coordenador(a) de Conteúdo Danillo Xavier Saes Projeto Gráfico e Capa Arthur Cantareli, Jhonny Coelho e Thayla Guimarães Editoração Sabrina Maria Pereira de Novaes Design Educacional Rossana Costa Giani Revisão Textual Ariane Andrade Fabreti Ilustração Marta Sayuri Kakitani Fotos Shutterstock CDD - 22 ed. 005.1 CIP - NBR 12899 - AACR/2 ISBN 978-85-459-1712-0 Impresso por: Bibliotecário: João Vivaldo de Souza CRB- 9-1679 Diretoria Executiva Chrystiano Mincoff, James Prestes, Tiago Stachon Diretoria de Design Educacional Débora Leite Diretoria de Graduação Kátia Coelho Diretoria de Permanência Leonardo Spaine Diretoria de Pós-graduação, Extensão e Formação Acadêmica Bruno Jorge Head de Produção de Conteúdos Celso Luiz Braga de Souza Filho Gerência de Produção de Conteúdo Diogo Ribeiro Garcia Gerência de Projetos Especiais Daniel Fuverki Hey Supervisão do Núcleo de Produção de Materiais Nádila Toledo Supervisão de Projetos Especiais Yasminn Zagonel NEAD - NÚCLEO DE EDUCAÇÃO A DISTÂNCIA Reitor Wilson de Matos Silva Vice-Reitor Wilson de Matos Silva Filho Pró-Reitor de Administração Wilson de Matos Silva Filho Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva Pró-Reitor de Ensino de EAD Janes Fidélis Tomelin Presidente da Mantenedora Cláudio Ferdinandi DIREÇÃO UNICESUMAR BOAS-VINDAS Neste mundo globalizado e dinâmico, nós tra- balhamos com princípios éticos e profissiona- lismo, não somente para oferecer educação de qualidade, como, acima de tudo, gerar a con- versão integral das pessoas ao conhecimento. Baseamo-nos em 4 pilares: intelectual, profis- sional, emocional e espiritual. Assim, iniciamos a Unicesumar em 1990, com dois cursos de graduação e 180 alunos. Hoje, temos mais de 100 mil estudantes espalhados em todo o Brasil, nos quatro campi presenciais (Maringá, Londrina, Curitiba e Ponta Grossa) e em mais de 500 polos de educação a distância espalhados por todos os estados do Brasil e, também, no exterior, com dezenasde cursos de graduação e pós-graduação. Por ano, pro- duzimos e revisamos 500 livros e distribuímos mais de 500 mil exemplares. Somos reconhe- cidos pelo MEC como uma instituição de exce- lência, com IGC 4 por sete anos consecutivos e estamos entre os 10 maiores grupos educa- cionais do Brasil. A rapidez do mundo moderno exige dos edu- cadores soluções inteligentes para as neces- sidades de todos. Para continuar relevante, a instituição de educação precisa ter, pelo menos, três virtudes: inovação, coragem e compromis- so com a qualidade. Por isso, desenvolvemos, para os cursos de Engenharia, metodologias ati- vas, as quais visam reunir o melhor do ensino presencial e a distância. Reitor Wilson de Matos Silva Tudo isso para honrarmos a nossa mis- são, que é promover a educação de qua- lidade nas diferentes áreas do conheci- mento, formando profissionais cidadãos que contribuam para o desenvolvimento de uma sociedade justa e solidária. P R O F I S S I O N A LT R A J E T Ó R I A Dr. Edson Alves de Oliveira Junior Pós-Doutorando em Experimentação em Computação Forense na PUC-RS. Possui doutorado em Ciências de Computação e Matemática Computacional pelo Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo (ICMC- -USP). Possui mestrado e graduação em Ciência da Computação pela Universidade Estadual de Maringá (UEM). Professor adjunto do Departamento de Informática (DIN) da Universidade Estadual de Maringá (UEM). Possui experiência na área de Ciência da Computação, com ênfase em Engenharia de Software, atuando, principal- mente, nos seguintes temas: Processos de Software, Linha de Produto de Software, Avaliação de Arquitetura de Software e de Linhas de Produto, Linha de Processo de Software, Gerenciamento de Variabilidades, Métricas e Modelos de Software, Frameworks, Modelagem e Metamodelagem UML, Ambientes de Desenvolvimento e Tecnologias Java. http://lattes.cnpq.br/8717980588591239. Me. Márcia Cristina Dadalto Pascutti Possui mestrado em Ciência da Computação pela Universidade Federal do Rio Gran- de do Sul (2002) e graduação em Processamento de Dados pela Universidade Es- tadual de Maringá (1989). Atualmente, é professora no Instituto Federal do Paraná - Campus Umuarama, e está cursando o doutorado na PUC-PR. Atua, principalmente, nos seguintes temas: arquitetura de computadores, engenharia de software, proces- samento de imagens, reconhecimento de padrões, visão computacional. http://lattes.cnpq.br/0297217008123332 Me. Andre Abdala Noel Mestre em Ciência da Computação pela Universidade Estadual de Maringá, com ênfase em sistemas de computação e bacharel em Ciência da Computação pela Universidade Estadual de Maringá. É professor e programador. Possui boa experiência em programação, aplicando, também, na docência superior, desde 2008. Autor do site Vida de Programador, mantém-se ativo na comunidade de desenvolvedores. http://lattes.cnpq.br/9035823171388697 P R O F I S S I O N A LT R A J E T Ó R I A Esp. Janaina Aparecida de Freitas Possui graduação em Informática pela Universidade Estadual de Maringá (2010) e especialização em MBA em Teste de Software pela UNICEUMA (2012). Atualmente, cursa o Programa de Mestrado em Ciência da Computação na Universidade Estadual de Maringá (UEM) e é graduanda de Letras – Português/Inglês na Unicesumar. Atua como professora mediadora, professora conteudista em gravação de aulas ao vivo e gravação de aulas conceituais nos cursos do NEAD – Núcleo de Educação a Distância – da Unicesumar, para os cursos de graduação de Sistemas para Internet, Análise e Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia de Software, nas disciplinas de Engenharia de Software, Design Gráfico, Tópicos Especiais, Gerenciamento de Software, Design de Interação Humano-Computador, Projeto Implementação e Teste de Software. Além disso, tem experiência em inicia- tiva privada na área de Análise de Sistemas e Testes de Software. http://lattes.cnpq.br/4906244382612830 Esp. Victor de Marqui Pedroso Possui Pós-Graduação em Banco de dados Oracle e DB2 pelo Centro Universitário de Maringá (2009) e graduação em Tecnologia em Processamento de Dados pelo Centro Universitário de Maringá (2003). Tem experiência como analista de sistemas, documentador, homologador e programador de software. Possui experiência em desenvolvimento utilizando a ferramenta Delphi. Já trabalhou como Professor Me- diador e, atualmente, trabalha como Professor Formador dos cursos de Análise e Desenvolvimento de Sistemas e Sistemas para Internet, ministrando as disciplinas de Banco de Dados e Design de Interação. http://lattes.cnpq.br/8611697826182780 Me. Rafael Alves Florindo Mestrado em Gestão do Conhecimento nas Organizações na linha de pesquisa Edu- cação e Conhecimento pela PPGGCO – Unicesumar – Centro Universitário de Maringá (2017). É especialista em Desenvolvimento de Sistema para Web pela UEM – Universi- dade Estadual de Maringá (2008). Graduado em Ciência da Computação pela FAI – Fa- culdadesAdamantinenses Integrada. Pós-graduando em Docência no Ensino Superior: Tecnologias Educacionais e Inovação e Banco de Dados pela Unicesumar. Professor – Ensino Técnico pela SEED-PR desde 2009. Professor autor, formador e mediador do EAD - Ensino a Distância da Unicesumar desde 2014, nos Cursos de TI: Sistemas para Internet, Análise e Desenvolvimento de Sistemas, Gestão da Tecnologia da Informação e Engenharia de Software. Professor presencial da Faculdade Unifamma desde 2019, no curso de Engenharia de Software e Sistema de Informação. http://lattes.cnpq.br/7246554526271622 D A D I S C I P L I N AA P R E S E N TA Ç Ã O PROGRAMAÇÃO III Seja bem-vindo(a)! Prezado(a) acadêmico(a), é com muito prazer que lhe apresentamos o livro de Programação III. Este livro está organizado em cinco unidades e todas estão, estreitamente, relacionadas. Na Unidade 1, apresentaremos alguns conceitos referentes à disciplina. Você notará, durante a leitura das outras unidades, que esses conceitos são utilizados com frequência. A engenharia de software surgiu mediante a necessidade de tornar o desenvolvimento de software confiável, com etapas bem definidas, custo e cronograma previsíveis, fatos que não aconteciam até 1968, quando o termo engenharia de software foi proposto. Além disso, gosta- ríamos de ressaltar que o software compreende, além dos programas, toda a documentação referente a ele, e a engenharia de software é a disciplina que trata dessa documentação. Na Unidade 2, daremos início à aplicação dos conhecimentos da engenharia de software na linguagem de programação Java. Abordaremos, primeiramente, os conceitos relacionados a modificadores de acesso e a encapsulamento. Esses recursos formam um dos pilares da programação orientada a objetos, recurso este que garante a integridade e o controle de acesso aos atributos e métodos. Continuando a aplicação dos conceitos de engenharia de software, na Unidade 3, abarcaremos mais dois pilares da programação orientada a objetos: a herança e o polimorfismo. Ambos estão relacionados, uma vez que, a partir do recurso da herança, ou seja, quando o filho herda A P R E S E N TA Ç Ã O D A D I S C I P L I N A características do pai, é possível especializar alguma operação. Nesse caso, temos que o filho pode implementar uma ação que o pai desenvolve, contudo ela pode ser diferente ou igual. Na Unidade 4, abordaremos algumas regras de desenvolvimento. A primeira será as classes abstratas, que funcionarão como modelo de desenvolvimento para outras classes que estão recebendo herança dela, ou seja, a classe que herda de uma classe abstrata deve implementar os métodos que estão marcados para serem implementados nas classes filhas. Outra regra é a interface, esta rege um contrato entre analista e desenvolvedor; aqui, quando construímos uma interface e uma classe a implementa, ela é obrigada a implementar todos os métodos, funcionando, assim, como um contrato. Finalmente, chegamos à última unidade do nosso material. Esta unidade é o fechamento das etapas do processo de software, onde realizaremos a implementação de um estudo de caso por meio da realização da nova análise desse estudo, agora, na visão do desenvolvedor. Assim, chegamos ao final do nosso livro. Esperamos, sinceramente, que a sua leitura seja agradável e que este conteúdo possa contribuir para o seu crescimento pessoal, acadêmico e profissional. ÍCONES Sabe aquela palavra ou aquele termo que você não conhece? Este ele- mento ajudará você a conceituá-la(o) melhor da maneira mais simples. conceituando No fim da unidade, o tema em estudo aparecerá de forma resumida para ajudar você a fixar e a memorizar melhor os conceitos aprendidos. quadro-resumo Neste elemento, você fará uma pausa para conhecer um pouco mais sobre o assunto em estudo e aprenderá novos conceitos. explorando Ideias Ao longo do livro, você será convidado(a) a refletir, questionar e transformar. Aproveite este momento! pensando juntos Enquanto estuda, você encontrará conteúdos relevantes online e aprenderá de maneira interativa usando a tecno- logia a seu favor. conecte-se Quando identificar o ícone de QR-CODE, utilize o aplicativo Unicesumar Experience para ter acesso aos conteúdos online. O download do aplicativo está disponível nas plataformas: Google Play App Store CONTEÚDO PROGRAMÁTICO UNIDADE 01 UNIDADE 02 UNIDADE 03 UNIDADE 05 UNIDADE 04 FECHAMENTO MODELAGEM DE SISTEMAS 10 MODIFICADORES JAVA E ENCAPSULAMENTO 45 78 HERANÇA E POLIMORFISMO 115 CLASSES ABSTRATAS E INTERFACES 150 ESTUDO DE CASO: ANÁLISE CLÍNICA 202 CONCLUSÃO GERAL 1 MODELAGEM DE SISTEMAS PLANO DE ESTUDO A seguir, apresentam-se as aulas que você estudará nesta unidade: • Modelagem de sistemas • Ferra- mentas CASE (Computer-Aided Software Engineering) • Introdução à UML (Unified Modeling Langua- ge) • Conceitos básicos de orientação a objetos • Diagrama de classes. OBJETIVOS DE APRENDIZAGEM • Expor a importância da modelagem de sistemas • Entender as Ferramentas CASE (Computer-Aided Software Engineering) • Entender a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) • Apresentar os conceitos básicos de orientação a objetos • Entender a estrutura do sistema por meio de elementos, tais como classes, atributos e associações entre os objetos. PROFESSORES Dr. Edson Alves de Oliveira Junior Me. Andre Abdala Noel Me. Márcia Cristina Dadalto Pascutti Me. Rafael Alves Florindo Esp. Janaina Aparecida de Freitas Esp. Victor de Marqui Pedroso INTRODUÇÃO Caro(a) aluno(a), nesta primeira unidade, você verá uma revisão dos conceitos de modelagem de sistema. Este é o processo de elaboração de modelos abstratos de um sistema, normalmente, representado por meio de um diagrama, em que cada um desses modelos apresenta uma visão ou uma perspectiva diferente do sistema (SOMMERVILLE, 2011). Esses modelos, normalmente, são elaborados utilizando uma notação gráfica, que, em nosso caso, será a UML(Unified Modeling Language ou Lingua- gem de Modelagem Unificada). A UML define, em sua versão atual, 21 tipos de diagramas para o uso na modelagem de software. Nesta unidade, veremos, somente, o diagrama de classe. Se você quiser conhecer os outros, consulte alguns livros relacio- nados nas referências. Como nosso objetivo, aqui, é mostrar a modelagem de um sistema, utilizaremos, somente, esse diagrama. Primeiramente, exporemos a importância de realizar a modelagem de um sistema de software. Esta se baseia na utilização de notações gráficas e textuais com o objetivo de construir modelos que representem as partes essenciais de um sistema. Depois, passaremos a entender as Ferramentas CASE (Computer-aided Software Engineering) e UML (Unified Modeling Language ou Linguagem de Modelagem Unificada). Todos os artefatos de software produzidos durante a modelagem serão usados como base para as fases seguintes do ciclo de desenvolvimento de sistemas, como as fases de projeto e de implementação. Em seguida, apresentaremos a você os conceitos básicos de Orientação a Objetos (OO) para entender, por meio de elementos, a estrutura do sistema. Por último, mostraremos o diagrama de classes. Este é o mais importante e, também, o mais utilizado da UML, além de servir de apoio para a maioria dos diagramas. O diagrama de classes define a estrutura das classes identi- ficadas para o sistema, mostrando os atributos e os métodos de cada uma, além de estabelecer como elas se relacionam e trocam informações entre si. U N ID A D E 1 12 1 MODELAGEM DE SISTEMAS Caro(a) aluno(a), a necessidade de planejamento no desenvolvimento de sistemas de informação leva ao conceito de modelagem de software, ou seja, antes de o software ser concebido, deve-se criar um modelo para ele. Um modelo pode ser entendido como uma representação idealizada de um sistema a ser construído. São exemplos: maquetes de edifício, plantas de casa, fluxogramas etc. A modelagem de sistemas de software se baseiana utilização de notações gráficas e textuais com o objetivo de construir modelos que representem as partes essenciais de um sistema. São várias as razões para utilizar modelos na construção de sistemas: 1. No desenvolvimento do software, usamos desenhos gráficos denomina- dos diagramas, a fim de representar o comportamento do sistema. Esses diagramas seguem um padrão lógico e possuem uma série de elementos gráficos que carregam um significado pré-definido. 2. Apesar de um diagrama expressar diversas informações de forma gráfica, em diversos momentos, há a necessidade de adicionar informações em forma de texto, com o objetivo de explicar ou definir certas partes. A modelagem de um sistema em forma de diagrama, em conjunto com a informação textual, forma a documentação de um sistema de software. 3. O rápido crescimento da capacidade computacional das máquinas re- sultou na demanda de sistemas de software cada vez mais complexos, que tirassem proveito de tal capacidade. Por sua vez, o surgimento desses U N IC ES U M A R 13 sistemas gerou a necessidade de reavaliação no desenvolvimento de siste- mas. Desde o aparecimento do primeiro computador até os dias de hoje, as técnicas para a construção de sistemas computacionais têm evoluído para suprir as necessidades do desenvolvimento de software. A seguir, a Figura 1 ilustra um parâmetro histórico da evolução digital: O processo de desenvolvimento de software é uma atividade bastante complexa. Isto se reflete no alto número de projetos de software que não chegam ao fim ou que Os sistemas de software eram bastante simples e, dessa forma, as técnicas de modelagem também. Era a época dos �uxogramas e diagramas de módulos. Nesta época, houve a expansão do mercado computacional. Sistemas complexos começavam a surgir e, por consequência, modelos mais robustos foram propostos. Além disso, surge a programação estruturada e, no �nal da década, a análise e o projeto estruturado. Surge a necessidade de interfaces homem-máquina mais so�sticadas, o que originou a produção de sistemas de software mais complexos. A análise estruturada se conso- lidou na primeira metade da década, e, em 1989, Edward Yourdon lançou o livro Análise Estrutura- da Moderna, tornando-se referência no assunto. Inicia-se um novo paradigma de modelagem, a análise orientada a objetos, como resposta para as di�culdades encontradas na aplicação da análise estruturada em certos domínios de aplicação. O paradigma da orientação a objetos atinge a sua maturidade. Os conceitos de padrões de projetos (design patterns), frameworks de desenvolvimen- to, componentes e padrões de qualidade começam a ganhar espaço. Surge, também, a Linguagem de Modelagem Uni�cada (UML), que é a ferramenta de modelagem utilizada no desenvolvimento atual de sistemas. 1950/60 Era a época dos �uxogramas e diagramas de módulos 1970 Expansão do mercado tecnológico 1980 Sistema da interface de usuário 1990 Novo paradigma de modelagem de sistemas de software 1990 e atualidade Maturidade Digital Figura 1 - Parâmetros históricos da evolução dos modelos na construção de sistemas. Fonte: os autores. U N ID A D E 1 14 Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um sistema, em que cada modelo apresenta uma visão ou perspectiva diferente desse. A modelagem, geralmente, representa o sistema com algum tipo de notação gráfica que, atualmente, quase sempre, é baseada em notações de UML (linguagem de modelagem unificada, do inglês Unified Modeling Language). Os modelos são usados durante o pro- cesso de engenharia de requisitos para ajudar a extrair os requisitos do sistema; duran- te o processo de projeto, são usados para descrever o sistema aos engenheiros que o implementam; e, após isso, são usados para documentar a estrutura e a operação do sistema. Um modelo é uma abstração do sistema a ser estudado, e não uma representa- ção alternativa dele. Idealmente, uma representação deve manter todas as informações sobre a entidade representada. Uma abstração, deliberadamente, simplifica e seleciona as características mais salientes. Fonte: adaptado de Sommerville (2011, p. 96). explorando Ideias extrapolam recursos de tempo e de dinheiro alocados. Em um estudo clássico sobre projetos de desenvolvimento de software, realizado em 1994, constatou-se que: ■ Porcentagem de projetos que terminam dentro do prazo estimado: 10%. ■ Porcentagem de projetos que são descontinuados antes de chegarem ao fim: 25%. ■ Porcentagem de projetos acima do custo esperado: 60%. ■ Atraso médio nos projetos: um ano. Os modelos construídos na fase de análise devem ser, cuidadosamente, validados e verificados. O objetivo da validação é o de assegurar que as necessidades do cliente es- tão sendo atendidas. Nessa atividade, os analistas apresentam os modelos criados para representar o sistema aos futuros usuários a fim de que esses modelos sejam validados. Já a verificação objetiva analisar se os modelos construídos estão em conformi- dade com os requisitos definidos. Na verificação dos modelos, é analisada a exatidão de cada um, separadamente, bem como a consistência entre eles. A verificação é uma etapa típica da fase de projeto e é a próxima etapa do desenvolvimento de software. Caro(a) aluno(a), utilizaremos a UML para realizar a modelagem de sistemas. Nesse primeiro tópico, estudamos alguns conceitos relacionados à orientação de objetos e fizemos uma introdução à linguagem UML. Lembre-se de que os artefatos de software produzidos durante a modelagem servirão de base para a fase seguinte do ciclo de desenvolvimento de sistemas, ou seja, a fase de projeto. U N IC ES U M A R 15 2 FERRAMENTAS CASE (Computer-Aided Software Engineering) Uma ferramenta CASE é um software que pode ser utilizado para apoiar as ati- vidades do processo de software, como a engenharia de requisitos, o projeto, o desenvolvimento de programa e os testes. As ferramentas CASE podem incluir editores de projeto, dicionários de dados, compiladores, depuradores, ferramentas de construção de sistemas, entre outros (SOMMERVILLE, 2011). Sommerville (2011) expõe alguns exemplos de atividades que podem ser automatizadas utilizando a CASE. Dentre elas, estão: 1. O desenvolvimento de modelos gráficos de sistemas enquanto parte das especificações de requisitos ou do projeto de software. 2. A compreensão de um projeto utilizando um dicionário de dados que carrega informações sobre as entidades e a sua relação em um projeto. 3. A geração de interfaces com usuários a partir de uma descrição gráfica da interface, que é criada interativamente pelo usuário. 4. A depuração de programas pelo fornecimento de informações sobre um programa em execução. 5. A tradução automatizada de programas a partir da antiga versão de uma linguagem de programação, como a Cobol, para uma versão mais recente. A tecnologia CASE está, atualmente, disponível para a maioria das atividades de rotina no processo de software, proporcionando, assim, algumas melhorias na qualidade e na produtividade de software. U N ID A D E 1 16 Existem, basicamente, duas formas de classificação geral para as ferramentas CASE. A primeira delas divide-se em: Upper CASE, Lower CASE, Integrated- -CASE e Best in Class: ■ Upper CASE ou U-CASE ou Front-End: são as ferramentas voltadas para as primeiras fases do processo de desenvolvimento de sistemas, como a análise de requisitos, o projeto lógico e a documentação. São uti- lizadas por analistas e pessoas mais interessadas na solução do problema do que na implementação. ■ Lower CASE ou L-CASE ou Back-End: são, praticamente, o oposto das ferramentas Upper CASE. Elas oferecem suporte nas últimas fases do desenvolvimento, como a codificação, os testes e a manutenção. ■ Integrated CASE ou I-CASE: são ferramentas que, além de englobarem características das Upper e Lower CASEs, oferecem, ainda, outras carac- terísticas, como controle de versão,por exemplo. Entretanto são utiliza- das somente em projetos de desenvolvimento muito extensos, por serem bastante caras e difíceis de operar. ■ Best in Class ou Kit de Ferramenta: semelhante às I-CASEs, os Kits de Fer- ramenta, também, acompanham todo o ciclo de desenvolvimento. Entretanto possuem a propriedade de conjugar a sua capacidade a outras ferramentas externas complementares, as quais variam de acordo com as necessidades do usuário. Para melhor entendimento, podemos compará-las a um computador sem o kit multimídia: as Best in Class seriam o computador que funciona nor- malmente, enquanto as outras ferramentas fariam o papel do kit multimídia, promovendo mais potencial de trabalho para a máquina. São mais usadas para o desenvolvimento corporativo, apresentando controle de acesso, versão e repositórios de dados, entre outras características. A segunda forma divide as ferramentas CASE em orientadas à função e em orien- tadas à atividade: ■ Orientadas à função: seriam as Upper CASE e Lower CASE. Baseiam- -se na funcionalidade das ferramentas, ou seja, são as que têm funções diferentes no ciclo de vida de um projeto. Por exemplo, a representação, apenas, do Diagrama de Entidades e Relacionamentos (DER) ou do Dia- grama de Fluxo de Dados (DFD). ■ Orientadas à atividade: seriam as Best in Class e as I-CASE, as quais pro- cessam atividades, tais como especificações, modelagem e implementação. U N IC ES U M A R 17 Além dos ambientes completos de engenharia de software, ferramentas de solução pon- tual que resolvem tudo, desde reunião de requisitos até refatoração de projeto/código e teste, continuarão a evoluir e se tornarão mais capazes em funcionalidade. (Roger Pressman e Bruce Maxim) pensando juntos 3 INTRODUÇÃO À UML (Unified Modeling Language) Segundo Booch, Rumbaugh e Jacobson (2006, p. 13), “a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de projetos de software”, podendo ser utilizada para visualização, especificação, construção e documentação de artefatos de soft- ware, por meio do paradigma de orientação a objetos. Além disso, a UML é a linguagem-padrão de modelagem de software adotada, internacionalmente, pela indústria de engenharia de software (GUEDES, 2007). A UML não é uma linguagem de programação, mas uma linguagem de modelagem cuja meta é auxiliar os engenheiros de software a definirem as características do softwa- re, tais como: os seus requisitos, o seu comportamento, a sua estrutura lógica, a dinâmica de seus processos e, até mesmo, as suas necessidades físicas em relação ao equipamento em que o sistema deverá ser implantado. Todas essas características são definidas por meio da UML antes do início do desenvolvimento do software (GUEDES, 2007). U N ID A D E 1 18 De acordo com Booch, Rumbaugh e Jacobson (2006), a UML é apenas uma linguagem de modelagem e, também, é independente de processo de software, visto que pode ser utilizada em modelo cascata, em desenvolvimento evolucioná- rio ou em qualquer outro processo utilizado para o desenvolvimento do software. A notação UML utiliza diversos símbolos gráficos, existindo uma se- mântica bem definida para cada um deles, o que permite elaborar diversos modelos. Além disso, a UML tem sido empregada, de maneira efetiva, em sistemas cujos domínios abrangem os sistemas de informações corporativos, os serviços bancários e os financeiros, os transportes, os serviços distribuídos baseados na web, entre outros. No entanto ela não se limita à modelagem de software, pois pode modelar sistemas, tais como o fluxo de trabalho no sis- tema legal, a estrutura e o comportamento de sistemas de saúde e o projeto de hardware (BOOCH; RUMBAUGH; JACOBSON, 2006). Ferramentas Case baseadas na Linguagem UML Nesta unidade, já constatamos que as ferramentas CASE (Computer-Aided Soft- ware Engineering – Engenharia de Software Auxiliada por Computador, em por- tuguês) são softwares que, de alguma forma, colaboram na realização de uma ou mais atividades realizadas durante o processo de desenvolvimento de software. Agora, veremos alguns exemplos de ferramentas CASE que suportam a UML, a qual é, em geral, a sua principal característica. Existem várias delas no mercado, dentre as quais podemos destacar: ■ Rational Rose: esta ferramenta foi desenvolvida pela Rational Software Corporation, empresa que estimulou a criação da UML, sendo a primeira ferramenta CASE baseada nessa linguagem. Atualmente, a Rational Rose é bastante usada pelas empresas desenvolvedoras de software. Ela permite a modelagem dos diversos diagramas da UML e a construção de modelos de dados com a possibilidade de exportação para a construção da base de dados ou a realização de engenharia reversa de uma base de dados existente. Em 20 de fevereiro de 2003, a empresa Rational foi adquirida pela IBM, e a ferramenta foi renomeada como IBM Rational Architect. U N IC ES U M A R 19 ■ Astah Professional: é uma ferramenta para a criação de diagramas UML e possui uma versão gratuita, o Astah Community, bem como outras ver- sões pagas. A versão gratuita possui algumas restrições de funções, porém, para as que necessitaremos nesta unidade, ela será suficiente. Portanto, será essa a ferramenta que utilizaremos para modelar os diagramas da UML que aprenderemos. Anteriormente, ela era conhecida como Jude. ■ Visual Paradigm for UML ou VP-UML: esta ferramenta oferece uma versão que pode ser baixada gratuitamente, a Community Edition, porém ela não suporta todos os serviços e opções disponíveis nas versões stan- dard ou professionais da ferramenta. Para quem deseja praticar a UML, a versão gratuita é uma boa alternativa, apresentando um ambiente ami- gável e de fácil compreensão. ■ Enterprise Architect: esta ferramenta não possui edição gratui- ta como as anteriores, mas é uma das que mais oferecem recursos compatíveis com a UML 2. O importante, em nossos estudos, é que você consiga entender como se inicia a modelagem do seu sistema. Para tanto, queremos que a informação não fique, apenas, anotada em um documento, mas que você facilite o processo de desen- volvimento utilizando os recursos de modelagem e de construção de diagramas. U N ID A D E 1 20 A UML é, totalmente, baseada no paradigma de Orientação a Objetos (OO). Sendo assim, para compreendê-la corretamente, precisamos, antes, estudar alguns dos conceitos relacionados à orientação a objetos. Objetos Segundo Melo (2004), um objeto é qualquer coisa, em forma concreta ou abstrata, que exista física ou apenas conceitualmente no mundo real. São exemplos de ob- jetos: cliente, professor, carteira, caneta, carro, disciplina, curso, caixa de diálogo. Além disso, eles possuem características e comportamentos. Classes Uma classe é uma abstração de um conjunto de objetos que possuem os mesmos tipos de características e comportamentos, sendo representada por um retân- gulo que possui três divisões. A primeira divisão armazena o nome da classe; a segunda, os atributos (características); enquanto a terceira carrega os métodos. Geralmente, uma classe possui atributos e métodos, mas é possível encontrar aquelas com apenas uma dessas características ou, até mesmo, nenhuma, quando se trata de classes abstratas. A Figura 2 apresenta um exemplo de classe: 4 CONCEITOS BÁSICOS DE ORIENTAÇÃO a Objetos U N IC ES U M A R 21 De acordo com Melo (2004), o momento inicial para a identificação de classes, em um documento de re- quisitos, é assinalar os substantivos. Note que esses substantivos podem levar a objetos físicos (cliente, livro, computador) ou a objetos conceituais (reserva, cronograma, norma). Em seguida, é preciso identifi- car, somente, aqueles que possuem importância para o sistema, verificando o que, realmente, consiste em objeto e o que consiste em atributo. Ainda, é preciso fazer nova análise dos requisitos para identificar as classes implícitas no contextotrabalhado, excluir classes parecidas ou juntar duas classes em uma. Vale a pena ressaltar que esse processo será iterativo, sem a possibilidade de definir todas as classes de uma só vez. Atributos Uma classe, normalmente, possui atributos que representam as suas característi- cas, as quais costumam variar de um objeto a outro, como o nome de um objeto da classe cliente ou a cor em um objeto da classe carro, por exemplo. Tais aspectos são os responsáveis por diferenciar um objeto de outro da mesma classe. De acordo com Guedes (2007), na segunda divisão da classe, aparecem os atributos. Cada atributo deve possuir um nome e, eventualmente, o tipo de dado que armazena, por exemplo, integer, float ou char. Assim, a classe especifica a estrutura de um objeto sem informar quais serão os seus valores. Em relação ao objeto, esse corresponde à instância de uma classe, em determinado momento. Apresentaremos um exemplo para facilitar o seu entendimento: Uma classe pessoa possui os atributos: nome, sexo e data de nascimento. Essa classe pode ter um objeto ou uma instância com os seguintes valores para cada atributo, respec- tivamente: Márcia, feminino, 22/03/1969. Dessa forma, em um sistema, devemos trabalhar com as instâncias (objetos) de uma classe, pois os va- lores de cada atributo são carregados nas ins- tâncias (MELO, 2004). A figura, a seguir, mostra um exemplo de classe com atributos: Cliente Figura 2 - Exemplo de classe. Fonte: os autores. Figura 3 - Exemplo de classe com atributos / Fonte: os autores. Pessoa - nome : string - sexo : string - data_nascimento : date + operation1() : void U N ID A D E 1 22 Métodos Métodos são processos ou serviços realizados por uma classe e disponibilizados para o uso de outras classes em um sistema. Além disso, devem ficar armazenados na terceira divisão da classe. Os métodos são as atividades que a instância de uma classe pode executar (GUEDES, 2007). Um método pode ou não receber parâmetros (valores que são utilizados du- rante a execução do método) bem como retornar valores os quais podem representar o resultado da operação executada ou somente indicar se o pro- cesso foi concluído com sucesso. Assim, um méto- do representa um conjunto de instruções que são executadas quando o método é chamado. Um ob- jeto da classe cliente, por exemplo, pode executar a atividade de incluir novo cliente. A Figura 4 apre- senta um exemplo de uma classe com métodos: Visibilidade De acordo com Guedes (2007), a visibilidade é um símbolo que antecede um atributo ou um método e é utilizada para indicar o seu nível de acessibilidade. Existem, basicamente, três modos de visibilidade: o público, o protegido e o pri- vado. Saiba mais sobre cada um nos tópicos a seguir, na Figura 5: Figura 5 - Modos de visibilidade / Fonte: os autores. Cliente - nome : string - endereço : string - cidade : string - UF : char - CEP : char + incluirNovoCliente() : void + atualizarCliente() : void Figura 4 - Exemplo de classe com métodos / Fonte: os autores. O símbolo mais (+) indica visibilidade pública, ou seja, signi�ca que o atributo ou o método pode ser utilizado por objetos de qualquer classe. O símbolo sustenido (#) indica que a visibilidade é protegida, ou seja, determina que apenas objetos da classe possuidora do atributo ou do método ou de suas subclasses podem acessá-lo. O símbolo menos (-) indica que a visibilidade é privada, ou seja, somente os objetos da classe possuidora do atributo ou do método poderão utilizá-lo. (+) (#) (-) U N IC ES U M A R 23 Note que, no exemplo da classe cliente, tanto os atributos quanto os métodos apresentam a sua visibilidade representada à esquerda de seus nomes. Assim, os atributos nome, sexo e data_nascimento possuem visi- bilidade privada, pois apresentam o símbolo de menos (-) à esquerda da sua descrição. Já os métodos IncluirNovoCliente() e AtualizarCliente() apresentam visibilidade pública, assim como indica o símbolo +, acres- centado à esquerda de sua descrição. Herança (generalização/especialização) A herança permite que as classes de um sistema compartilhem atributos e mé- todos, otimizando, assim, o tempo de desenvolvimento com a diminuição de linhas de código, o que facilita futuras manutenções (GUEDES, 2007). A herança (ou generalização/especialização) acontece entre classes gerais (chamadas de superclasses ou classes-mãe) e classes específicas (chamadas de subclasses ou classes-filha) (BOOCH; RUMBAUGH; JACOBSON, 2006). A herança significa que os objetos da subclasse podem ser utilizados em qualquer local em que a superclasse ocorra, e não vice-versa. A subclasse herda as propriedades da mãe, ou seja, os seus atributos e métodos, bem como pode possuir atributos e métodos próprios, além dos herdados. De acordo com Guedes (2007), a vantagem do uso da herança é que, quando uma classe é declarada com os seus atributos e métodos especí- ficos e, após isto, uma subclasse é derivada, não é necessário redeclarar os atributos e métodos já definidos. Em outras palavras, por meio da herança, a subclasse herda tais atributos e métodos automaticamente, permitindo a reutilização do código já pronto. Assim, é preciso, somente, declarar os atributos ou métodos restritos da subclasse, o que torna o processo de desenvolvimento mais ágil, além de facilitar as manutenções futuras, pois, em caso de alteração, será ne- cessário alterar, somente, o método da superclasse para que todas as sub- classes estejam, também, atualizadas. A Figura 6 apresenta um exemplo de herança, explicitando os papéis de superclasse e subclasse e, também, apresenta o símbolo de herança da UML, uma linha que liga as classes com um triângulo que toca a superclasse: U N ID A D E 1 24 Figura 6 - Exemplo de herança / Fonte: os autores. A figura apresentada mostra a superclasse cliente com os atributos nome, en- dereço, cidade, UF e CEP, bem como os métodos incluirNovoCliente() e atuali- zarCliente(). A subclasse PessoaFisica herda esses atributos e métodos, além de possuir os atributos CPF e RG e o método validarCPF(). A seta que aponta para a superclasse cliente indica a herança. A subclasse PessoaJuridica herda, também, todos os atributos e métodos da superclasse cliente, além de possuir os atributos CNPJ, inscrição_estadual e razão_social e o método validarCNPF(). Quando olhamos para a Figura 6, notamos que a classe cliente é a mais gené- rica e as classes PessoaFisica e PessoaJuridica são as mais especializadas. Então, podemos afirmar que generalizamos quando partimos das subclasses para a su- perclasse e especializamos quando fazemos o contrário, ou seja, quando partimos da superclasse para as subclasses. Polimorfismo O conceito de polimorfismo está associado à herança, pois trabalha com a re- declaração de métodos previamente herdados por uma classe. Esses métodos, embora parecidos, diferem-se, de alguma forma, da implementação utilizada na Cliente - nome : string - endereço : string - cidade : string - UF : char - CEP : char + incluirNovoCliente() : void + atualizarCliente() : void - cnpj : int - inscricao_estadual : int - razão_social: string + validarCnpj() : void PessoaJurídica - cpf: int - RG : int + validarCpf() : void PessoaFísica U N IC ES U M A R 25 superclasse, sendo necessário implementá-los, novamente, na subclasse. Todavia, a fim de não ter que alterar o código-fonte, acrescentando uma chamada a um método com nome diferente, redeclara-se o método com o mesmo nome decla- rado na superclasse (GUEDES, 2007). De acordo com Lima (2009), o polimorfismo é o princípio em que classes derivadas (as subclasses) e uma mesma superclasse podem chamar métodos que têm o mesmo nome (ou a mesma assinatura), mas que possuem comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como cada objeto implementa o método. Em outras palavras, podem existir dois ou mais métodos com a mesma nomenclatura, diferenciando-sena maneira como foram im- plementados. O sistema é o responsável por verificar se a classe da instância em questão possui o método declarado nela própria ou se o herda de uma superclasse (GUEDES, 2007). Por ser um exemplo bastante claro, para ilustrar o polimorfismo, apresentamos a Figura 7: Figura 7 - Exemplo de poliformismo / Fonte: os autores. No exemplo apresentado, há uma classe geral chamada Conta_Comum (que, neste caso, é a superclasse), a qual possui um atributo chamado saldo, que contém o valor total depositado em determinada instância da classe, e um método chamado saque. Esse método, somente, diminui o valor a ser debitado do saldo da conta se este possuir valor suficiente. Caso contrário, a operação não poderá ser realizada, ou seja, o saque deve ser recusado pelo sistema (GUEDES, 2007). Conta_Comum - saldo : double + saque() : void - aniversario : date Conta_Poupança - limite : double + saque() : void Conta_Especial U N ID A D E 1 26 5 DIAGRAMA DE CLASSES Os diagramas de classe são usados no desenvolvimento de um modelo de sistema orien- tado a objetos para mostrar as classes de um sistema e as associações entre elas. Em pou- cas palavras, uma classe de objeto pode ser pensada como a definição geral de um tipo de objeto do sistema. Uma associação é um link entre classes que indica algum relaciona- mento entre elas. Consequentemente, cada classe pode precisar de certo conhecimento de sua classe associada. Quando você está desenvolvendo modelos durante os estágios explorando Ideias O diagrama de classes tem como objetivo permitir a visualização das classes uti- lizadas pelo sistema e como elas se relacionam, apresentando a visão estática de como estão organizadas, preocupando-se, apenas, em definir a sua estrutura lógica (GUEDES, 2007). Ainda, de acordo com o estudioso, um diagrama de classes pode ser utilizado para modelar o modelo lógico de um banco de dados, parecendo-se, neste caso, com o diagrama de entidade-relacionamento (o modelo entidade-re- lacionamento, o qual você estuda na disciplina de banco de dados). No entanto deve ficar bem claro que o diagrama de classes não é utilizado, unicamente, para esta finalidade, e que uma classe não corresponde, necessariamente, a uma tabela. U N IC ES U M A R 27 iniciais do processo de engenharia de software, os objetos representam algo no mundo real, como um paciente, uma receita médica, um médico etc. Enquanto uma aplicação é desenvol- vida, geralmente, é necessário definir objetos adicionais de implementação que são usados para fornecer a funcionalidade requerida do sistema. Fonte: adaptado de Sommerville (2011, p. 90). Estrutura da classe Uma classe pode representar o repositório lógico dos atributos de uma tabe- la, mas a classe não é a tabela. Isto se deve ao fato de que os atributos de seus objetos são armazenados em memória enquanto uma tabela armazena os seus registros fisicamente, em disco. Podemos definir classe como a descrição de uma coleção de objetos que possuem propriedades (atributos, métodos e as- sociações), conforme mostra a Figura 8: Figura 8 - Estrutura da classe / Fonte: os autores. Relacionamentos As classes não trabalham sozinhas. Pelo contrário, elas colaboram umas com as outras, por meio de relacionamentos (MELO, 2004). No diagrama de clas- ses, temos alguns tipos de relacionamentos, como o de associação (que pode ser unária ou binária), de generalização ou de agregação, por exemplo. Na sequência, detalharemos esses e outros tipos. + Nome : string = Fernando +Idade : int = 18 + andar(entrada direção: Direção) : bool + dormir() : bool Pessoa Nome da classe Métodos São as operações que podem ser executadas sobre um objeto Atributos e tipo de dado Informação associada a um objeto U N ID A D E 1 28 Associação De acordo com Melo (2004), a associação é um relacionamento que conecta duas ou mais classes, demonstrando a colaboração entre as instâncias de classe. Pode, também, existir o relacionamento de uma classe com ela mesma e, neste caso, tem-se uma associação unária ou reflexiva. A seguir, apresentaremos, na Figura 9, um exemplo de uma associação entre classes: Figura 9 - Exemplo de associação / Fonte: os autores. Associação unária ou reflexiva Segundo Guedes (2007), a associação unária ocorre quando existe o rela- cionamento da instância de uma clas- se com instâncias da mesma classe, conforme ilustra a Figura 10: No exemplo apresentado, temos a classe funcionário, cujos atributos são código e nome bem como o código do possível chefe do funcionário. Pelo fato de esse chefe, também, ser um funcionário, a associação chamada “chefia” indica possí- vel relação entre uma ou mais instâncias dessa classe com outras instâncias da mesma classe, ou seja, tal associação determina que um funcionário pode ou não chefiar outros. Além disso, essa associação faz com que a classe possua o atributo codChefe para armazenar o código do funcionário, atributo esse que é o respon- sável pela instância do funcionário em questão. Desse modo, após consultar uma instância da classe funcionário, pode-se utilizar o atributo codChefe da instância consultada para pesquisar outra instância da classe (GUEDES, 2007). - Codigo : int - Nome : char + CalcPreco() : void + CalcImposto() : void Produto - NumeroVenda: int + Data() : int Venda Associação 0..* 0..* - codigo : int - nome : char - codChefe : int Funcionario Che�a 0..* Figura 10 - Exemplo de associação unária. Fonte: os autores. U N IC ES U M A R 29 Associação binária A associação binária conecta duas classes por meio de uma reta que liga uma classe a outra. A Figura 11 demonstra um exemplo de associação binária: Figura 11 – Exemplo de associação binária / Fonte: os autores. No exemplo, um objeto da classe cidade pode ou não se relacionar com instâncias da classe cliente, conforme demonstra a multiplicidade 0..*. Entretanto, se existir um objeto da classe cliente, ele terá que se relacionar com um objeto da classe cidade, pois, pelo fato de que não foi definida a multiplicidade na extremidade da classe cidade, isto significa que ela é 1..1. Após termos explicado os relaciona- mentos em um diagrama de classes, explicaremos o conceito de multiplicidade. Agregação Uma agregação pode ocorrer, somente, entre duas classes. De acordo com as re- gras da UML, esse tipo de relacionamento ou associação é identificável a partir da notação de uma linha sólida entre duas classes: a classe denominada “todo-agre- gado” recebe um diamante vazio, enquanto a outra ponta da linha é ligada à classe denominada “parte-constituinte”. Ambas podem “viver” de forma independente, ou seja, não existe ligação forte entre as duas. Objetos da parte constituinte ou da parte agregada são independentes em termos de vida, mas ambas são partes do todo único. Essa análise dependerá do domínio do problema em estudo. Para sabermos se um relacionamento é de agregação, basta perguntarmos se, em primeiro lugar, ele comporta a estrutura todo-parte. Em seguida, questionamos se o objeto constituinte-parte “vive” sem o objeto agregado. Se a resposta for sim a ambas Cliente - nome : string - sexo : char - data_nascimento : Date - endereco : String - CEP : int - nome : String - UF : String - DDD : int Cidade 0..* U N ID A D E 1 30 as perguntas, teremos uma agregação. A Figura 12 apresenta a notação para esta se- mântica. Em determinado domínio de problema que trata de apartamentos e con- domínios, observamos que um apartamento tem depósitos. Quando nos referimos a um depósito, podemos perguntar a qual apartamento ele pertence. Por outro lado, determinado proprietário pode ter decidido vender um depósito para alguém que sequer mora no prédio. Assim, teremos os dois objetos, neste exemplo, viven- do separadamente, sem incômodo algum. Poderíamos ter a situação em que um aparta- mento é interditado ou passa por extensa reforma. Durante algum tempo, não temos movimentação naquele local,mas o depósito que faz parte daquele jogo apartamento-depósito continua sendo usado livremente. Assim, o mesmo exemplo valeria para garagens de um apartamento: Composição Uma composição ocorre quando temos uma situação semelhante à da agrega- ção entre duas classes, mas os objetos da classe parte não podem viver quando o todo é destruído. Esse tipo de relacionamento é identificável pela notação de uma linha sólida entre duas classes: a classe denominada todo-composta, a qual recebe um diamante preenchido, enquanto a outra ponta da linha é ligada à classe denominada “parte-componente”. Ambas as classes “vivem” unidas de forma dependente, ou seja, existe uma ligação forte entre as duas. Os objetos-parte não podem ser destruídos por um objeto diferen- te do objeto-todo ao qual estão relacionados (GUEDES, 2011). Essa análise depen- derá do domínio do problema em estudo. Para sabermos se um relacionamento é de composição, basta perguntarmos se, em primeiro lugar, cabe a estrutura todo-parte. Em seguida, questionamos se o objeto parte “vive” sem o objeto todo. Se a resposta for sim para a primeira pergunta e não para segunda, teremos uma composição. clsApartamento - dMetragem : double - IcountApartamento: double + obterMetragem() : void + obterNrAptsInstanciados() : int clDeposito Figura 12 - Uma agregação en- tre duas classes. Fonte: os autores. U N IC ES U M A R 31 A Figura 13 apresenta uma visão da notação para esse tipo de relacio- namento. Em relação a este domínio de problema, precisamos pensar o pré- dio como um todo. Isso parece plausível, pois, nesse domínio de problema, necessariamente, um prédio deveria existir para que haja um apartamento. Caso não pudesse qualificar um prédio, nada poderia ser feito em relação àquele apartamento. Não se pode fazer nada com um apartamento, vender ou alugar, enquanto ele não possuir um endereço. O endereço é o do pré- dio, o apartamento possui, apenas, complemento. Assim, para os fins deste software, não seria possível instanciar um objeto clsApartamento, caso não fosse designado um objeto clsPredio: Figura 13 - Composição entre duas classes / Fonte: os autores. Generalização/especialização Esta associação identifica as classes-mãe (superclasses), as quais são chamadas gerais, e as classes-filhas (subclasses), as chamadas especializadas, demonstrando a ocorrência de herança e, possivelmente, de métodos polimórficos nas classes especializadas. A seguir, na Figura 14, há um exemplo entre classes que demonstra o uso de generalização/especialização: clsApartamento - dMetragem : double - IcountApartamento: int + obterMetragem() + obterNumAptsInstanciados() : int clsDeposito clsPredio - Nome : String - Endereco : String U N ID A D E 1 32 Figura 14 - Generalização/especialização entre duas classes. Fonte: Guedes (2011, p. 114). Multiplicidade De acordo com Guedes (2007), a multiplicidade determina o número mínimo e máximo de instâncias envolvidas em cada uma das extremidades da associação, permitindo, também, especificar o nível de dependência de um objeto com os ou- tros. Quando não existe multiplicidade explícita, entende-se que ela é 1..1, o que significa que, somente, uma instância dessa extremidade da associação relaciona-se com as instâncias da outra extremidade. A Tabela 1, a seguir, demonstra alguns dos diversos valores de multiplicidade que podem ser utilizados em uma associação: Conta_Comum # nro_conta : long # dt_abertura : Date # dt_encerramento : Date # situracao : int # senha : int # saldo : double + abrir_conta(int : int) : long + consultar_Conta(long : int) : int + validar_Senha(int : int) : int + saldo_Conta() : double + extrato_Conta() : String + sacar_Valor(double : int) : int + depositar_Valor(long : int, double : int) : int + encerrar_Conta() : int - limite_conta : double + abrir_conta(int : int, double : int) : long + sacar_valor(double : int) : int + juros_Conta(double : int) : double Conta_Especial - dt_aniversario : Date + renda_conta(Date : int, double : int) : double Conta_Poupanca U N IC ES U M A R 33 Multiplicidade Significado 0..1 No mínimo, zero (nenhum), no máximo, um. Indica que os objetos das classes associadas não precisam, obrigatoria- mente, estar relacionados, mas, se houver relacionamento, indica que apenas uma instância da classe se relaciona com as instâncias da outra classe. 1..1 Um e somente um. Indica que apenas um objeto da classe se relaciona com os objetos da outra classe. 0..* No mínimo, nenhum, no máximo, muitos. Indica que pode ou não haver instâncias da classe participando do relacionamento. * Muitos. Indica que muitos objetos da classe estão envolvi- dos no relacionamento. 1..* No mínimo, um, no máximo, muitos. Indica que há, pelo menos, um objeto envolvido no relacionamento e que pode haver muitos objetos envolvidos. 2..5 No mínimo, dois, no máximo, cinco. Indica que existem, pelo menos, duas instâncias envolvidas no relacionamento e que podem ser três, quatro ou cinco as instâncias envolvidas, porém não mais do que isso. Tabela 1 - Exemplos de multiplicidade / Fonte: adaptada de Guedes (2011, p. 108). As associações que possuem multiplicidade do tipo muitos (*), em qualquer de suas extremidades, forçam a transmissão do atributo-chave na classe da outra extremida- de da associação. Entretanto esse atributo-chave não aparece desenhado na classe. Figura 15 – Multiplicidade / Fonte: os autores. Pessoa Empresa 1..* * trabalha para multiplicidade associação U N ID A D E 1 34 Classe associativa Quando um relacionamento possui multiplicidade, ou seja, muitos (*) em suas duas extremidades, é necessário criar uma classe associativa para guardar os ob- jetos envolvidos nessa associação. Na classe associativa, são definidos o conjunto de atributos que participam da associação, e não as classes que participam do relacionamento. Nesse caso, pelo menos os atributos-chave devem fazer parte da classe associativa, mas ela, também, pode ter atributos próprios. Uma classe associativa é representada por uma reta tracejada que parte do meio da associação e atinge uma classe. A Figura 16 apresenta um exemplo de classe associativa que possui atributos próprios, além dos atributos-chave das classes que participam da associação. Contudo é necessário reforçar que, neste caso, esses atributos-chave não são representados no diagrama. Figura 16 - Exemplo de classe associativa / Fonte: os autores. No exemplo apresentado, uma instância da classe curso pode se relacionar com muitas instâncias da classe disciplina, bem como uma instância da classe disci- plina pode se relacionar com muitas instâncias da classe curso. Como existe a multiplicidade nas extremidades de ambas as classes da associação, não há como reservar atributos para armazenar as informações decorrentes da associação, já que não é possível determinar um limite para a quantidade de disciplinas que um curso pode ter e nem saber a quantos cursos uma disciplina pode pertencer. Assim, é preciso criar uma classe para guardar essa informação, além das informações próprias da classe, que são a carga horária da disciplina no curso e a Curso - nome : int - area : int Disciplina_Curso - carga_horaria : int - serie : int Disciplina - nome : int Disciplina_Curso 1..* 1..* U N IC ES U M A R 35 série a qual essa disciplina estará vinculada. Os atributos-chave das classes curso e disciplina são transmitidos de forma transparente pela associação, não sendo necessário, portanto, escrevê-los como atributos da classe associativa. Segundo Guedes (2007), as classes associativas podem ser substituídas por classes normais, que, neste caso, são chamadas de classes intermediárias, mas que desempenham, exatamente, a mesma função das associativas. A Figura 17 mostra o mesmo exemplo da figura anterior, porém com a classe intermediária no lugar da classe associativa: Figura 17 - Exemplo de classe intermediária / Fonte: os autores. Curso - nome: int - area : int Disciplina_Curso - carga_horaria : int - serie : int Disciplina - nome : int 1..* 1..* U N ID A D E 1 36 CONSIDERAÇÕES FINAIS No decorrer desta unidade, estudamos a importância da modelagem de um siste- ma e como ela é a parte fundamental de todas as atividades de desenvolvimento, dentro de um processo de software, as quais levam à implantação de um bom software. Esses modelos, normalmente, são representados por meio de diagramas em que é utilizada uma notação gráfica, a qual, em nosso caso, foi a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada). Iniciamos a unidade aprendendo que a modelagem de software se baseia na utilização de notações gráficas e textuais com o objetivo de construir modelos que representem as partes essenciais de um sistema. Na sequência, estudamos alguns conceitos das Ferramentas CASE (Computer-Aided Software Engineering) e da UML. Aprendemos, também, que todos os artefatos de software produzidos durante a modelagem, dentre eles, o diagrama de classe, podem ser usados como base para as fases seguintes do ciclo de vida do programa. Aprendemos que, pelo fato de a UML ser, totalmente, baseada no paradigma de Orientação a Objetos (OO), foi necessário, para compreendê-la, estudar alguns dos conceitos relacionados a tal orientação. Portanto, na sequência, abordamos os conceitos básicos desse paradigma para entender, por meio de elementos, a estrutura do sistema. Por último, relembramos o diagrama de classes, sendo o mais importante e utilizado da UML, pois é ele que define a estrutura das classes identificadas para o sistema, mostrando os atributos e os métodos de cada uma das classes bem como os seus relacionamentos. Na próxima unidade, você estudará conceitos de encapsulamento e mo- dificadores de acesso denominados public, protected e private. Entenderá a diferença dos modificadores static, abstract e final e, também, o que são os construtores de classes. Preparados para seguir em frente? Bons estudos! 37 na prática 1. Uma classe é um conjunto de objetos que possuem os mesmos tipos de caracterís- ticas e comportamentos, sendo representada por um retângulo que pode possuir até três divisões. Partindo desse conceito, elabore um diagrama de classes com duas classes que tenham as características citadas a seguir. Lembre-se que classes não trabalham sozinhas, portanto, construa, entre elas, um relacionamento 1..* (no mínimo, um, no máximo, muitos): Nome da classe: FUNCIONÁRIO Descrição: Contém dados cadastrais dos funcionários Campo Tipo Visibilidade Chave Descrição Matricula Integer Pública PK Matrícula CpfCnpj String Pública CPF ou CNPJ NomeFunc String Pública --- Nome do funcionário DtAdmissao Date Pública --- Data da admissão Métodos: +IncluirNovoFunc +BuscarFunc +ExcluirFunc Nome da Classe: DEPENDENTE Descrição: Contém dados cadastrais do dependente Campo Tipo Visibilidade Chave Descrição IdDep Integer Privada PK Número do dependente NomeDep String Privada --- Nome do dependente DtNasci- mento Date Privada --- Data de nascimento IdFunc Integer Pública FK Código do funcionário Métodos: +IncluirNovoDep +ExcluirDep 38 na prática 2. Faça um diagrama de classes para um sistema de locações de ônibus, levando em consideração os seguintes requisitos: • A empresa tem muitos ônibus. Cada ônibus tem os seguintes atributos: número de placa, cor, ano, tipo de combustível, número de portas, quilometragem, Re- navame valor de locação. • Cada ônibus tem um modelo e uma marca, mas um modelo pode relacionar-se a muitos ônibus e uma marca pode referir-se a muitos modelos, embora cada modelo só tenha uma marca específica. • Um ônibus pode ser alugado por muitos clientes, em momentos diferentes, e um cliente pode alugar muitos ônibus. É preciso saber quais estão locados ou não. Sempre que locar um ônibus, é necessário armazenar a data e a hora de sua locação e, quando for devolvido, a data e a hora da devolução. Com base nesse cenário, identifique as classes, os atributos, os métodos e os relacionamentos. 3. O diagrama de classe é uma representação da estrutura e das relações das classes que servem de modelo para objetos. Partindo disso, analise o diagrama de classe, a seguir, e assinale a alternativa correta: a) Entre as entidades ônibus e passageiro, temos um rela- cionamento de composição. b) Entre as entidades ônibus e passageiro, temos um rela- cionamento de agregação. c) Entre as entidades ônibus e passageiro, temos um relacio- namento de generalização/especialização (herança). d) Entre as entidades ônibus e passageiro, temos um rela- cionamento unário. e) Entre as entidades ônibus e passageiro, temos um rela- cionamento de realização. Onibus Passageiro 39 na prática 4. Maria controla, em Excel, a sua lista mensal de compras de produtos. Na planilha, ela cadastra: • Nome do produto. • Unidade de compra (quilos, litros, metros etc.). • Quantidade prevista para o mês. • Quantidade comprada. • Preço estimado (que é atualizado todo mês). • Valor total da compra. A quantidade comprada pode variar em função da sobra do produto de um mês para o outro ou da necessidade de um gasto menor ou maior no mês. Com base nesse cenário, identifique as classes, os atributos, os métodos e os relacionamentos. 5. Os símbolos menos (-) e mais (+), na frente dos atributos e métodos, representam a sua visibilidade. Esta, por sua vez, é utilizada para indicar o nível de acessibilidade de determinado atributo ou método, sendo, sempre, representada à esquerda. A partir da informação apresentada, descreva os principais três modos de visibilidade utilizados na UML. 40 aprimore-se A UML – Unified Modeling Language ou Linguagem de Modelagem Unificada – é uma linguagem visual utilizada para modelar softwares baseados no paradigma de orientação a objetos. É uma linguagem de modelagem de propósito geral que pode ser aplicada a todos os domínios de aplicação. Essa linguagem tornou-se, nos úl- timos anos, a linguagem-padrão de modelagem adotada internacionalmente pela indústria de engenharia de software. Deve ficar bem claro, porém, que a UML não é uma linguagem de programa- ção, e sim uma linguagem de modelagem, uma notação, cujo objetivo é auxiliar os engenheiros de software a definirem as características do sistema, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus proces- sos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. Tais características podem ser definidas por meio da UML antes do software começar a ser realmente desenvolvido. Além disso, cumpre destacar que a UML não é um processo de desenvolvimento de software e tampouco está ligada a um de forma exclusiva, sendo totalmente independente, po- dendo ser utilizada por muitos processos de desenvolvimento diferentes ou mesmo da forma que o engenheiro considerar mais adequada. A UML surgiu da união de três métodos de modelagem: o método de Booch, o método OMT (Object Modeling Technique) de Jacobson, e o método OOSE (Objec- t-Oriented Software Engineering) de Rumbaugh. Estes eram, até meados da déca- da de 1990, os métodos de modelagem orientada a objetos mais populares entre os profissionais da área de desenvolvimento de software. A união desses métodos contou com o amplo apoio da Rational Software, que a incentivou e financiou. O esforço inicial do projeto começou com a união do método de Booch ao OMT de Jacobson, o que resultou no lançamento do Método Unificado no final de 1995. Logo em seguida, Rumbaugh juntou-se a Booch e Jacobson na Rational Software, e seu método OOSE começou também a ser incorporado à nova metodologia. O trabalho 41 aprimore-se de Booch, Jacobson e Rumbaugh, conhecidos popularmente como “Os Três Ami- gos”, resultou no lançamento, em 1996, da primeira versão da UML propriamente dita. Tão logo a primeira versão foi lançada, muitas empresas atuantesna área de modelagem e desenvolvimento de software passaram a contribuir para o projeto, fornecendo sugestões para melhorar e ampliar a linguagem. Finalmente, a UML foi adotada, em 1997, pela OMG (Object Management Group ou Grupo de Gerencia- mento de Objetos), como uma linguagem-padrão de modelagem. A versão 2.0 da linguagem foi oficialmente lançada em julho de 2005, encontran- do-se, atualmente, na versão 2.3 beta. A documentação oficial da UML pode ser con- sultada no site da OMG em www.omg.org ou mais exatamente em www.uml.org. POR QUE MODELAR SOFTWARE? Qual a real necessidade de se modelar um software? Muitos “profissionais” podem afirmar que conseguem determinar todas as necessidades de um sistema de in- formação de cabeça, e que sempre trabalharam assim. Qual a real necessidade de se projetar uma casa? Um pedreiro experiente não é capaz de construí-la sem um projeto? Isso pode ser verdade, mas a questão é muito mais ampla, envolvendo fatores extremamente complexos, como levantamento e análise de requisitos, pro- totipação, tamanho do projeto, complexidade, prazos, custos, documentação, ma- nutenção e reusabilidade, entre outros. Existe uma diferença gritante entre construir uma pequena casa e construir um prédio de vários andares. Obviamente, para se construir um edifício é necessário, em primeiro lugar, desenvolver um projeto muito bem-elaborado, cujos cálculos têm de estar extremamente corretos e precisos. Além disso, é preciso fornecer uma estimativa de custos, determinar em quanto tempo a construção estará concluída, avaliar a quantidade de profissionais necessária à execução da obra, especificar a http://www.uml.org 42 aprimore-se quantidade de material a ser adquirida para a construção, escolher o local onde o prédio será erguido etc. Grandes projetos não podem ser modelados de cabeça, nem mesmo a maioria dos pequenos projetos pode sê-lo, exceto, talvez, aqueles extremamente simples. Na realidade, por mais simples que seja, todo e qualquer sistema deve ser mode- lado antes de se iniciar sua implementação, entre outras coisas, porque os sistemas de informação frequentemente costumam ter a propriedade de “crescer”, isto é, au- mentar em tamanho, complexidade e abrangência. Muitos profissionais costumam afirmar que sistemas de informação são “vivos”, porque nunca estão completamen- te finalizados. Na verdade, o termo correto seria “dinâmicos”, pois normalmente os sistemas de informação estão em constante mudança. Tais mudanças são devidas a diversos fatores, como, por exemplo: • Os clientes desejam constantemente modificações ou melhorias no sistema. • O mercado está sempre mudando, o que força a adoção de novas estraté- gias por parte das empresas e, consequentemente, de seus sistemas. • O governo seguidamente promulga novas leis e cria novos impostos e alí- quotas ou, ainda, modifica as leis, os impostos e alíquotas já existentes, o que acarreta a manutenção no software. Assim, um sistema de informação precisa ter uma documentação extremamente de- talhada, precisa e atualizada para que possa ser mantido com facilidade, rapidez e correção, sem produzir novos erros ao corrigir os antigos. Modelar um sistema é uma forma bastante eficiente de documentá-lo, mas a modelagem não serve apenas para isso: a documentação é apenas uma das vantagens fornecidas pela modelagem. Fonte: Guedes (2011, p. 19-21). 43 eu recomendo! UML 2 – Uma Abordagem Prática Autor: Gilleanes Thorwald Araújo Guedes Editora: Novatec Sinopse: a UML – Unified Modeling Language ou Linguagem de Modelagem Unificada – é uma linguagem utilizada para modelar softwares baseados no paradigma de orientação a objetos, aplica- da, principalmente, durante as fases de análise de requisitos e de projeto de software. A UML consagrou-se como a linguagem-padrão de modelagem adotada, internacionalmente, pela indústria de Engenharia de Software e, assim, há amplo mercado para profissionais que a dominam. Este livro procura ensinar ao leitor, por meio de exemplos práticos, como modelar softwares pela UML. A lingua- gem é ensinada mediante a apresentação de seus muitos diagramas, detalhando o propósito e a aplicação de cada um deles e os elementos que os compõem, as suas funções e formas de aplicação. A obra enfatiza, ainda, a importância da UML para a Engenharia de Software, além de abordar o paradigma de orientação a objetos, um conceito imprescindível para a compreensão correta da linguagem. livro 44 eu recomendo! Este vídeo mostra uma introdução aos conceitos de orientação a objetos. http://www.youtube.com/watch?v=MnJLeYAno4o&feature=relmfu. O vídeo mostra a importância da modelagem de sistemas bem como da elabora- ção do diagrama de casos de uso. http://www.youtube.com/watch?v=hfN6n5fJfLc&feature=relmfu. conecte-se UML – Guia do Usuário Autor: Grady Booch, James Rumbaugh e Ivar Jacobson Editora: Campus Sinopse: há quase 10 anos, a Unified Modeling Language (UML) é o padrão para visualizar, especificar, construir e documentar os arte- fatos de um sistema de software. A UML 2.0 vem para assegurar as contínuas popularidade e viabilidade da linguagem. As suas simpli- cidade e expressividade permitem que os usuários modelem tudo, desde sistemas empresariais de informação, passando por aplicações distribuídas baseadas na Web até sistemas embutidos de tempo real. Nesta nova edição, totalmente revista, os criadores da linguagem fornecem um tutorial dos aspectos centrais da UML. Começando com um modelo conceitual da UML, o livro aplica, progressivamente, a linguagem em uma série de problemas de modelagem cada vez mais complexos, usando diversos domínios de aplicação. A abordagem em tópicos é recheada de exemplo, o que fez da primeira edição um recurso indispensável. Entretanto, o con- teúdo reflete as mudanças na notação e no uso exigidos pela UML 2.0. livro 2 PLANO DE ESTUDO A seguir, apresentam-se os tópicos que você estudará nesta unidade: • O que é encapsulamento? • Modificadores de acesso: default, public, protected e private • Utilizando modificadores de acesso (getters e setters) • Modificadores static, abstract e final • Construtores de classe. OBJETIVOS DE APRENDIZAGEM • Entender o conceito de encapsulamento • Estudar os modificadores de acesso default, public, protec- ted e private • Controlar o acesso a métodos, atributos e construtores por meio de modificadores • En- tender a diferença dos modificadores static, abstract e final • Entender o que são construtores de classes. MODIFICADORES JAVA E ENCAPSULAMENTO PROFESSORES Dr. Edson Alves de Oliveira Junior Me. Andre Abdala Noel Me. Márcia Cristina Dadalto Pascutti Me. Rafael Alves Florindo Esp. Victor de Marqui Pedroso Esp. Janaina Aparecida de Freitas INTRODUÇÃO Caro(a) aluno(a), após estudarmos a importância da modelagem de um sistema em UML, e como ela é a parte fundamental de todas as atividades dentro de um processo de software, nesta segunda unidade, você verá a revisão dos conceitos de encapsulamento, de modificadores de acesso e construtores em Java. A ideia de encapsulamento remete ao fato de que é possível agru- par estados e comportamentos de um objeto em um mesmo módulo e, ainda, controlar as suas propriedades e o seu acesso, ou seja, trata dos padrões de visibilidade de acessos para as classes, os atributos e os métodos. Para estudar o encapsulamento, escreveremos métodos de acesso que são mais conhecidos como modificadores de acesso. Estes atuarão em elementos de uma classe, utilizando os chamados métodos setters (armazenamento) e getters (resgate). Nos modificadores de acesso setters e getters, a linguagem Java permite o uso dos modificadores static, final e abstract. O modificador static permite que um método de uma classe seja invocada sem ter a instância de uma. O modificador final bloqueará a herança da classe ou o reuso de um método em outra classe. O modificador abstract permite modelar uma classe de forma que elaseja um modelo para as outras que a estendem. Por fim, abordaremos o momento em que uma classe é instanciada, ou seja, quando criamos um objeto de uma classe que, automaticamente, é executado o seu método construtor, que pode inicializar atributos ou outras instruções essenciais para o início da classe. Dessa forma, con- trolaremos como os objetos de uma classe serão inicializados e de qual forma podemos melhor aproveitá-los. Para mostrar a você como utilizar estes recursos, empregaremos alguns exemplos que usam essas técnicas de modificadores de acesso e de cons- trutores de classe. Discutiremos, ao longo da unidade, um exemplo para a apresentação do tema e, também, outro exemplo, em que será construído um projeto completo, desenvolvido com as técnicas apresentadas. U N IC ES U M A R 47 1 O QUE É ENCAPSULAMENTO? Classes (e seus objetos) encapsulam, isto é, contêm seus atributos e métodos. Os atri- butos e métodos de uma classe (e de seu objeto) estão intimamente relacionados. Os objetos podem se comunicar entre si, mas eles, em geral, não sabem como outros ob- jetos são implementados – os detalhes de implementação permanecem ocultos dentro dos próprios objetos. Esse ocultamento de informações, como veremos, é crucial à boa engenharia de software. Fonte: Deitel e Deitel (2017, p. 9). conceituando Caro(a) aluno(a), quando se fala de encapsulamento, você, provavelmente, ima- gina um objeto fechado, dentro de uma cápsula, e isto não é muito diferente na programação orientada a objetos, pois a ideia principal do encapsulamento envolve omitir os membros de uma classe, além de esconder como funcionam as rotinas ou as regras de negócio. Dessa forma, o programador deve se atentar às funcionalidades da classe, e não como ela foi implementada. Isto é bom, uma vez que há a expansão na modularidade do seu projeto. Sendo assim, realizar o encapsulamento de um projeto é fundamental para a possibilidade de minimizar o impacto de problemas referentes a alterações do U N ID A D E 2 48 projeto, uma vez que não é preciso alterar uma regra de negócio em vários lugares, mas, sim, em apenas um lugar, já que tal regra está encapsulada. Para exemplificar, focaremos no problema de realização de operações bancá- rias em um caixa eletrônico. No caixa, é possível: sacar dinheiro, depositar, verifi- car saldo, verificar extrato, pagar contas e fazer transferências. Para utilizar o caixa eletrônico, não é necessário conhecer como as operações foram implementadas em nível de programação, mas, sim, saber o que cada operação afeta em sua conta. Analise a Figura 1, a seguir, e verifique a classe Conta, com atributos e méto- dos para uma Conta Corrente. Note, por exemplo, que o método transferir rece- be, como parâmetro, o número da conta (numContaDestino) e um valor a ser transferido (valor). Para utilizar esse método, o programador não precisa saber como o criador dessa classe o implemen- tou, basta saber que esse método é respon- sável por enviar um valor para outra conta corrente, e que essa transferência implica subtração do saldo da conta remetente. Ainda em relação à Figura 1, que ilustra um diagrama de Classe UML, o símbo- lo soma (+) indica que tanto os atributos quanto os métodos são públicos. Isso significa que eles podem ser acessados e modificados de qualquer outra classe do projeto, e isto não é uma boa prática de programação, uma vez que os seus atributos estão expostos e qualquer outro objeto pode alterar os valores dos ele- mentos das classes, comprometendo, assim, a coesão do seu projeto. Por exemplo, na Figura 2: //Criação da referência a Conta ContaCorrente cc = new Conta(); //Modificação do atributo saldo de forma direta cc.saldo = 0; System.out.println("Saldo Conta: R$"+cc.saldo); Para solucionar este problema, faz-se necessária a utilização de modificadores de acesso, sendo que eles farão o papel de restringir ou autorizar o acesso a determi- nados atributos ou métodos das classes, e isto será visto a partir da próxima seção. Conta + saldo : �oat + titular : String + cpfTitular : String + numConta : int + sacar(valorSaque : �oat) : void + depositar(valorDep : �oat) : void + veri�carSaldo() : void + transferir(numContaDestino : int, valor : int) : �oat Figura 1 - Classe Conta com atributos e métodos públicos / Fonte: os autores. U N IC ES U M A R 49 2 MODIFICADORES DE ACESSO: Default, Public, Protected e Private Segundo Deitel e Deitel (2017), projeto e pacotes de projeto são conceitos básicos da programação em Java: Um projeto é a base para o desenvolvimento em Java, é nele que estarão todos os paco- tes, as classes, as interfaces, as imagens da sua aplicação (2017). O rico conjunto do Java de classes predefinidas é agrupado em pacotes – chamados de grupos de classes. Estes são referidos como biblioteca de classes Java, ou Interface de Programação de Aplicativo Java (API Java). Fonte: os autores. conceituando É a partir dos modificadores de acesso que poderemos restringir ou não o acesso aos atributos e métodos de uma classe. Na programação orientada a objetos, os modificadores de acesso mais utilizados são o public e o private. Antes de abordarmos os modificadores, é importante frisar alguns conceitos básicos sobre a programação em Java: projeto e pacotes do projeto. Quando trabalhamos com o Netbeans para a criação de um projeto, basta aces- sarmos o menu “Arquivo” e, em seguida, selecionar a opção “Novo Projeto”. Feito isto, aparecerá uma tela, como você pode verificar na Figura 2, a seguir: U N ID A D E 2 50 Figura 2 - Criando um projeto em Java no Netbeans / Fonte: os autores. Como o Netbeans é uma IDE que suporta diversas linguagens de programação, ao criar o projeto, é necessário, previamente, selecionar a linguagem e, em segui- da, o tipo de projeto. Sendo assim, criaremos um Aplicativo Java selecionando a opção “Aplicativo Java”. Feito isso, uma nova tela solicitará o preenchimento do nome do projeto, como você pode verificar na Figura 3: Figura 3 - Configurando o nome do projeto / Fonte: os autores. U N IC ES U M A R 51 Após essas etapas, o seu projeto estará criado e poderá ser visualizado na Paleta “Projetos” do Netbeans, como pode ser ve- rificado na Figura 4. Você pode notar que um projeto envolve pacotes e bibliotecas que, talvez, a sua aplicação necessite utilizar. Figura 4 - Projeto em Java Fonte: os autores. Para criar um novo pacote na pasta “Pacotes de código-fonte”, por exemplo, é neces- sário clicar sobre a pasta com o botão direito e selecionar a opção: “Novo” -> “Pacote Java” e, em seguida, dar um nome ao seu novo pacote, como mostra a Figura 5. Figura 5 - Criando um novo pacote Fonte: os autores. Agora que você já entendeu o conceito de pacotes, iniciaremos a teoria sobre modificadores de acesso. Temos quatro deles: default, public, private e protected. O modificador default não precisa ser declarado, ou seja, atributos ou mé- todos que não têm a declaração de um modificador de acesso são considerados default (do inglês, significa “padrão”). Como exemplo, você pode notar, no código, a criação de um atributo com modificador de acesso default. No pacote em que está localizada a classe criada, o atributo com esse modificador pode ser acessa- do de forma direta por qualquer classe, agora, se a classe que instanciar a classe estiver em outro pacote, este não será acessível de forma direta. U N ID A D E 2 52 //exemplo de atributo default String valorTransitorio; Atributos e métodos públicos (public) podem ser acessados e modificados de qualquer classe do projeto a partir da instância do objeto, ou seja, é possível, até de outros pacotes, ter acesso a atributos/métodos do tipo public, de forma direta. Para declarar esse tipo de modificador, é necessário utilizar a palavra reservada public antes de indicar o tipo de variável, isso pode ser verificado no exemplo de código-fonte, a seguir. //exemplo de atributo public public int idade;
Compartilhar