Baixe o app para aproveitar ainda mais
Prévia do material em texto
1 2 SUMÁRIO 1 INTRODUÇÃO ..................................................................................... 3 2 MODELO DE ANÁLISE DE SOFTWARE (ORIENTADA A OBJETOS)..... ......................................................................................................... 4 3 ENGENHARIA DE SOFTWARE APLICADA À ANÁLISE DE SOFTWARE ORIENTADA A OBJETOS ................................................................. 5 4 ELEMENTOS DA MODELAGEM ORIENTADA A OBJETOS.............. 6 4.1 Linguagem de modelagem unificada (UML).................................. 7 4.2 Diagrama de classe ...................................................................... 9 4.3 Casos de uso .............................................................................. 11 5 VANTAGENS E DESVANTAGENS DA ANÁLISE ORIENTADA A OBJETOS.... .......................................................................................................... 14 6 PADRÕES DE PROJETOS ............................................................... 16 6.1 O que é um padrão de projeto? .................................................. 18 7 PROGRAMAÇÃO ORIENTADA A OBJETOS ................................... 21 7.1 Linguagens orientadas a objetos ................................................ 23 8 DESENVOLVENDO COM PROGRAMAÇÃO ORIENTADA A OBJETOS... ........................................................................................................... 28 9 REFERÊNCIAS ................................................................................. 31 3 1 INTRODUÇÃO Prezado aluno! O Grupo Educacional FAVENI, esclarece que o material virtual é semelhante ao da sala de aula presencial. Em uma sala de aula, é raro – quase improvável - um aluno se levantar, interromper a exposição, dirigir-se ao professor e fazer uma pergunta, para que seja esclarecida uma dúvida sobre o tema tratado. O comum é que esse aluno faça a pergunta em voz alta para todos ouvirem e todos ouvirão a resposta. No espaço virtual, é a mesma coisa. Não hesite em perguntar, as perguntas poderão ser direcionadas ao protocolo de atendimento que serão respondidas em tempo hábil. Os cursos à distância exigem do aluno tempo e organização. No caso da nossa disciplina é preciso ter um horário destinado à leitura do texto base e à execução das avaliações propostas. A vantagem é que poderá reservar o dia da semana e a hora que lhe convier para isso. A organização é o quesito indispensável, porque há uma sequência a ser seguida e prazos definidos para as atividades. Bons estudos! 4 2 MODELO DE ANÁLISE DE SOFTWARE (ORIENTADA A OBJETOS) Fonte: google.com.br A análise orientada a objetos, diferentemente do enfoque tradicional, sugere que um sistema é uma coletânea de objetos que interagem entre si, com características próprias, representadas por atributos e operações. Neste tipo de análise, os atributos representam os dados de um objeto e servem para expressar características e informações. Já as operações são as ações que podem ser realizadas pelo objeto. O mais interessante é a possibilidade de modelar o sistema usando objetos que representam elementos do mundo real. Isso permite que sistemas complexos sejam facilmente modelados e implementados, além de facilitar o seu crescimento e a manutenção. (Morais, 2018). Neste capítulo, você vai adquirir conhecimentos fundamentais para avançar no aprendizado sobre análise orientada a objetos. Explore conceitos básicos sobre o modelo, suas ferramentas, vantagens e desvantagens. (Morais, 2018). 5 3 ENGENHARIA DE SOFTWARE APLICADA À ANÁLISE DE SOFTWARE ORIENTADA A OBJETOS A era tecnológica almeja por softwares cada vez mais complexos. Essa complexidade está ligada diretamente à grande quantidade de informações que devem ser processadas simultaneamente. Com o tempo, os recursos tecnológicos passaram por diversas mudanças, tanto em seus dispositivos físicos quanto lógicos. A Engenharia de Software surgiu devido à necessidade de haver técnicas que norteassem o processo de desenvolvimento do software (Morais, 2018). Diante dos diversos conceitos, métricas e ferramentas que regem a Engenharia de Software, foram desenvolvidas maneiras de realizar a análise de software. Primeiramente, o modelo mais utilizado foi o modelo de análise estruturada, que ficou conhecido também como um modelo clássico. Por ser clássico, ele traz conceitos de base para se realizar a análise de um software. Porém, como citado anteriormente, vivemos em uma era em que os artefatos tecnológicos devem ser cada vez mais robustos e compatíveis às novas tecnologias. (Morais, 2018). A OOA (análise orientada a objetos, em inglês object-oriented analysis,) é uma técnica de análise semiformal para o paradigma de orientação a objetos. A análise orientada a objetos é um componente-chave do paradigma de orientação a objetos. Quando esse fluxo de trabalho é realizado, as classes são extraídas. Os casos de uso e as classes são a base de um produto de software orientado a objetos a ser desenvolvido (SCHACH, 2010, p.395). Dessa forma, “concentra-se na definição de classes e na maneira como colaboram entre si para atender aos requisitos dos clientes” (PRESSMAN; MAXIM, 2016, p. 172). Uma classe traz um conceito do mundo real, representa algum conceito, um objeto, que tem comportamento e características e que executa ações. Assim como as diversas vertentes da Engenharia de Software, a metodologia de análise de software também requer técnicas específicas para que todos os detalhes observados sejam documentados, seja por meio da escrita de 6 uma documentação específica, seja pelo uso de recursos gráficos. Veremos quais elementos são utilizados pela análise orientada a objetos no próximo tópico. Uma das metodologias existentes na Engenharia de Software é a metodologia ágil e que pode ser aplicada na análise de software. No The Official Agile Modeling Site, Scott Ambler (apud PRESSMAN; MAXIM, 2016, p. 81), descreve modelagem ágil (AM) da seguinte maneira: Modelagem ágil (AM) consiste em uma metodologia prática, voltada para a modelagem e documentação de sistemas baseados em software. Simplificando, modelagem ágil consiste em um conjunto de valores, princípios e práticas voltados para a modelagem do software que podem ser aplicados a um projeto de desenvolvimento de software de forma leve e eficiente. Os modelos ágeis são mais eficientes do que os tradicionais pelo fato de serem simplesmente bons, pois não têm a obrigação de ser perfeitos. 4 ELEMENTOS DA MODELAGEM ORIENTADA A OBJETOS Fonte:google.com.br O modelo de análise de software estruturado faz uso do diagrama de fluxo de dados e do dicionário de dados, não se limitando a nenhum desses elementos, 7 até mesmo porque o uso de uma metodologia ou ferramenta irá depender do contexto ao qual ela será inserida. Dessa forma, para a realização da análise de software orientado a objetos, se faz comum o uso da linguagem de modelagem unificada (do inglês UML – unified modeling language) como elemento de representação gráfica e informacional de dados e informações de um software. (Morais, 2018). 4.1 Linguagem de modelagem unificada (UML) A UML nos permite visualizar e especificar detalhes de um software em desenvolvimento por meio de uma linguagem específica. Ela permite que elementos, relacionamentos e diagramas sejam modelados. Esses elementos podem ser estruturais, comportamentais e, até simples anotações sobre os artefatos do software, que são compostos por classes, componente, interações, pacotes, dentre outros. Os relacionamentos entre as classes, ou seja, entre os objetos dentro de um contexto de orientação a objetos,ocorrem por meio de dependências, associações, implementações e até generalizações. Cada relacionamento é estabelecido conforme o problema a ser solucionado. (Morais, 2018). Para Larman (2007, p. 39), a palavra visual na definição é um ponto-chave. A UML é a notação diagramática padrão, de fato, para desenhar ou apresentar figuras (com algum texto) relacionadas a software – principalmente software orientado a objetos (OO). Em Fowler (2003 apud Larman, 2007), três modos pelos quais as pessoas aplicam UML são apresentados: • UML como rascunho: diagramas incompletos e informais (frequentemente rascunhados à mão em quadros brancos) criados para explorar partes difíceis do problema ou espaço de soluções, explorando o poder das linguagens visuais. • UML como planta de software: diagramas de projeto relativamente detalhados, usados seja em Engenharia reversa, para visualizar e 8 melhor entender o código existente em diagramas UML; ou geração de código (Engenharia avante). • Em Engenharia reversa: uma ferramenta UML lê o código fonte ou o código binário e gera (tipicamente) diagramas UML de pacotes, de classes e de sequência. Essas “plantas de software” podem ajudar o leitor a entender os elementos, a estrutura e as colaborações globais. • Antes da programação, alguns diagramas detalhados podem fornecer diretrizes para a geração de código (por exemplo, em Java), quer manualmente, quer automaticamente, com uma ferramenta. É comum que os diagramas sejam usados para uma parte do código e outra parte seja preenchida por um desenvolvedor que esteja codificando (talvez também aplicando rascunhos UML). • UML como linguagem de programação: especificação executável completa de um sistema de software em UML. Código executável será automaticamente gerado, mas não é normalmente visto ou modificado por desenvolvedores; trabalha-se apenas na “linguagem de programação” UML. Esse uso da UML requer um modo prático de diagramar todo o comportamento ou a lógica (provavelmente usando diagramas de interação ou estado) e está ainda em desenvolvimento em termos de teoria, ferramentas robustas e usabilidade. Ainda sob o ponto de vista do autor, “a UML descreve tipos de esboço de diagramas, tais como diagramas de classe e diagramas de sequência. Ela não superpõe a eles uma perspectiva de modelagem. Por exemplo, a mesma notação UML de diagrama de classes pode ser usada para desenhar imagens de conceitos do mundo real ou de classes de software em Java” (LARMAN, 2007, p. 40). 9 4.2 Diagrama de classe O diagrama de classe “fornece um conjunto inicial de elementos de notação que todos os outros diagramas de estrutura usam. A representação UML de uma classe é um retângulo contendo três compartimentos empilhados verticalmente [...]. O compartimento superior mostra o nome da classe. O compartimento do meio lista os atributos da classe. O compartimento inferior lista as operações da classe. Ao projetar um elemento de classes em um diagrama de classes, deve-se usar o compartimento superior, e os dois compartimentos inferiores são opcionais (os dois inferiores seriam desnecessários em um diagrama que ilustrasse um nível mais alto de detalhes, no qual o propósito fosse mostrar somente o relacionamento entre os classificadores (BELL, 2016, p. 3). A Figura 1 a seguir traz um exemplo da notação gráfica do diagrama de classes. O contexto que envolve a manipulação de objetos traz também a questão da herança, a qual permite que uma classe herde outras funcionalidades e até outros atributos. A representação gráfica desse conceito é realizada pela ligação entre as classes por meio de uma ponta de seta, já que o “traço” representa apenas uma associação. Neste caso, essa ponta de seta não deve ser preenchida e deve 10 apontar, da classe que está disponibilizando, seus atributos e operações. Chamamos essa classe de superclasse (Figura 2). De acordo com Pressman e Maxim (2016, p. 895), qualquer alteração nos atributos ou nas operações contidas dentro de uma superclasse é imediatamente herdada por todas as subclasses. Portanto, a hierarquia de classes torna-se um mecanismo pelo qual alterações (em altos níveis) podem ser imediatamente propagadas em um sistema. É importante notar que, em cada nível de hierarquia de classe, novos atributos e operações podem ser acrescentados àqueles que foram herdados de níveis mais altos na hierarquia. 11 4.3 Casos de uso O caso de uso é outro diagrama da UML, e Alistair Cockburn (2001, apud PRESSMAN; MAXIM, 2016, p. 149) observa que “um caso de uso captura um contrato [...] [que] descreve o comportamento do sistema sob várias condições, à medida que o sistema responde a uma solicitação de um de seus envolvidos”. Para Pressman e Maxim (2016, p. 149), basicamente, um caso de uso conta uma jornada estilizada sobre como um usuário (desempenhando um de uma série de papéis possíveis) interage com o sistema sob um conjunto de circunstâncias específicas. De acordo com Schach (2010, p. 290), outra forma de interpretar um caso de uso é que ele mostra a interação entre o produto de software e o ambiente no qual ele opera, isto é, o ator é o membro do mundo externo ao produto de software, ao passo que o retângulo no caso de uso representa o produto de software. Normalmente, é mais fácil identificar um ator. • Frequentemente, ator é um usuário de produto de software. No caso de um produto de software para a área bancária, os usuários desse 12 produto de software são os clientes e os funcionários do banco, como caixas e gerentes. • Em geral, o ator desempenha um papel em relação ao produto de software, que poderia ser como usuário deste. Entretanto, o iniciador de um caso de uso, ou alguém que desempenhe um papel crítico em um caso de uso, também desempenha um papel, portanto, é considerado um ator, independentemente de essa pessoa também ser um usuário do produto de software (Figura 3). Assim como no diagrama de classe, o caso de uso também traz associações, que relacionam os autores, os casos de uso, e até outros autores que podem estar envolvidos no mesmo contexto. Para Jacobson (1992 apud PRESSMAN; MAXIM, 2016, p. 150), algumas perguntas que devem ser respondidas por um caso de uso: • Quais são as metas do ator? • Que precondições devem existir antes de uma jornada começar? • Que tarefas ou funções principais são realizadas pelo ator? 13 • Que exceções poderiam ser consideradas à medida que uma jornada é descrita? • Quais são as variações possíveis na interação do ator? • Que informações de sistema o ator adquire, produz ou modifica? • O ator terá de informar o sistema sobre mudanças no ambiente externo? • Que informações o ator deseja do sistema? • O ator gostaria de ser informado sobre mudanças inesperadas? Diversos mecanismos podem ser utilizados na concepção de um caso de uso. Geralmente, as informações contidas nesse tipo de diagrama são oriundas de uma completa documentação de requisitos, os quais devem trazer os requisitos funcionais do sistema. Dessa forma, todos devem trazer mais clareza e consistência ao sistema, pois demonstram visualmente alguns de seus mais importantes aspectos, que são suas funcionalidades. (Morais, 2018). 14 5 VANTAGENS E DESVANTAGENS DA ANÁLISE ORIENTADA A OBJETOS A demanda social trouxe diversas versões da UML. Dessa forma, suas conotações buscaram sempre acompanhar a necessidade dos desenvolvedores de software. Com isso, uma das vantagens em utilizar a UML na análise de software orientada a objetos é que sempre há alguma atualização nova, para que sua usabilidade não fique obsoleta. Ela também traz facilidades que visam à melhor compreensão das funcionalidades de um sistema, deixando todos os detalhes mais claros,não só para os desenvolvedores, mas também para os clientes, que na maioria das vezes são leigos no assunto. (Morais, 2018). A desvantagem se encontra no tempo, o qual deve ser dedicado ao desenvolvimento dos diagramas e, consequentemente, de uma vasta documentação. Dessa forma, só é indicado dar início ao processo de implementação após todo o sistema ter sido especificado nos diagramas. Outro fator atrelado à desvantagem do uso da UML na análise de software orientado a objetos é a familiaridade da equipe desenvolvedora com as notações dos diagramas e com as ferramentas utilizadas para desenvolvê-los, um fato que acaba atrelado ao tempo – e sabemos que para obter lucro no desenvolvimento de um software o custo- benefício deve estar ligado diretamente ao investimento de tempo, ferramentas e uma equipe especializada. (Morais, 2018). De qualquer forma, a Engenharia de Software traz métodos que podem ser adaptáveis a qualquer projeto. O importante é sabermos que temos diversas opções. Porém, para realizarmos a melhor escolha, devemos conhecer todas as técnicas disponíveis e sabermos como elas operam em um ciclo de desenvolvimento de software. (Morais, 2018). 15 16 6 PADRÕES DE PROJETOS Projetar software orientado a objetos é difícil, mas projetar software reutilizável orientado a objetos é ainda mais complicado. Você deve identificar objetos pertinentes, fatorá-los em classes no nível correto de granularidade, definir as interfaces das classes, as hierarquias de herança e estabelecer as relações- chave entre eles. O seu projeto deve ser específico para o problema a resolver, mas também genérico o suficiente para atender problemas e requisitos futuros. Também deseja evitar o reprojeto, ou pelo menos minimizá-lo. Os mais experientes projetistas de software orientado a objetos lhe dirão que um projeto reutilizável e flexível é difícil, senão impossível, de obter corretamente da primeira vez. Antes que um projeto esteja terminado, eles normalmente tentam reutilizá-lo várias vezes, modificando-o a cada vez. (SAGAH, 2018) Projetistas experientes realizam bons projetos, ao passo que novos projetistas são sobrecarregados pelas opções disponíveis, tendendo a recair em técnicas não orientadas a objetos que já usavam antes. Leva um longo tempo para os novatos aprenderem o que é realmente um bom projeto orientado a objetos. Os projetistas experientes evidentemente sabem algo que os inexperientes não sabem. O que é? (SAGAH, 2018) Uma coisa que os melhores projetistas sabem que não devem fazer é resolver cada problema a partir de princípios elementares ou do zero. Em vez disso, eles reutilizam soluções que funcionaram no passado. Quando encontram uma boa solução, eles a utilizam repetidamente. Consequentemente, você encontrará padrões, de classes e de comunicação entre objetos, que reaparecem frequentemente em muitos sistemas orientados a objetos. Esses padrões resolvem problemas específicos de projetos e tornam os projetos orientados a objetos mais flexíveis e, em última instância, reutilizáveis. Eles ajudam os projetistas a reutilizar projetos bem-sucedidos ao basear os novos projetos na experiência anterior. Um projetista que está familiarizado com tais padrões pode aplicá-los imediatamente a diferentes problemas de projeto, sem necessidade de redescobri-los. (SAGAH, 2018) 17 Uma analogia nos ajudará a ilustrar este ponto. Os novelistas ou autores de roteiros (cinema, teatro, televisão) raramente projetam suas tramas do zero. Em vez disso, eles seguem padrões como “O herói tragicamente problemático” (Macbeth, Hamlet, etc.) ou “A Novela Romântica” (um sem-número de novelas de romances). Do mesmo modo, projetistas de software orientado a objetos seguem padrões como “represente estados como objetos” e “adorne objetos de maneira que possa facilmente acrescentar/remover características”. Uma vez que você conhece o padrão, uma grande quantidade de decisões de projeto decorre automaticamente. (SAGAH, 2018) Todos sabemos o valor da experiência de projeto. Quantas vezes você já não passou pela experiência do déja vu durante um projeto – aquele sentimento de que já resolveu um problema parecido antes, embora não sabendo exatamente onde e como? Se pudesse lembrar os detalhes do problema anterior e de que forma o resolveu, então poderia reutilizar a experiência em lugar de redescobri-la. Contudo, nós não fazemos um bom trabalho ao registrar experiência em projeto de software para uso de outros. (SAGAH, 2018) Os padrões de projeto tornam mais fácil reutilizar projetos e arquiteturas bem-sucedidas. Expressar técnicas testadas e aprovadas as torna mais acessíveis para os desenvolvedores de novos sistemas. Os padrões de projeto ajudam a escolher alternativas de projeto que tornam um sistema reutilizável e a evitar alternativas que comprometam a reutilização. Os padrões de projeto podem melhorar a documentação e a manutenção de sistemas ao fornecer uma especificação explícita de interações de classes e objetos e o seu objetivo subjacente. Em suma, ajudam um projetista a obter mais rapidamente um projeto adequado. (SAGAH, 2018) Nenhum dos padrões de projeto descreve projetos novos ou não-testados. Incluímos somente projetos que foram aplicados mais de uma vez em diferentes sistemas. Muitos deles nunca foram documentados antes. São parte do folclore da comunidade de desempenho de software orientado a objetos ou elementos de sistemas orientados a objetos bem-sucedidos — em nenhum dos casos é fácil para projetistas novatos aprender as lições. Assim, embora esses projetos não sejam 18 novos, nós os capturamos numa forma nova e acessível: como um catálogo de padrões, que tem um formato consistente. (SAGAH, 2018) 6.1 O que é um padrão de projeto? Christopher Alexander afirma: “cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca o fazer da mesma maneira” [AIS+77, pág. x]. Muito embora Alexander estivesse falando acerca de padrões em construções e cidades, o que ele diz é verdadeiro em relação aos padrões de projeto orientados a objeto. Nossas soluções são expressas em termos de objetos e interfaces em vez de paredes e portas, mas no cerne de ambos os tipos de padrões está a solução para um problema num determinado contexto. (SAGAH, 2018) Em geral, um padrão tem quatro elementos essenciais: 1. O nome do padrão é uma referência que podemos usar para descrever um problema de projeto, suas soluções e consequências em uma ou duas palavras. Dar nome a um padrão aumenta imediatamente o nosso vocabulário de projeto. Isso nos permite projetar em um nível mais alto de abstração. Ter um vocabulário para padrões permite-nos conversar sobre eles com nossos colegas, em nossa documentação e até com nós mesmos. O nome torna mais fácil pensar sobre projetos e a comunicá-los, bem como os custos e benefícios envolvidos, a outras pessoas. Encontrar bons nomes foi uma das partes mais difíceis do desenvolvimento do nosso catálogo. 2. O problema descreve em que situação aplicar o padrão. Ele explica o problema e seu contexto. Pode descrever problemas de projeto específicos, tais como representar algoritmos como objetos. Pode descrever estruturas de classe ou objeto sintomáticas de um projeto 19 inflexível. Algumas vezes, o problema incluirá uma lista de condições que devem ser satisfeitas para que faça sentido aplicar o padrão. 3. A solução descreve os elementos que compõem o padrão de projeto, seus relacionamentos, suas responsabilidades e colaborações. A solução não descreve um projeto concreto ou uma implementação em particular porque um padrão é como um gabarito que pode ser aplicado em muitas situações diferentes. Em vez disso, o padrão fornece uma descrição abstratade um problema de projeto e de como um arranjo geral de elementos (classes e objetos, no nosso caso) o resolve. 4. As consequências são os resultados e análises das vantagens e desvantagens (trade-offs) da aplicação do padrão. Embora as consequências sejam raramente mencionadas quando descrevemos decisões de projeto, elas são críticas para a avaliação de alternativas de projetos e para a compreensão dos custos e benefícios da aplicação do padrão. As consequências para o software frequentemente envolvem balanceamento entre espaço e tempo. Elas também podem abordar aspectos sobre linguagens e implementação. Uma vez que a reutilização é frequentemente um fator no projeto orientado a objetos, as consequências de um padrão incluem o seu impacto sobre a flexibilidade, a extensibilidade ou a portabilidade de um sistema. Relacionar essas consequências explicitamente ajuda a compreendê-las e avaliá-las. O ponto de vista afeta a interpretação de alguém sobre o que é, ou não, um padrão. O padrão de uma pessoa pode ser um bloco de construção primário para outra. Padrões de projeto não são projetos, como listas encadeadas e tabelas de acesso aleatório, que podem ser codificadas em classes e ser reutilizadas tais como estão. Tampouco são projetos complexos, de domínio específico, para uma 20 aplicação inteira ou subsistema. Padrões de projeto, neste livro, são descrições de objetos e classes comunicantes que precisam ser personalizadas para resolver um problema geral de projeto num contexto particular. (SAGAH, 2018) Um padrão de projeto nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum para torná-la útil para a criação de um projeto orientado a objetos reutilizável. O padrão de projeto identifica as classes e instâncias participantes, seus papéis, colaborações e a distribuição de responsabilidades. Cada padrão de projeto focaliza um problema ou tópico particular de projeto orientado a objetos. Ele descreve em que situação pode ser aplicado, se ele pode ser aplicado em função de outras restrições de projeto e as consequências, custos e benefícios de sua utilização. Uma vez que em algum momento devemos implementar nossos projetos, um padrão de projeto também fornece exemplos em código – nesse caso, C++ e, algumas vezes, Smalltalk – para ilustrar uma implementação. (SAGAH, 2018) Embora padrões de projeto descrevam projetos orientados a objeto, baseiam-se em soluções reais que foram implementadas nas principais linguagens de programação orientadas a objeto, como Smalltalk e C++, em vez de implementações em linguagens procedurais (Pascal, C, Ada) ou linguagens orientadas a objetos mais dinâmicas (CLOS, Dylan, Self). Nós escolhemos Smalltalk e C++ por razões práticas: a nossa experiência do dia a dia foi com estas linguagens e elas estão se tornando cada vez mais populares. (SAGAH, 2018) A escolha da linguagem de programação é importante porque influencia o ponto de vista do projetista (usuário do pradrão): nossos padrões assumem recursos de linguagem do nível do Smalltalk/C++, e essa escolha determina o que pode, ou não, ser implementado facilmente. Se tivéssemos assumido o uso de linguagens procedurais, deveríamos ter incluído padrões de projetos como “Herança”, “Encapsulamento” e “Polimorfismo”. De maneira semelhante, alguns dos nossos padrões são suportados diretamente por linguagens orientadas a objetos menos comuns. Por exemplo, CLOS tem multi- métodos que diminuem a necessidade de um padrão como Visitor (pág. 305). De fato, há bastante diferenças 21 entre Smalltalk e C++, o que significa que alguns padrões podem ser expressos mais facilmente em uma linguagem que em outra. (SAGAH, 2018) 7 PROGRAMAÇÃO ORIENTADA A OBJETOS O conceito de POO tem suas raízes na linguagem de programação simula 67, criada por Alan Kay, o precursor dos conceitos desse paradigma de programação. Contudo, sua grande evolução foi totalmente alcançada com a chegada da linguagem de programação Smalltalk 80: De fato, algumas pessoas consideram Smalltalk a modelo base para uma linguagem de programação puramente orientada a objetos. Uma linguagem orientada a objetos deve fornecer suporte para três recursos chave de linguagem: tipos de dados abstratos, herança e vinculação dinâmica de chamadas a métodos (SEBESTA, 2018, p. 547). Linguagens que suportam a POO são, atualmente, muito usadas. Algumas das linguagens de programação mais novas, projetadas para a POO, não implementam mais conceitos de linguagens procedurais como as primeiras implementavam. Porém, ainda assim, empregam estruturas básicas da programação estruturada e são imperativas, como as linguagens Java e C#, atualmente muito utilizadas e consideradas exemplos de sucesso de POO. (SAGAH, 2018) Smalltalk 80 foi primeira linguagem a implementar completamente os conceitos da POO, pois, em 1980, mesmo com a evolução dos módulos e pacotes pelas linguagens de programação da época, os problemas ainda persistiam. Um dos maiores problemas com os recursos atuais era que não existia mecanismo para inicialização e finalização automática do tipo fornecido. (SAGAH, 2018) Segundo Tucker e Noonan (2009, p. 307) “As inicializações normalmente necessárias incluem abertura de um arquivo, alocação de memória e inicialização de variáveis locais ao módulo”. Já quanto às finalizações, incluem o fechamento de arquivos e a liberação de memória. 22 Além disso, alguns programadores e projetistas começaram a perceber que algumas necessidades não eram atendidas com as atuais linguagens de programação imperativa de decomposição funcional e abstração de dados, como os padrões de graphical user interfaces (GUI), que poderiam ser melhor implementadas com o conceito de objetos que pudessem trocar mensagens uns com os outros. Uma GUI poderia ser mais facilmente implementada se considerarmos, por exemplo, que seus componentes (botões, áreas de texto, imagens etc.) são tratados como objetos que podem interagir entre si e com o usuário do sistema. (SAGAH, 2018) Assim, a POO surge como um paradigma centrado no desenvolvimento de objetos, no lugar da atual decomposição funcional e abstração de dados. Na Figura, você pode perceber um pouco dessa diferença entre a atual programação estruturada e o conceito de objetos. (SAGAH, 2018) Em uma linguagem de POO, o encapsulamento dos tipos de dados e suas funções é alcançado por meio da implementação das classes. Uma classe é uma declaração de um tipo de objeto que encapsula os seus tipos de dados pelos seus atributos e funções por meio de seus métodos. É comum ouvir falar que uma classe serve como uma matriz de objetos, pois, ao determinar os seus atributos e métodos, 23 serve como um modelo para que diversas instâncias de um objeto sejam criadas a partir de sua estrutura. (SAGAH, 2018) Ao analisar a Figura, você pode perceber que um programa em programação estrutural possui um desempenho melhor que um mesmo programa em POO, e isso ocorre pelo fato de, na programação estruturada, um código ser executado após o outro sequencialmente, ao passo que na POO são necessários alguns desvios. Entretanto, a POO traz outros pontos que acabam sendo mais interessantes no contexto de aplicações modernas. Como, na maioria das aplicações, o desempenho das aplicações não é uma das grandes preocupações (devido ao poder de processamento dos computadores atuais), a POO se tornou muito difundida. (SAGAH, 2018) Na próxima seção, vamos abordar como as linguagens Java, C# e Python implementam os conceitos da POO. Essas linguagens serão exemplos por serem muito utilizadas atualmente no contexto de desenvolvimento de software. 7.1 Linguagens orientadas a objetos Agora, você entenderá um pouco sobre as linguagens Java, C# e Python, atualmente muito utilizadas e que implementam os conceitos da POO. (SAGAH, 2018)Java é uma linguagem de programação que foi desenvolvida pela Sun Microsystems no início da década de 1990. Ela se tornou um símbolo da POO, inclusive causando certa confusão, por julgarem que a POO era um paradigma de Java e não ao contrário (MACHADO; FRANCO; BERTAGNOLLI, 2016, p. 54). De fato, a característica mais marcante da linguagem de programação Java está relacionada a sua portabilidade, pois os sistemas construídos não são compilados em código nativo da plataforma. Programas em Java são compilados para um bytecode, que é executado por uma máquina virtual, a Java virtual machine, que permite que os programas escritos em Java possam ser rodados em qualquer plataforma compatível com a sua máquina virtual. (SAGAH, 2018) 24 Em Java, todo o programa usa classes e objetos, e é fundamental que o programador compreenda esses conceitos da POO para conseguir programar em Java. Os programas são escritos em pequenos pedaços separados, chamados de objetos. Segundo Machado, Franco e Bertagnolli (2016, p. 78), “Objetos são pequenos programas que guardam dentro de si os dados — em suma, as variáveis — que precisam para executar suas tarefas”. Os objetos também trazem em si, como sub-rotinas, as instruções para processar esses dados. As variáveis que um objeto guarda são chamadas de atributos, e as suas sub- -rotinas são chamadas de métodos. (SAGAH, 2018) Veja o exemplo de uma classe Cachorro em Java com os atributos nome, peso, altura e cor e o método pular (). Como você pode observar, a programação em Java é praticamente regrada pelos conceitos de POO, e as classes são a base de qualquer código Java. Qualquer análise para um novo programa em Java deve partir do entendimento do seu contexto e projeção das classes. (SAGAH, 2018) 25 Agora, vamos analisar a linguagem C#. A linguagem C# (lê-se C Sharp) é definida pela Microsoft, que a desenvolve como uma linguagem de POO que faz parte de sua plataforma de desenvolvimento .NET. Embora a linguagem C# tenha sido criada totalmente do zero pela Microsoft, foi baseada na linguagem C++, e possui muitos elementos das linguagens Java e Pascal. (SAGAH, 2018) A plataforma .NET na qual teve seu desenvolvimento inicial, apresentou algumas limitações que motivaram que, em 1999, fosse montada uma força tarefa para o desenvolvimento de uma nova linguagem para essa plataforma. Segundo Ledur (2018, p. 108): A criação da linguagem C# ajudou muito no desenvolvimento do .NET, pois a plataforma não precisou se adequar a nenhum código de alguma linguagem já existente. O C# foi criado especificamente para .NET, sendo que muitas outras linguagens têm suporte à C#. Os principais objetivos do projeto da linguagem C# são: • Ser simples moderna e de propósito geral OO. • Ter uma linguagem e suas implementações que forneçam suporte para princípios de engenharia de software. • Ser destinada à utilização no desenvolvimento de componentes de software. • Possibilitar a portabilidade dos programas escritos em C#, assim como é possível na linguagem Java. • Fornece suporte para a escrita de programa, tanto hospedados localmente como incorporados. A Figura a seguir mostra um exemplo da estrutura de uma classe em C#. 26 Você pode perceber que, assim como em Java, C# possui uma estrutura semelhante com a declaração dos atributos da classe logo no início e depois em seus métodos, além de uma semelhança na sintaxe entre as duas linguagens, o que é explicado devido ao embasamento do C# na linguagem Java. (SAGAH, 2018) Para finalizar esta seção, vamos abordar a POO na linguagem de programação Python, que é uma linguagem de programação bastante utilizada por sua facilidade de aprendizado, aliada as suas características de programação de alto nível, de script, imperativa, OO e interpretada. (SAGAH, 2018) Python é uma linguagem que permite o desenvolvimento tanto no conceito de programação estruturada como a POO. Possui suporte a tipificação dinâmica, recursos de gerenciamento de uso de memória, além de oferecer uma abrangente biblioteca padrão. Os interpretadores Python possuem suporte para diversos sistemas operacionais, possibilitando a adaptação dos sistemas construídos. (SAGAH, 2018) 27 A origem do nome Python, apesar de confundido com o animal cobra, na realidade é oriunda do grupo de comédia britânico que era assistido pelo criador da linguagem, chamado Monty Python, formado por Graham Chapman, John Cleese, Eric Idle, Michael Palin, Terry Jones e Terry Gilliam. (SAGAH, 2018) Carinhosamente, são chamados de Pythonistas os programadores Python, e as referências aos trabalhos do grupo de comédia estão espalhadas pelos tutoriais e sua documentação (LUTZ; ASCHER, 2007). Python é uma linguagem muito simples, fácil de usar e aprender, apesar disso, também é uma linguagem extremamente robusta e utilizada nas mais diversas soluções: • back-end de sistemas Web, customer relationship management (CRM), ou gerenciamento de relacionamento com o cliente; • pesadas simulações de engenharia; • processamento pesado de efeitos especiais de filmes; • soluções de análise de dados (data analytics); • aprendizado de máquina, do inglês machine learning (ML). Veja o exemplo de uma classe Pessoa em Python 28 Apesar da sintaxe do Python ser um pouco diferente da sintaxe de Java e C#, é possível verificar a estrutura da classe com a definição de atributos e métodos e que Python é outro exemplar de linguagem OO. Na próxima seção, você verá alguns exemplos da aplicação da programação OO em classes de exemplos, para fixar o entendimento. (SAGAH, 2018) 8 DESENVOLVENDO COM PROGRAMAÇÃO ORIENTADA A OBJETOS Para ajudar a elucidar o conceito de POO, vamos começar analisando a seguinte situação: um exemplo em Java que demonstra a criação da classe Pessoa com os atributos nome, dataNascimento e CPF; e o método tirarCopias, que calcula o custo da geração de cópias em um sistema de gestão de impressões de uma escola. (SAGAH, 2018) Esse sistema deve calcular o valor da cópia embasado na seguinte regra: • para alunos da escola, o valor unitário da cópia será de R$ 0,07; • para os demais usuários, o valor unitário será de R$ 0,10. A diferença é que este requisito será implementado com os seguintes conceitos da POO: 29 • classes; • heranças. Observe na Figura, onde consta a classe Pessoa. Na classe Pessoa podemos observar os seguintes atributos: • nome; • cpf; • data nascimento. Observamos, também, que essa classe possui o método tirarCopias, que faz o cálculo do valor da cópia para pessoas em geral, ou seja, pessoas que não são alunos. Porém, você pode estar se perguntando, onde estão os dados do aluno e o método que faz o cálculo do valor da cópia quando se trata de um aluno? (SAGAH, 2018) Esses dados estão na classe Aluno, mas, como o Aluno também é uma pessoa e tem alguns atributos que são comuns as demais pessoas, não vamos repetir na classe Aluno. A Figura mostra como ficaria a classe Alunos em Java. 30 É possível, portanto, observar que no início da classe Aluno existe a declaração extends. Essa declaração significa que a classe Aluno está dizendo que herda a classe Pessoa, dessa forma, os atributos que são comuns à classe Pessoa não necessitam ser repetidos. Além disso, percebe-se que a classe Aluno possui o atributo matrícula, que é específico do Aluno. (SAGAH, 2018) Por fim, veja que, na classe Aluno, o método tirarCopias é alterado de acordo com o valor específico para os Alunos, o que é possível em razão de um outro recurso de POO: o polimorfismo. Polimorfismo é um recurso que permite ao objeto ter um comportamento diferente, dependendo da situação. Nesse caso, o cálculo do valor da cópia se altera por conta da situação de desconto de aluno.Pelos exemplos apresentados, percebe-se na prática alguns recursos e usos da programação OO e seus benefícios para a programação, possibilitando, principalmente, a reutilização do código. (SAGAH, 2018) Conceitos como os observados nos exemplos das Figuras 3 e 4 são casos comuns em POO, por isso é importante todo programador conseguir abstrair classes com seus atributos e métodos separados e, quando utilizar conceitos bases da POO, como herança de classes, evitar reutilização de código. (SAGAH, 2018) 31 9 REFERÊNCIAS BELL, D. Fundamentos básicos de UML: o diagrama de classes. Uma introdução aos diagramas de estrutura em UML 2. IBM developerWorks, Nova York, 2016. Disponível em: Accesso em: 22/07/2020. COCKBURN, A. Writing Effective Use-Cases. Reading: Addison-Wesley, 2001. GAMMA, E. et al. PADRÕES DE PROJETOS: Soluções reutilizáveis de software orientado an objeto. 1. Ed. Porto Alegre: Bookman, 2007. P. 17- 20. GASPAROTTO, H. M. Os 4 pilares da Programação Orientada a Objetos. DevMedia, Rio de Janeiro, 2014. Disponível em: https://www.devmedia.com.br/os-4-pilares-da- -programacao-orientada-a- objetos/9264. Acesso em: 15 set. 2019. GEOVANE, H. Entendendo e Aplicando Herança em Java. DevMedia, Rio de Janeiro, 2012. Disponível em: https://www.devmedia.com.br/entendendo-e-aplicando-heranca-em- - java/24544. Acesso em: 15 set. 2019. FOWLER, M. UML Distilled. 3. ed. Reading: Addison-Wesley.2003. JACOBSON, I. Object-Oriented Software Engineering. Reading: Addison- Wesley, 1992. LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo.3. ed. Porto Alegre: Bookman, 2007. 32 LEDUR, C. L. Desenvolvimento de sistemas com C#. Porto Alegre: SAGAH, 2018. 268 p. LUTZ, M.; ASCHER, D. Aprendendo Python. 2. ed. Porto Alegre: Bookman; O’Reilly, 2007. 566 p. MACHADO, R. P.; FRANCO, M. H. I.; BERTAGNOLLI, S. C. Desenvolvimento de software III: programação de sistemas web orientada a objetos em Java. Porto Alegre: Bookman, 2016. 220 p. (Série Tekne; Eixo Informação e Comunicação). RODRIGUES, J. Como criar minha primeira classe em C#. DevMedia, Rio de Janeiro, 2017. Disponível em: https://www.devmedia.com.br/como-criar- minha-primeira-classe-em- -csharp/38785. Acesso em: 22/07/2020. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016. SCHACH, S.R. Engenharia de software: os paradigmas clássicos e orientado a objetos. 7. ed. Porto Alegre: AMGH, 2010. SEBESTA, R. W. Conceitos de linguagem de programação. 11. ed. Porto Alegre: Bookman, 2018. 758 p. SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011. TUCKER, A. B.; NOONAN, R. E. Linguagens de programação: princípios e paradigmas. 2. ed. Porto Alegre: AMGH, 2009. 630 p.
Compartilhar