Baixe o app para aproveitar ainda mais
Prévia do material em texto
2015 Análise OrientAdA A ObjetOs i Prof. Jean Carlos Possamai Copyright © UNIASSELVI 2015 Elaboração: Prof. Jean Carlos Possamai Revisão, Diagramação e Produção: Centro Universitário Leonardo da Vinci – UNIASSELVI Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri UNIASSELVI – Indaial. 005.1 P856ac Possamai, Jean Carlos Análise orientada a objetos I / Jean Carlos Possamai. Indaial : UNIASSELVI, 2015. 189 p. : il. ISBN 978-85-7830-874-2 1. Programação orientada a objetos. I. Centro Universitário Leonardo Da Vinci. Impresso por: III ApresentAçãO Prezado(a) acadêmico(a)! Seja bem-vindo ao mundo da Programação Orientada a Objetos. Neste universo você vai se deparar com termos como atributos, métodos, abstração, encapsulamento, classes, hierarquia das classes, processo unificado, entre outros, que compõem o material de estudo desta disciplina e, por consequência, o dia a dia de um analista, desenvolvedor, programador, ou seja, o profissional da programação. Este caderno pressupõe que você já possua alguma experiência anterior em programação, principalmente JAVA, afinal muitos dos objetos, classes e diagramas apresentados neste material estão voltados a esta linguagem de programação. É essencial você fazer uso dos conhecimentos adquiridos em disciplinas anteriores para então conseguir acompanhar o desenvolvimento de um sistema e assim auxiliar você na construção do entendimento em programação orientada a objetos. Aproveito a oportunidade para destacar a importância de desenvolver as autoatividades, afinal cada exercício deste caderno foi desenvolvido para a fixação de conceitos por meio da prática. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com seu Tutor Externo ou com a tutoria da Uniasselvi, não prosseguindo as atividades sem ter sanado todas as dúvidas que irão surgindo. Vale destacar a necessidade de dedicação e de muita determinação, afinal a Programação Orientada a Objetos exige de você bem mais do que apenas este caderno para sua total compreensão. Aqui, você recebe somente um início, ou seja, os conceitos de determinados pontos importantes na programação, porém é somente na prática que você consegue compreender o mundo da programação como um todo. Lembre-se que o mundo da informática é encantador, assim, seu entusiasmo por este universo depende somente de você, destacando neste momento a compreensão da lógica envolvida no processo de construção de programas. Por este motivo, destaco uma frase que considero importante no caso da programação, afinal: “Para se ter sucesso, é amar de verdade o que se faz. Caso contrário, levando em conta apenas o lado racional, você simplesmente desiste. É o que acontece com a maioria das pessoas “ (Steven Jobs – criador da Apple). Bom estudo! Sucesso na sua trajetória acadêmica e profissional! JEAN CARLOS POSSAMAI IV Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material. Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura. O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo. Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão. Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade. Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos! NOTA Olá acadêmico! Para melhorar a qualidade dos materiais ofertados a você e dinamizar ainda mais os seus estudos, a Uniasselvi disponibiliza materiais que possuem o código QR Code, que é um código que permite que você acesse um conteúdo interativo relacionado ao tema que você está estudando. Para utilizar essa ferramenta, acesse as lojas de aplicativos e baixe um leitor de QR Code. Depois, é só aproveitar mais essa facilidade para aprimorar seus estudos! UNI V VI VII UNIDADE 1 - O PARADIGMA DA ORIENTAÇÃO A OBJETOS ............................................. 1 TÓPICO 1 - HISTÓRICO .................................................................................................................... 3 1 INTRODUÇÃO .................................................................................................................................. 3 2 O QUE SÃO OBJETOS? ................................................................................................................... 3 2.1 OBJETOS COMPUTACIONAIS .................................................................................................. 5 2.2 OS DIFERENTES TIPOS DE OBJETOS COMPUTACIONAIS ............................................... 5 2.2.1 Objetos computacionais visuais......................................................................................... 5 2.2.2 Objetos com tarefa relacionada .......................................................................................... 6 2.2.3 Objetos multimídias ............................................................................................................ 7 2.2.4 Objetos de domínio do trabalho ........................................................................................ 8 2.3 ORIENTAÇÃO A OBJETOS ........................................................................................................ 9 2.3.1 Análise orientada a objetos ................................................................................................. 9 2.3.2 Análise orientada a objetos ................................................................................................. 10 2.3.3 Vantagens e benefícios da orientação a objetos ............................................................... 11 RESUMO DO TÓPICO 1..................................................................................................................... 13 AUTOATIVIDADE .............................................................................................................................. 14 TÓPICO 2 - PROCESSO UNIFICADO (UP) ................................................................................... 17 1 INTRODUÇÃO .................................................................................................................................. 17 2 CARACTERIZAÇÃO DO UP .......................................................................................................... 18 2.1 FASES DO UP ................................................................................................................................ 22 2.2 RUP – RATIONAL UNIFIED PROCESS .................................................................................... 25 2.2.1 Blocos de Construção do RUP ........................................................................................... 27 2.2.2 Papéis no RUP ...................................................................................................................... 27 2.2.2.1 Papel do Analista .....................................................................................................27 2.2.2.2 Papel do Desenvolvedor ......................................................................................... 28 2.2.2.3 Papel de Testador ..................................................................................................... 29 2.2.2.4 Papel de Gerente ...................................................................................................... 29 2.2.2.5 Outros Papéis............................................................................................................ 30 2.2.3 AUP – Agile Unified Process .............................................................................................. 32 2.2.4 Open UP – Open Unified Process ..................................................................................... 34 2.2.5 EUP – Enterprise Unified Process ..................................................................................... 35 2.2.6 RUP-SE – Rational Unified Process – Systems Engineering ......................................... 36 RESUMO DO TÓPICO 2..................................................................................................................... 38 AUTOATIVIDADE .............................................................................................................................. 39 TÓPICO 3 - ESTRUTURAS E RELACIONAMENTOS ................................................................. 41 1 INTRODUÇÃO .................................................................................................................................. 41 2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS ................................................................ 41 2.1 ESTRUTURA GENERALIZAÇÃO – ESPECIALIZAÇÃO (GE) ............................................ 42 2.2 ESTRUTURA TODO – PARTE (TP) ........................................................................................... 43 2.3 CONEXÕES ................................................................................................................................... 44 2.3.1 Conexões de ocorrência ...................................................................................................... 44 sumáriO VIII 2.3.2 Cardialidade ......................................................................................................................... 45 2.3.3 Conexão de mensagem ....................................................................................................... 45 2.3.4 Polimorfismo ........................................................................................................................ 47 LEITURA COMPLEMENTAR ............................................................................................................ 48 RESUMO DO TÓPICO 3..................................................................................................................... 54 AUTOATIVIDADE .............................................................................................................................. 55 UNIDADE 2 - UNIFIED MODELING LANGUAGE (UML) ........................................................ 57 TÓPICO 1 - INTRODUÇÃO A UML ................................................................................................ 59 1 INTRODUÇÃO .................................................................................................................................. 59 2 BREVE HISTÓRICO DA UML ....................................................................................................... 59 3 POR QUE MODELAR SOFTWARE? .............................................................................................. 61 3.1 LEVANTAMENTO E ANÁLISE DE REQUISITOS .................................................................. 63 3.2 PROTOTIPAÇÃO ......................................................................................................................... 65 3.3 PRAZOS E CUSTOS ..................................................................................................................... 67 3.4 MANUTENÇÃO ........................................................................................................................... 68 3.5 DOCUMENTAÇÃO HISTÓRICA .............................................................................................. 70 4 EVOLUÇÃO ........................................................................................................................................ 71 RESUMO DO TÓPICO 1..................................................................................................................... 73 AUTOATIVIDADE .............................................................................................................................. 74 FASES DO DESENVOLVIMENTO DE UM SISTEMA UML ...................................................... 77 1 INTRODUÇÃO .................................................................................................................................. 77 2 ANÁLISE DE REQUISITOS ............................................................................................................ 77 3 ANÁLISE ............................................................................................................................................. 79 4 DESIGN (PROJETO) .......................................................................................................................... 81 5 PROGRAMAÇÃO ............................................................................................................................. 82 RESUMO DO TÓPICO 2..................................................................................................................... 84 AUTOATIVIDADE .............................................................................................................................. 85 TÓPICO 3 - MODELOS DE ELEMENTOS ..................................................................................... 87 1 INTRODUÇÃO .................................................................................................................................. 87 2 CLASSES ............................................................................................................................................. 87 3 OBJETOS ............................................................................................................................................. 89 4 ESTADOS ............................................................................................................................................ 90 5 PACOTES............................................................................................................................................. 91 6 COMPONENTES ............................................................................................................................... 92 7 RELACIONAMENTOS .................................................................................................................... 93 8 MECANISMOS GERAIS ................................................................................................................. 98 LEITURA COMPLEMENTAR ............................................................................................................ 101 RESUMO DO TÓPICO 3..................................................................................................................... 103 AUTOATIVIDADE .............................................................................................................................. 104 UNIDADE 3 - DIAGRAMAS ............................................................................................................. 107 TÓPICO 1 - DIAGRAMAS DE CASOS DE USO ........................................................................... 109 1 INTRODUÇÃO .................................................................................................................................. 109 2 ATORES ...............................................................................................................................................109 3 CASO DE USO ................................................................................................................................... 111 4 DOCUMENTAÇÃO DE CASOS DE USO .................................................................................... 113 5 ASSOCIAÇÕES .................................................................................................................................. 114 IX 6 INCLUSÃO ......................................................................................................................................... 114 7 EXTENSÃO ......................................................................................................................................... 115 8 ESPECIALIZAÇÃO/ GENERALIZAÇÃO .................................................................................... 117 9 EXEMPLOS DE DIAGRAMA DE CASOS DE USO ................................................................... 119 RESUMO DO TÓPICO 1..................................................................................................................... 122 AUTOATIVIDADE .............................................................................................................................. 123 TÓPICO 2 - DIAGRAMA DE CLASSES .......................................................................................... 125 1 INTRODUÇÃO .................................................................................................................................. 125 2 CLASSES, ATRIBUTOS E MÉTODOS ......................................................................................... 125 3 ABSTRAÇÃO...................................................................................................................................... 129 4 ENCAPSULAMENTO....................................................................................................................... 130 4.1 HIERARQUIA DAS CLASSES .................................................................................................... 133 5 HERANÇA .......................................................................................................................................... 133 5.1 HERANÇA MÚLTIPLA ............................................................................................................... 135 6 CLASSE ASSOCIATIVA .................................................................................................................. 137 7 RESTRIÇÃO ....................................................................................................................................... 139 8 PERSISTÊNCIA ................................................................................................................................. 139 9 EXEMPLOS DE DIAGRAMAS DE CLASSES ............................................................................. 140 RESUMO DO TÓPICO 2..................................................................................................................... 148 AUTOATIVIDADE .............................................................................................................................. 149 TÓPICO 3 - DIAGRAMA DE SEQUÊNCIA ................................................................................... 151 1 INTRODUÇÃO .................................................................................................................................. 151 2 ATORES ............................................................................................................................................... 151 3 OBJETOS ............................................................................................................................................. 152 4 LINHA DE VIDA ............................................................................................................................... 152 5 FOCO DE CONTROLE OU ATIVAÇÃO ...................................................................................... 153 6 MENSAGENS OU ESTÍMULOS .................................................................................................... 154 7 MENSAGENS DE RETORNO ........................................................................................................ 156 8 AUTOCHAMADAS OU AUTODELEGAÇÕES ......................................................................... 157 9 CONDIÇÕES OU CONDIÇÕES DE GUARDA ......................................................................... 158 10 EXEMPLOS DE DIAGRAMAS DE SEQUÊNCIA .................................................................... 159 RESUMO DO TÓPICO 3..................................................................................................................... 164 AUTOATIVIDADE .............................................................................................................................. 165 TÓPICO 4 - DEMAIS DIAGRAMAS EXISTENTES ..................................................................... 167 1 INTRODUÇÃO .................................................................................................................................. 167 2 DIAGRAMAS DE SERVIÇOS ........................................................................................................ 167 3 DIAGRAMA DE COLABORAÇÃO .............................................................................................. 169 4 DIAGRAMA DE ATIVIDADES ..................................................................................................... 172 5 DIAGRAMAS DE ESTADOS ......................................................................................................... 174 LEITURA COMPLEMENTAR ............................................................................................................ 176 RESUMO DO TÓPICO 4..................................................................................................................... 183 AUTOATIVIDADE .............................................................................................................................. 184 REFERÊNCIAS ...................................................................................................................................... 187 X 1 UNIDADE 1 O PARADIGMA DA ORIENTAÇÃO A OBJETOS OBJETIVOS DE APRENDIZAGEM PLANO DE ESTUDOS Esta unidade tem por objetivos: • conhecer o histórico da programação orientada a objetos; • identificar e caracterizar os objetos; • compreender a cerca do Processo Unificado, sua caracterização e suas fases; • conhecer como se comporta o Processo Unificado na Programação Orien- tada, quais as suas caracterizações e suas fases; • compreender como ocorre a interação entre os objetos, ou seja, a estrutura e relacionamentos, existentes entre os objetos. Esta unidade de ensino está dividida em três tópicos, sendo que no final de cada um deles, você encontrará atividades que contribuirão para a apropriação dos conteúdos. TÓPICO 1 – HISTÓRICO TÓPICO 2 – PROCESSO UNIFICADO (UP) TÓPICO 3 – ESTRUTURAS E RELACIONAMENTOS 2 3 TÓPICO 1 UNIDADE 1 HISTÓRICO 1 INTRODUÇÃO Como já é de seu conhecimento, a tecnologia se encontra em constante evolução, seja em novos hardwares, gadgets e software. Especificamente falando de software, também é possível perceber que a forma como são desenvolvidos os softwares encontra-se em constante evolução. Neste contexto, vale destacar que ao final da década de 60 surgiu a “Engenharia de Software”, que veio para tentar solucionar problemas de qualidade e produtividade de software. Já nas duas décadas seguintes 70 e 80, vários estudiosos desenvolveram técnicas com propostas para solucionar estes problemas. Uma das técnicas desenvolvidas pela Engenharia de Software foi a orientação a objetos, que ocorreu na década de 90, sendo amplamente difunda entre a comunidade de desenvolvedores, afinal, apresentava maior fidelidade às situações em que são aplicadas no mundo real, como:maior produtividade, usabilidade e reusabilidade de funções e códigos. Nesta unidade serão abordados aspectos sobre o paradigma da orientação a objetos, sua origem, seus conceitos, suas aplicações, suas vantagens e como utilizá-los no contexto de desenvolvimento de software. 2 O QUE SÃO OBJETOS? Para que possamos iniciar nossos estudos sobre a Orientação a Objetos, vamos visualizar algumas definições básicas, como por exemplo, o que é um objeto? Correia e Tafner (2001, p. 1) se baseiam no dicionário Aurélio, onde temos as seguintes definições para palavra objeto: [Do lat. Objectu, part. De objicere, ´por, lançar diante´, ´expor´.] S.m. 1. Tudo que é exterior ao espírito; 2. Tudo que é aprendido pelo conhecimento, que não é o sujeito do conhecimento; 3. Tudo que é manipulável e manufaturável; 4. Tudo que é perceptível por qualquer dos sentidos; 5. Coisa, peça, artigo de compra e venda; 6. Matéria, assunto. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 4 Ambler (1998, p. 5) em seu estudo traz uma definição computacional de objeto onde “considera que qualquer indivíduo, lugar, coisa, tela, relatório ou conceito que seja aplicável ao sistema é um objeto”. Ex.: Em um sistema universitário, Arthur Dent é um estudante-objeto; ele atende a diversos seminários-objetos e está trabalhando em um mestrado-objeto. Já em um sistema bancário Artur é um cliente-objeto e possui uma conta corrente-objeto da qual emite cheque-objetos. FIGURA 1 – EXEMPLOS DE OBJETOS FONTE: Disponível em: <http://www.dreamstime.com/stock-photo-retro-objects-icons-detailed- set-image30928100>. Acesso em: 23 dez. 2014. TÓPICO 1 | HISTÓRICO 5 Objetos são, com frequência, semelhantes a outros tipos de objetos. Estudantes compartilham de características semelhantes (fazem os mesmos tipos de coisas, são descritos da mesma forma), cursos compartilham características semelhantes, contas bancárias compartilham características semelhantes e assim por diante. Assim, ao analisar as duas citações descritas acima, podemos concluir que objeto é uma coisa física (pedra), ou abstrata (uma equação ou conta corrente). 2.1 OBJETOS COMPUTACIONAIS Objetos computacionais procuram reproduzir as mesmas características e comportamentos dos objetos do mundo real dentro de um sistema. Correia e Tafner (2001) reforçam que os programadores podem interagir com estes objetos ativando características ou comportamentos, sem necessidade de entender o funcionamento interno do objeto computacional. Ou seja, para interagir com objetos, precisamos apenas conhecer o que estes objetos fazem e usá-los, nada mais. 2.2 OS DIFERENTES TIPOS DE OBJETOS COMPUTACIONAIS Para que você acadêmico possa compreender melhor a relação existente entre os objetos computacionais e seu comportamento agregado, seguem alguns tipos diferentes de objetos computacionais encontrados, bem como seus exemplos. 2.2.1 Objetos computacionais visuais A utilização de programação visual proporciona ao usuário uma experiência totalmente interativa. Desta forma, o usuário pode interagir com sistema computacional através do mouse ou teclado, apertando botões, selecionando itens de um calendário, escrevendo em um campo texto ou selecionando itens de uma lista, conforme ilustrado na figura 2. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 6 FIGURA 2 – OBJETOS COMPUTACIONAIS VISUAIS COMUNS PARA INTERFACE COM USUÁRIO FONTE: Sistema ERP Empresa Supero Tecnologia 2.2.2 Objetos com tarefa relacionada Os desenvolvedores de softwares utilizam os objetos computacionais visuais para desenvolver e realizar tarefas relacionadas a dados proporcionando aos usuários: janelas, campos ou botões com os quais estes possam interagir. Ex.: Um editor de textos qualquer, conforme representado na figura a seguir, é um bom exemplo. Neste editor, o documento é apresentado ao usuário por meio de uma interface gráfica (também orientada a objetos) que permite uma interação direta e praticamente total com o documento em que as barras de ferramentas são objetos com os quais o usuário pode interagir com o texto. TÓPICO 1 | HISTÓRICO 7 FIGURA 3 – OBJETOS COM TAREFA RELACIONADA COMUM PARA INTERFACE COM USUÁRIO FONTE: O autor 2.2.3 Objetos multimídias Os objetos multimídia proporcionam uma rica experiência de interação com o usuário. Este tipo de objeto computacional possibilita a reprodução de sons, imagens, animações ou vídeos da mesma forma que nos editores de texto. Como podemos verificar na figura a seguir, no reprodutor de fotos as barras de ferramentas são objetos que permitem que o usuário interaja com o conteúdo alterando seu comportamento. FIGURA 4 – OBJETOS MULTIMÍDIAS COMUNS PARA INTERFACE COM USUÁRIO FONTE: O autor UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 8 2.2.4 Objetos de domínio do trabalho São características ou compartimentos de um objeto ou sistema operacional, criado para ficar, na maioria das vezes, oculto aos usuários. Afinal, estes estão diretamente envolvidos com o funcionamento do sistema ou objeto computacional. Para exemplificar esta situação observe na figura a seguir o gerenciador de tarefas do sistema operacional. Ele está quase sempre oculto, garantindo que os milhares de objetos do sistema operacional que fazemos uso trabalhem adequadamente. FIGURA 5 – OBJETOS DE DOMÍNIO DE TRABALHO COMUNS PARA INTERFACE COM USUÁRIO FONTE: O autor TÓPICO 1 | HISTÓRICO 9 2.3 ORIENTAÇÃO A OBJETOS O conceito de Orientação a Objetos surgiu com o intuito de minimizar os problemas encontrados até então na criação de softwares complexos, projetados por meio de decomposição funcional e sub-rotinas (ARAÚJO, 2009). A análise e programação orientada a objetos, não se resume apenas na utilização de componentes de interface gráfica, mas, sim, na definição e programação do sistema computacional, desde que atenda à metodologia. Metodologia esta, que segundo Correia e Tafner (2001, p. 7) serve tanto para a definição lógica do sistema quanto para a sua implementação, sendo esta uma das vantagens da Orientação a Objetos. 2.3.1 Análise orientada a objetos Como já foi visto anteriormente, um objeto é qualquer coisa, real ou abstrata, a respeito da qual armazenamos dados e os métodos que os manipulam disparam operações que mudam o estado dos objetos, possibilitando que eles interagem uns com os outros. Segundo Araújo (2009, p. 46), “o foco da análise Orientada a Objetos é no mapeamento de uma solução sistêmica para algum processo de negócio”. Assim, na análise orientada a objetos, os analistas e desenvolvedores têm como objetivo principal identificar os objetos que farão parte do sistema computacional que está sendo automatizado, seus atributos e principalmente no comportamento destes objetos dentro do sistema computacional. Larman (2004, p. 31) descreve que durante a análise orientada a objetos, “o objetivo é encontrar e descrever os objetos – ou conceitos – no domínio do problema. No caso do sistema de informação de uma biblioteca, por exemplo, alguns dos conceitos incluem Livro, Biblioteca e usuário”, observe a representação por meio da figura a seguir, demonstrada na programação orientada a objetos. Orientação a Objetos consiste em considerar os sistemas computacionais como uma coleção de objetos que interagem de maneira organizada (FARINELLI, 2007). IMPORTANT E UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 10 2.3.2 Análise orientada a objetos Segundo Larman (2004, p. 31), “durante o projeto orientado a objetos, há uma ênfase na definição dos objetos de software e como eles colaboram para a satisfação dos requisitos. No sistema da biblioteca, por exemplo, um objeto de software Livro, pode ter um atributo título e um método obterCapítulo”, observe a figura a seguir. Em seu estudo David (2007, p. 1) define que a Programação Orientada a Objetos “foi criada para tentar aproximar o mundo real do mundo virtual. Assim, a ideia fundamental é tentar simular o mundo real dentro do computador. Paraisso, nada mais natural do que utilizar Objetos, afinal, nosso mundo é composto por objetos”. Na Programação Orientada a Objetos, o analista ou desenvolvedor é responsável por delinear o mundo dos objetos, e assim determinar como devem interagir entre si. Desta forma, é possível perceber que os objetos conversam entre si por meio de envio de mensagens, e, assim, a função do analista ou desenvolvedor é verificar quais devem ser as mensagens que cada objeto deve receber, e consequentemente verificar qual ação deve ser tomada ao receber cada mensagem. Finalmente Larman (2004) escreve que durante a implementação ou programação orientada a objetos, os objetos são implementados, como uma classe Livro em Java, conforme demonstra a figura seguinte. “a Análise Orientada a Objetos consiste em definir quais objetos fazem parte de um sistema e a maneira como se comportam” (CORREIA e TAFNER, 2001, p. 8). IMPORTANT E TÓPICO 1 | HISTÓRICO 11 FIGURA 6 – A ORIENTAÇÃO A OBJETOS ENFATIZA A REPRESENTAÇÃO DE OBJETOS FONTE: LARMAN (2004, p. 31) 2.3.3 Vantagens e benefícios da orientação a objetos Ao estudar a Orientação a Objetos, fica fácil perceber que sua principal vantagem é a utilização de uma mesma metodologia, tanto para a análise de sistemas, quanto para a programação. Neste contexto, Farinelli (2007) descreve que a Orientação a Objetos consiste em conceber um sistema computacional como um todo orgânico formado por objetos que se relacionam entre si, trazendo consigo alguns benefícios, como por exemplo: unificação entre dados e processos; consistência entre análise e desenvolvimento; reutilização e aumento da produtividade; multidesenvolvimento e, por último, mas não menos importante, suas facilidades de manutenção. “Programação Orientada a Objetos consiste em utilizar objetos computacionais para implementar a funcionalidade de um sistema”. (CORREIA e TAFNER, 2001, p. 8) IMPORTANT E UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 12 Assim, para finalizar o pensamento acerca deste tema, pode-se verificar que a principal utilização desta ferramenta é a reutilização das informações constantes no sistema. 13 Neste tópico, vimos: • O Paradigma da Orientação a Objetos, que trata da utilização no desenvolvimento de softwares, seu histórico; afinal, surgiu há algumas décadas e, desde então, vem sendo difundido e adaptado às necessidades do mercado. • Os objetos e seus diferentes tipos: objetos computacionais, objetos visuais, objetos multimídias, objetos de domínio do trabalho e objetos com tarefa relacionada. • A análise e programação orientada a objetos, que segundo David (2007), a Programação Orientada a Objetos foi criada para tentar aproximar o mundo real do mundo virtual. Assim, a ideia fundamental é tentar simular o mundo real dentro do computador. Neste momento, você está apto a realizar as autoatividades deste tópico e iniciar na sequência, o Tópico 2 desta unidade. Bom estudo! RESUMO DO TÓPICO 1 14 AUTOATIVIDADE 1 Na área da informática um objeto pode ser considerado qualquer indivíduo, lugar, coisa, tela, relatório ou conceito que seja aplicável ao sistema. Com base nesta definição, cite os diversos tipos de objetos computacionais. 2 São características ou compartimentos de um objeto ou sistema operacional, criados para ficarem, na maioria das vezes, ocultos aos usuários. Esta afirmação se refere a: a) Objetos multimídias. b) Objeto domínio de trabalho. c) Objetos computacionais visuais. d) Objetos com tarefa relacionada. 3 Assinale V para as sentenças verdadeiras e F para as falsas no que diz respeito à Orientação a Objetos. ( ) A metodologia utilizada na Orientação a Objetos serve tanto para programação quanto para análise. ( ) A Análise Orientada a Objetos é bem definida e consiste em apresentar quais os objetos que compõem um sistema e como se comportam. ( ) Com relação à Programação Orientada a Objetos, ela somente utiliza a estrutura de dados que pode simular o comportamento dos objetos, prejudicando, desta forma, a análise e programação do sistema. ( ) Uma das vantagens da Análise de Orientação a Objetos do analista ou desenvolvedor é de dividir com o usuário seu entendimento acerca do programa. Agora, assinale a sequência CORRETA: a) ( ) V – F – F – V. b) ( ) F – F – V – F. c) ( ) V – V – F – V. d) ( ) F – V – F – F. 15 4 Utilizando-se das informações recebidas durante o estudo deste tópico, descreva a diferença em Análise e Programação Orientada a Objetos. 5 Descreva uma das principais vantagens da Orientação a Objetos. 16 17 TÓPICO 2 PROCESSO UNIFICADO (UP) UNIDADE 1 1 INTRODUÇÃO O Processo Unificado é um dos mais importantes padrões da indústria de software atual. Vale destacar que o processo unificado (UP ou Unified Process) foi desenvolvido por três importantes pioneiros da orientação a objetos nos anos 1990 (Jacobson, Booch e Rumbaugh). Este é o resultado de mais de 30 anos de experiência acumulada em forma de projetos, notações e processos. O UP é o primeiro modelo de processo inteiramente adaptado ao uso da notação UML (Unified Modeling Language). Sua concepção foi baseada nas práticas de maior Retorno do investimento (ROI) de mercado. Wazlawick (2013, p. 75) descreve ainda que as atividades do UP são bem definidas no seguinte sentido: a)Elas são compostas por uma descrição clara e precisa. b)Apresentam responsáveis. c)Nestas atividades apresentam-se os artefatos de entrada e saída. d)Determinam as dependências entre as atividades. e)Possuem um modelo de ciclo de vida bem definido. f)São acompanhadas de procedimentos adequados para o uso das ferramentas disponibilizadas. g)Indicam o uso da linguagem UML. Neste tópico será abordado acerca do Processo Unificado, principalmente sua caracterização, suas fases e por fim suas derivações. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 18 2 CARACTERIZAÇÃO DO UP O UP é um framework extensível para a concepção de processos, podendo ser adaptada as características de diferentes empresas e projetos (WAZLAWICK, 2013). Vejamos a seguir as principais características do UP: a) Dirigido por Caso de Uso Este é um processo compreendido do ponto de vista do usuário, não antecipando decisões de implementações. Para o UP, o conjunto de casos de uso deve esgotar toda a funcionalidade possível do sistema. Neste momento, vale destacar, a aplicação mais fundamental do caso de uno no desenvolvimento de sistemas é a incorporação dos requisitos funcionais de forma organizada. Cada passo dos fluxos principais e alternativos de um caso corresponde a uma função do sistema. Requisitos não funcionais podem ser anotados juntamente com os casos de usos de seus passos, e requisitos suplementares são anotados em um documento à parte (WAZLAWICK, 2013). FIGURA 7 – CASOS DE USO FONTE: Disponível em: <http://www.devmedia.com.br/artigo-clube-delphi-83-modelagem-uml- com-together/11031>. Acesso em: 23 dez. 2014. Cadastrar Curso Cadastrar Professor Cadastrar Disciplina Cadastrar Aluno Matricular Aluno Secretaria TÓPICO 2 | PROCESSO UNIFICADO (UP) 19 a) Centrado na arquitetura O UP sugere desenvolver uma sólida arquitetura de sistema. As funcionalidades identificadas nos diversos casos de uso devem ser incrementadas a esta arquitetura. É importante destacar que a arquitetura pode ser compreendida como o conjunto de classes, possivelmente agrupadas em componentes que realizam operações definidas pelo sistema. Para Wazlawick (2013, p. 76), “a arquitetura é basicamente um modelo que define a estrutura da informação, suas possíveis operações e sua organização em componentes ou até mesmo em camadas”. FIGURA 8 – CENTRADO NA ARQUITETURA FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014. A arquitetura se desenvolve por meio das visões dos usuários demonstradas em casos de uso, sendo esta influenciada por fatores de implementação: arquitetura de computador, sistema operacional, dbms, protocolosde redes, linguagem de programação, ambiente de interface gráfica, biblioteca de funções disponíveis, sistemas legados, necessidade de performance, portabilidade, entre outros. Application-specific layer Classes específicas de negócio Application-general layer Classes de Serviços Middleware layer Pacotes Genéricos System-software layer Sistemas Operacionais UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 20 FIGURA 9 – FATORES QUE INFLUENCIAM A ARQUITETURA FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014. a) Interativo e Incremental “Assim como os desenvolvimentos ágeis, o UP preconiza o desenvolvimento baseado em ciclos interativos de duração fixa, onde em cada interação a equipe incorpora à arquitetura as funcionalidades necessárias para realizar os casos de uso abordados”. (WAZLAWICK, 2013, p. 77). Lembre-se, acadêmico(a), para cada interação os desenvolvedores identificam os casos de uso relevante, analisando-os segundo a arquitetura selecionada. Ao final, o produto da interação é componente (modelos ou módulos executáveis). Desta forma, verifica-se então se os componentes satisfazem os casos de uso e a arquitetura. Se a implementação atinge os objetivos, ou seja, seus componentes satisfazem os casos de uso e a arquitetura, o desenvolvimento passa para a próxima interação, caso contrário, os desenvolvedores devem revisar as decisões anteriores e tentar uma nova abordagem (REBOUÇAS, 2007). System software Middleware (including frameworks) Legacy systems Standards and policies Nonfunctional requirements Distribution needs Constraints and Enablers Use Cases Architecture Experience: Previous architectures Architectural patterns TÓPICO 2 | PROCESSO UNIFICADO (UP) 21 FIGURA 10 – DESENVOLVIMENTO INTERATIVO E INCREMENTAL FONTE: Disponível em: <http://www.devmedia.com.br/introducao-ao-processo-unificado/3931>. Acesso em: 23 dez. 2014. Como principais benefícios do desenvolvimento interativo, Larman (2004, p. 41) destaca: a)Mitigação precoce. b)Progresso visível desde o início. c)Realimentação, envolvimento do usuário e adaptação imediatos, levando a um sistema refinado que atenda, de forma mais adequada, às reais necessidades dos interessados no projeto. d)A complexidade é administrada, desta forma, a equipe não é sobrecarregada pela paralisia da análise ou por passos muito longos e complexos. e)O aprendizado obtido em uma interação pode ser metodicamente usado para melhorar o próprio processo de desenvolvimento, interação por interação. a) Focado em riscos Este tipo de abordagem prioriza os casos de uso mais crítico onde são tratados primeiro os problemas mais difíceis. Neste caso, os requisitos ou casos de uso de maior risco são os mais imprevisíveis, assim, estudá-los primeiramente além de garantir maior aprendizado sobre o sistema e decisões arquiteturais, vai fazer com que riscos arquiteturais sejam dominados o mais cedo possível. Realimentação da iteração N leva ao refinamento e adaptação dos requisitos e do projeto na iteração N+1 RequisitosTempo N N+1 Quatro semanas por exemplo. O sistema cresce incrementalmente. Requisitos Implementação Implementação Testes e Integração Testes e Integração Projeto Projeto UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 22 2.1 FASES DO UP Caro(a) acadêmico(a)! Observe, a seguir, quais são as fases que compõem a construção de um UP, e ao final das descrições, observe a figura que demonstra como essas fases se comportam durante o processo. a) Concepção (inception) Busca-se obter uma visão da abrangência do sistema. Nesta fase são levantados os requisitos, e um modelo conceitual preliminar é construído, bem como ocorre a identificação dos casos de uso de alto nível, que implementam as funcionalidades requeridas pelo cliente. Neste momento calcula-se também o esforço de desenvolvimento dos casos de uso e é construído o plano de desenvolvimento, sendo este composto por um conjunto de ciclos interativos nos quais são acomodados os casos de uso. Pode haver, nesta fase, alguma implementação e testes, caso seja necessário elaborar protótipos para reduzir riscos, possibilitando assim a verificação dos casos de uso que requerem um maior cuidado. b) Elaboração (elaboration) As interações que ocorrem nesta fase têm como objetivo detalhar a análise e expandir os casos de uso, para obter assim sua descrição detalhada e verificar as situações excepcionais, ou seja, são voltadas para a produção da arquitetura básica, e vários casos de uso são demonstrados com detalhes, possuindo uma arquitetura projetada a qual utiliza-se de artefatos, os quais podem ser estáticos ou dinâmicos. O modelo conceitual será transformado em definitivo, cada vez mais refinado, sobre o qual serão aplicados padrões de análise e uma descrição funcional poderá ser feita, bem como o design lógico e físico do sistema. Ao final desta fase, é necessário que os desenvolvedores estejam aptos a planejar a fase seguinte a construção. TÓPICO 2 | PROCESSO UNIFICADO (UP) 23 c) Construção (construction) A fase de construção possui interações nas quais os casos de uso mais complexos já foram tratados e a arquitetura já foi estabilizada, afinal, o produto é construído no decorrer desta fase. Assim, as atividades de suas interações consistem predominantemente na geração de código e teste do sistema. Com a automação da geração de código e a introdução de modelos de desenvolvimento dirigidos a teste, pressupõe-se que um bom design possa dar origem rapidamente a um código de alta qualidade, ou seja, o sistema será composto por todos os casos de uso que a gerência e os usuários concordaram em desenvolver para esta versão do produto. Vale lembrar que mesmo que ocorram erros, estes podem ser corrigidos, estando aptos assim para seguir no processo e iniciar a próxima fase. d) Transição (deployment) Esta fase consiste na implementação do sistema no ambiente de produção, com a realização de teste e operação, onde a primeira versão do sistema é entregue ao usuário. Também, neste momento, é feita a transferência de dados de possíveis sistemas antigos para o novo sistema e o treinamento dos usuários, caso ocorram divergências no sistema, os usuários reportam-nas para os desenvolvedores, incorporando as melhorias. Nesta fase ainda pode haver alguma revisão de requisitos e geração de código, mas não de forma significativa. Após todas as definições, conforme mencionado no início deste tópico, observe a figura que demonstra as fases, bem como os fluxos de trabalhos no decorrer do processo de construção de um UP. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 24 FIGURA 11 – FASES DO UP – FLUXOS DE TRABALHO FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-o- processo-unificado-integrado-ao-desenvolvimento-web/803>. Acesso em: 23 dez. 2014. FIGURA 12 – EXEMPLO DE UM PROCESSO UNIFICADO FONTE: Disponível em: <http://slideplayer.com.br/slide/345298/>. Acesso em: 23 dez. 2014. Concepção Elaboração Construção Transição Inicial Elab.nº 1 Elab. nº 2 Const. nº 1 Const. nº 2 Const. nº N Trans. nº 1 Trans. nº 2 Teste Fluxo de trabalho Interações Ambiente Gerenciamento de Projeto Geren. de Configuração e Mudança Implantação Implementação Requisitos Análise e Design Modelagem de Negócios Fases Use-Case Model Analysis Model Design Model Deployment Model Implementation Model Test Model Specified by realized by distributed by implemented by verified by X OK X OK X OK TÓPICO 2 | PROCESSO UNIFICADO (UP) 25 Observe como se apresenta o ciclo de desenvolvimento de um UP. FIGURA 13 – CICLO DE DESENVOLVIMENTO UP FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014. Agora, acadêmico(a), que você conhece a definição de UP, bem como suas fases, chegou o momento de conhecer as derivações desta ferramenta de programação, as quais se apresentam a seguir, iniciando-sepor: RUP (Rational Unified Process), AUP (Agile Unified Process), OpenUp (Open Unified Process), EUP (Enterprise Unified Process), e finalizando com RUP-SE (Rational Unified Process – Systems Engineering). 2.2 RUP – RATIONAL UNIFIED PROCESS Micro Incremento Ciclo de Vida de Iteração Ciclo de Vida de Projeto Dias Semanas Meses Item de Trabalho Plano de Interação Plano de Projeto Foco no Indivíduo Foco na Equipe Foco nos Envolvidos Iniciação Elaboração Construção Trânsição Valor Ríscos Executável Estável Incremento Interação “Este processo de engenharia de software fornece uma abordagem para assumir tarefas e responsabilidades dentro de uma organização de desenvolvimento, cujo objetivo é assegurar a produção de software de alta qualidade dentro de prazos e orçamentos previsíveis”. (KRUCHTEN, 2003, p. 14). O autor ainda afirma que “Derivado dos trabalhos sobre UML e do Processo Unificado de Desenvolvimento de Software, ele captura seis das melhores práticas no desenvolvimento de software de forma satisfatória para uma grande faixa de projetos e organizações”. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 26 Em outras palavras, o autor quer dizer que o RUP é um método que pode ser utilizado no desenvolvimento de software, contemplando técnicas que os membros da equipe de desenvolvimento devem seguir para atingir o objetivo de aumentar sua produtividade. O RUP representa uma nova geração de processos genéricos, a mais importante inovação é a separação de fases e workflows, e sobretudo, o reconhecimento de que a implantação de software no ambiente do usuário é parte do processo. (SENE, 2015). FIGURA 14 – QUANDO DEVO UTILIZAR O RUP FONTE: Disponível em: <http://www.wthreex.com/rup/v711_ptbr/rup/guidances/supportingmaterials/ introduction_to_rup,_uRs44C8CEdqfj_h52-wqcw.html> e <http://www.tiespecialistas.com.br/2011/02/ rup-primeiros-passos/>. Acesso em: 23 dez. 2014. Maior Complexibilidade Técnica - Tempo real incorporado, distribuído, tolerância aos defeitos - Reengenharia de arquitetura sem precedentes, personalizada - Alto desempenho Menos Complexibilidade Técnica - Maioria 4 GL ou baseada em componentes - Reengenharia de aplicativo - Desempenho interativo Menor Complexibilidade de Gerenciamento - Pequena escala - Informal - Investidor único Maior Complexibilidade de Gerenciamento - Larga escala - Contratual - Muitos investidores Necessidade de alto "nível de cerimônia" TÓPICO 2 | PROCESSO UNIFICADO (UP) 27 2.2.1 Blocos de Construção do RUP Identificamos o conjunto de elementos básicos (building blocks) da seguinte forma: a) Quem: define o conjunto de habilidades necessário para realizar determinadas atividades. b) O quê: define algo produzido por uma atividade, como diagramas, relatórios ou código. c) Como: descreve uma unidade de trabalho atribuída a um papel que produz determinado conjunto de artefatos. d) Quando: definem as tendências entre as diferentes atividades. 2.2.2 Papéis no RUP O papel define um conjunto de comportamentos, habilidades e responsabilidades de uma pessoa da equipe. Os papéis dentro de um projeto não são necessariamente para pessoas específicas nem para cargos dentro da equipe. A mesma pessoa pode exercer vários papéis em diferentes momentos do dia, no mesmo projeto. Vejamos a seguir as categorias em que são organizados os papéis: 2.2.2.1 Papel do Analista O analista é o responsável por realizar o relacionamento ou contato com usuário ou cliente do sistema. As pessoas que exercem este papel devem ser capazes de entender quais são as necessidades do sistema, e criar descrições que sejam compreendidas pelos designers, desenvolvedores e testadores. Além de terem a responsabilidade de atentarem para as adequações de reais necessidades, bem como verificar a conformidade com normas e padrões estabelecidos. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 28 FIGURA 15 – PAPEL DO ANALISTA FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm. htm>. Acesso em: 23 dez. 2014. 2.2.2.2 Papel do Desenvolvedor Os desenvolvedores transformam os requisitos em produto de software e devem ter o conhecimento necessário para desenvolver os códigos-fonte e testá-los. FIGURA 16 – PAPEL DO DESENVOLVEDOR FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_implm. htm>. Acesso em: 23 dez. 2014. Implementar Componente Componente Realizar Teste Unitário Corrigir um Defeito Desenvolver Artefatos de Instalação Artefatos de Instalação Implementar Componentes de Teste e de Subsistemas Componente de Teste Subsistema de Implementação Implementador TÓPICO 2 | PROCESSO UNIFICADO (UP) 29 2.2.2.3 Papel de Testador É responsável por definir técnicas, estratégias, e principalmente definir os casos de testes que serão aplicados no sistema, ou seja, tem a função de analisar os resultados dos testes e no caso de necessidade, informar aos responsáveis que providenciem a correção. FIGURA 17 – PAPEL DO TESTADOR FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_tstr. htm>. Acesso em: 23 dez. 2014. 2.2.2.4 Papel de Gerente O papel de gerente está relacionado principalmente com as atividades de planejamento, controle e sobre tudo a organização do projeto. UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 30 FIGURA 18 – PAPEL DE GERENTE FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workers/wk_projm. htm>. Acesso em: 23 dez. 2014. 2.2.2.5 Outros Papéis Neste item é possível encontrar outros papéis que não foram classificados nos tipos anteriores como: interessados, desenvolvedor de curso, redator técnico e administrador de sistemas. Como o RUP é uma ferramenta adaptável, novos papéis podem ser necessários e adicionados a um projeto ou processo específico. TÓPICO 2 | PROCESSO UNIFICADO (UP) 31 FIGURA 19 – DESENVOLVEDOR DE CURSO FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/ workers/wk_crsdv.htm>. Acesso em: 23 dez. 2014. FIGURA 20 – ADMINISTRADOR DE SISTEMA FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/ workers/wk_sysad.htm>. Acesso em: 23 dez. 2014. Desenvolvedor do Curso Materiais de Treinamento Desenvolver Materiais de Treinamento responsável por Administrador do Sistema Suportar o Desenvolvimento Infraestrutura de Desenvolvimento responsável por UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 32 FIGURA 21 – REVISOR DE PROJETO FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/workflow/ovu_mgm. htm>. Acesso em: 23 dez. 2014. 2.2.3 AUP – Agile Unified Process O Agile Unified Process é uma versão simplificada do RUP, que aplica técnicas ágeis de desenvolvimento dirigido por testes (TDD), modelagem ágil e fatoração. A AUP teve sua origem no início do século XXI, por meio de um grupo de engenheiros, consultores, autores, os quais, após muito estudo, denominaram esta pesquisa de The Agile Manifesto, tendo então como objetivo a apresentação e discussão de novas técnicas que poderiam ser utilizadas para desenvolver softwares, disponibilizando maior agilidade por meio dos conceitos aplicados às metodologias já existentes. TÓPICO 2 | PROCESSO UNIFICADO (UP) 33 Após a criação deste manifesto, percebeu-se que a AUP seria um método ágil e que poderia atender às seguintes prerrogativas: a) Valorizar os indivíduos envolvidos no processo e as interações entre ambos. b) Produzir softwares funcionais, não somente documentações completas e atualizadas. c) Colaborar com os clientes e não apenas discutir picuinhas contratuais. d) Estar preparado para a adaptação e introdução de mudanças. Em sentido complementar, vale destacar os princípios que denominam a AUP: a) Assumir simplicidade. b) Flexibilidade para mudanças. c) O software é o primeiro objetivo. d) Viabilizar esforços futuros. e) Alterações incrementais. f) Maximizar o investimento dos interessados no software. g) Modelar com propósito.h) Múltiplos modelos. i) Trabalho com qualidade. FIGURA 22 – FASES DO AUP FONTE: Disponível em: <http://www.cs.sjsu.edu/~pearce/modules/lectures/se/aup. htm>. Acesso em: 23 dez. 2014. Testing Implementation Modeling Deployment UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 34 FIGURA 23 – Fases do AUP FONTE: Disponível em: <http://pt.slideshare.net/redecharles21/aup-seminario-final>. Acesso em: 23 dez. 2014. Ao contrário do RUP, conforme demonstra a figura acima, a AUP possui apenas sete disciplinas (Modelagem, Implementação, Teste, Implantação, Gerenciamento de configuração, Gerenciamento de projeto, Ambiente). A filosofia de produção de artefatos é minimalista, ou seja, deve gerar o mínimo necessário de artefatos para produzir um sistema com qualidade. 2.2.4 Open UP – Open Unified Process A OpenUP é uma implementação aberta da UP desenvolvida como parte do Eclipse Processes Framework, conhecida anteriormente como Basic Unified Process (BUP). OpenUP aceita, grande parte dos princípios utilizados no Processo Unificado, porém é um método independente de ferramenta, não exigindo grande precisão e detalhes nos documentos. O processo baseia-se em quatro princípios (Colaboração, Evolução, Balanceamento e Foco). O ciclo de vida também é dividido em quatro fases como no UP. Estas fases são divididas em interações, porém aqui as equipes se auto-organizam para planejar cada uma delas. Test Project Management Configuration Management Implementation Deployment Environment Model Inception I1 E1 C1 T1 T2C2 Cn Elaboration TransitionConstruction Phases Iterations TÓPICO 2 | PROCESSO UNIFICADO (UP) 35 FIGURA 24 – CICLO DE VIDA OpenUP FONTE: Disponível em: <http://open2up.blogspot.com.br/>. Acesso em: 23 dez. 2014. Em relação ao UP, a maioria dos processos opcionais foi eliminada e outros foram mesclados. O resultado é um processo mais simples, mais ainda fiel aos princípios do RUP. FIGURA 25 – MODELO DE CICLO DE VIDA DE UMA INTERAÇÃO OpenUp FONTE: Disponível em: <http://pt.slideshare.net/jeanstreleski/open-up-gerenciando-projetos- sob-principios-geis>. Acesso em: 23 dez. 2014. 2.2.5 EUP – Enterprise Unified Process O modelo EUP visualiza ao desenvolvimento de software não apenas como um projeto a ser desenvolvido, mais como algo intrínseco ao ciclo de vida da empresa. Este modelo foi proposto como uma extensão ao modelo RUP para prover, além das fases do RUP, duas novas fases para tratar a evolução ou suporte ao sistema e à aposentadoria do sistema. Iteration planning Stable weekly build Stable iteration build Iteration review / Retrospective Upfront planning and architecture Continuous micro-increments / bug-fixing / builds Continuous bug-fixing / micro-increments / builds A few hours A few hours A few days - Escopo do sistema - Requisitos do sistema - Custo geral do sistema - Riscos em potencial - Baseline da Arquitetura - Riscos em potencial - Componentes do sistema - Reusabilidade - Qualidade do sistema - Versões Alfa e Beta - Release do sistema - Teste Beta - Conversão do BD - Treinamentos - Distribuição - Documento de visão - Lista de riscos - Plano de interação - Glossário - Modelo de Caso de Uso - Protótipos - Protótipo - Modelo de Design - Modelo de Dados - Modelo de Implantação - Release do sistema - Casos de Testes - Material de Suporte - Release - Material de Suporte - Casos de Testes - Pacote de Distribuição Objetivos do Ciclo de Vida FASES MARCOS OBJETIVOS ARTEFATOS ElaboraçãoIniciação Arquitetura do Ciclo de Vida Construção Recurso Opera- cional Inicial Transição Liberação do Produto UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 36 FIGURA 26 – FASES EUP FONTE: Disponível em: <http://www.enterpriseunifiedprocess.com/>. Acesso em: 23 dez. 2014. O objetivo principal da disciplina de operação e suporte é manter o produto funcionando em produção. Afinal, estes devem garantir o correto funcionamento do software, a evolução dos processos, a realização dos backups, planos de recuperação de desastre devem ser criados e executados se necessário. A fase de aposentadoria consiste na retirada de um sistema de operação onde sistemas antigos são substituídos por sistemas novos ou retirados de operação. 2.2.6 RUP-SE – Rational Unified Process – Systems Engineering O RUP-SE é uma extensão do modelo RUP, especialmente adequada para o desenvolvimento de sistemas de grande porte, envolvendo software, hardware, pessoas e componentes de informação. TÓPICO 2 | PROCESSO UNIFICADO (UP) 37 FIGURA 27 – CICLO DE VIDA RUP-SE FONTE: Disponível em: <http://www.devarticles.com/c/a/Development-Cycles/Organizing-RUP- SE-Projects/1/>. Acesso em: 26 dez. 2014. O Framework permite, neste caso, considerar o sistema a partir de diferentes perspectivas (lógica, física ou informacional). Isto pode ser bastante útil quando se deseja demonstrar ou discutir aspectos de um sistema com diferentes interessados. Maiores informações acerca do processo unificado, bem como selecionar versões do processo unificado é possível por meio dos seguintes sites: <www.rational.com/rup>. <http://.flylib.com/books>. <http://savannah.nongnu.org/>. <http://www.git-scm.com/>. <http://mercurial.selenic.com/>. IMPORTANT E 38 RESUMO DO TÓPICO 2 Neste tópico, vimos: • O Processo Unificado (UP), bem como conhecer suas principais definições, sua caracterização, suas fases, bem como suas derivações (RUP – Rational Unified Process; AUP – Agile Unified Process; OpenUp – Open Unifies Process; EUP – Enterprise Unified Process; RUP-SE – Rational Unified Process – Systems Engineering). • A importância de cada uma das derivações apresentadas, e como podemos utilizá-las nos diferentes tipos de projetos. Afinal cada uma possui suas especificidades e suas características próprias. Neste sentido, para auxiliar na compreensão, foram apresentadas por meio das figuras as fases de cada processo. Neste Momento, você está apto a realizar as autoatividades deste tópico, e, na sequência, iniciar o estudo do Tópico 3 desta unidade. Bom estudo! 39 AUTOATIVIDADE 1 Descreva como se caracteriza processo unificado. 2 Explique as fases do processo unificado. 3 Entre os diversos papéis assumidos no RUP, quais são os que definem um conjunto de comportamentos e responsabilidades para determinada pessoa? Com base nesta afirmação, analise a figura a seguir: Agora, assinale a alternativa CORRETA: a) ( ) Outros papéis. b) ( ) Papel do testador. c) ( ) Papel do gerente. d) ( ) Papel do desenvolvedor. 4 A figura a seguir se refere a qual das derivações apresentadas no Processo Unificado? 40 a) Open-Up – Open Unified Process. b) AUP – Agile Unified Process. c) RUP – Rational Unifies Process. d) EUP – Enterprise Unified Process. 5 As interações que ocorrem nesta fase têm como objetivo detalhar a análise e expandir os casos de uso, para obter assim sua descrição detalhada e verificar as situações excepcionais, ou seja, são voltadas para a produção da arquitetura básica, e vários casos de uso são demonstrados com detalhes, possuindo uma arquitetura projetada que se utiliza de artefatos, que podem ser estáticos ou dinâmicos. A qual das fases esta afirmação se refere? a) Construção. b) Concepção. c) Transição. d) Elaboração. Test Project Management Configuration Management Implementation Deployment Environment Model Inception I1 E1 C1 T1 T2C2 Cn Elaboration TransitionConstruction Phases Iterations 41 TÓPICO 3 ESTRUTURAS E RELACIONAMENTOS UNIDADE 1 1 INTRODUÇÃO Conforme foi abordado nos tópicos anteriores, você entrou em contato com as definições acerca dos objetos, seus diferentes tipos e uma prévia sobre a Análise e Programação Orientada a Objetos. Teve contato também com os princípios básicos da Orientação a Objetos, bem como seus principais conceitos. Agora, neste tópico, iremos abordar sobre as estruturas de relacionamento dos objetos, ou seja, de que forma estas estruturas auxiliam os analistas e desenvolvedoresna composição e apresentação dos objetos dentro do contexto de software, possibilitando assim uma melhor visualização do problema a ser estudado. Ainda neste contexto, vale frisar que o relacionamento entre os objetos ocorre quando um objeto se referencia ao outro, ou quando um método de um objeto é ativado por outro objeto. 2 TIPOS DE ESTRUTURAS E RELACIONAMENTOS Segundo Correia e Tafner (2001, p. 39), “Na Programação Orientada a Objetos, as estruturas possibilitam os analistas ou programadores arranjar os objetos de forma que possa visualizar melhor o domínio e a complexidade do problema em estudo”. Existem dois tipos básicos de estrutura: Generalização- Especialização e Todo-Parte, que serão estudadas na sequência. E com relação aos relacionamentos, os autores descrevem que os relacionamentos ocorrem quando os objetos se referenciam uns aos outros (conexão de ocorrência), ou quando um objeto ativa um método de outro objeto (conexão de mensagem). 42 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 42 2.1 ESTRUTURA GENERALIZAÇÃO – ESPECIALIZAÇÃO (GE) A Generalização é conhecida pelo conceito de associar indivíduos com atributos em comum, e ao mesmo tempo despreza as diferenças. Quando adaptamos pela generalização, não estamos distorcendo seu conceito, estamos ampliando-o não apenas para o grupo de indivíduos, mas também vamos generalizar alguns atributos para que a aderência do conceito seja maior (ANGELANTONIO, 2014). FIGURA 28 – EXEMPLO DE GENERALIZAÇÃO – ESPECIALIZAÇÃO FONTE: Disponível em: <https://alexevalerio.wordpress.com/2014/04/07/modelagem-de- banco-de-dados-generalizacaoespecializacao/>. Acesso em: 26 dez. 2014. A Especialização é muito semelhante à herança, a qual já estudamos anteriormente. Assim, caso tenha interesse em realizar uma herança, deve utilizar a estrutura Generalização-Especialização. TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 43 2.2 ESTRUTURA TODO – PARTE (TP) Este tipo de estrutura é bastante característico, uma vez que trata de agregação ou decomposição de objetos. “Essa estratégia é muito útil na identificação dos objetos e dos seus componentes diante de um determinado problema em estudo”. (CORREIA E TAFNER, 2001, p. 41). FIGURA 29 – ESTRUTURA TODO-PARTE FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014. Além desta definição, é importante destacar que a estrutura Todo-Parte é composta por uma característica conhecida por cardinalidade, que é importante para determinar o número de ocorrências em um relacionamento. FIGURA 30 – CARDINALIDADE NA PRÁTICA FONTE: Disponível em: <http://slideplayer.com.br/slide/298878/>. Acesso em: 26 dez. 2014. Todo Parte 1 Parte 2 Automóvel Automóvel 0..1 4..5 Roda Roda Roda Roda Roda 44 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 44 No exemplo apresentado na figura 30, um carro, como todos sabem, é composto por quatro rodas (cinco, considerando o estepe), sendo todas iguais. Desta forma denominamos roda um objeto e se repete quatro vezes dentro do objeto carro. Em outras palavras, conforme a definição, roda ocorre quatro vezes neste relacionamento entre carro e roda. 2.3 CONEXÕES Na Programação Orientada a Objetos, existem dois tipos de conexão entre os objetos, que são conhecidas por Conexões de Ocorrência e Conexões de Mensagens (serão estudadas posteriormente), porém é importante destacar que ambas não possuem nenhum tipo de hierarquia ou estrutura. 2.3.1 Conexões de ocorrência Uma Conexão de Ocorrência existe quando um atributo de um objeto contém uma referência a outro objeto. Sendo assim, “a necessidade de criar uma conexão de ocorrência com frequência surge da identificação de atributos em um objeto que é redundante e que sob uma análise mais atenta, percebe-se fazerem parte de outro objeto”. (CORREIA e TAFNER, 2001, p. 43). FIGURA 31 – CONEXÃO DE OCORRÊNCIA FONTE: Correia e Tafner (2001, p. 44) No diagrama representado pela Figura 31 existe uma conexão de ocorrência entre carro e pessoa, neste objeto carro contém um atributo chamado proprietário, que contém uma ocorrência para um objeto da classe pessoa. TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 45 2.3.2 Cardialidade Conforme já foi visto anteriormente, Cardinalidade determina o número de vezes que um objeto é referenciado ou se referencia ao outro. Quando se refere à estrutura todo-parte, a cardinalidade é demonstrada por meio de pares de números adjacentes à linha que representa a relação entre os objetos. FIGURA 32 – CARDINALIDADE ENTRE ALUNO, MATRÍCULA E MATÉRIA FONTE: Disponível em: <http://e-reality-database.blogspot.com.br/2007/09/cardinalidade.html>. Acesso em: 26 dez. 2014. Observando a Figura 32, contata-se que na cardinalidade existe o aluno que pode se matricular em no mínimo uma disciplina e no máximo três disciplinas, e neste contexto, cada matéria relaciona-se com as matrículas, e que podem ser de no mínimo 0 e no máximo n alunos matriculados. 2.3.3 Conexão de mensagem Com relação à conexão de mensagem, pode-se dizer que uma mensagem é uma ação que envia um método específico no objeto receptor, fazendo com que este efetue um comportamento determinado. Este método, por sua vez, retorna ou não uma resposta para o objeto transmissor. Para simplificar, a conexão de mensagem ocorre sempre que um objeto envia uma mensagem a outro objeto, neste contexto apresenta-se o método transmissor e o receptor. 46 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 46 FIGURA 33 – CONEXÃO DE MENSAGEM FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 26 dez. 2014. Para ajudar em sua compreensão, segue mais um exemplo de conexão de mensagem. FIGURA 34 – OUTRO EXEMPLO DE CONEXÃO DE MENSAGEM FONTE: Disponível em: <http://slideplayer.com.br/slide/365068/>. Acesso em: 26 dez. 2014. Analisando as figuras que se referem à conexão de mensagem, pode-se perceber que na Figura 33 ocorre a transmissão de uma mensagem entre duas pessoas, ou seja, uma realiza uma pergunta e a outra consequentemente a responde. Já na figura 34, estamos falando de um sistema que se refere à locação de filmes, neste a locação envia uma mensagem para verificar se o cliente está cadastrado para realizar a locação do filme, caso não esteja cadastrado retorna a mensagem solicitando o cadastro do cliente. Cadastro_Cliente Criar_Cliente Consultar_Cliente Criar_C liente Cliente Locação A_Fita A _Cliente Locar_Fita_Cliente Cliente Locar_Fita Liberar_Fita Consultar_Disp Cadastro_Fita Consultar_Fita 1,1 1,1 1,1 1,1 0,n 0,n 0,n 0,n C onsultar_C liente TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 47 2.3.4 Polimorfismo Segundo a definição de Lima (2005), polimorfismo é o princípio em que classes derivadas de uma mesma superclasse podem invocar operações que têm a mesma assinatura, mas comportamentos diferentes em cada subclasse, produzindo resultados diferentes, dependendo de como cada objeto implementa a operação. Continuando, o autor destaca que é a capacidade de objetos diferentes possuírem operações com o mesmo nome e a mesma lista de argumentos, mas que executam tarefas de formas diferentes. FIGURA 35 – POLIMORFISMO FONTE: Disponível em: <http://www.tomasvasquez.com.br/cursocsharp/programacao_orientada_ objetos/polimorfismo>. Acesso em: 26 dez. 2014. Por meio da figura apresentada sobre polimorfismo, foi possível perceber certa semelhança com a Herança que já foi estudada anteriormente, ou seja, a subclasse bicicleta e a subclasse carro, ambos herdaram da superclasse veículo os métodos movimentar e parar, assim cada objeto responde à mesma mensagem, porém cada um a sua maneira. Ou seja, a bicicleta movimenta-se em duas rodas, enquanto o carro necessita de quatro rodas para se movimentar, mas ambos pertencem à mesma superclasse veículo. Processos de Herança Membros de Herdados Classe Veículo • ... • Movimentar • Parar • ... Classe Bicicleta • ... • Movimentar • Parar • ... Classe Carro • ... • Movimentar • Parar• ... 48 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS Herança A herança é um mecanismo que permite a uma dada classe (classe derivada-subclasse) aceder a dados e métodos de uma outra classe (classe base- superclasse). A utilização de herança aplica-se de uma forma natural a todos os procedimentos definidos de uma forma hierárquica, onde as classes derivadas herdam as propriedades da(s) classe(s) base(s). O processo da criação de uma classe derivada, permite: • Especialização: criação de uma classe específica de uma dada classe, como por exemplo a definição de uma classe para vectores de números inteiros com base na classe genérica vector. • Generalização: criação de uma classe que prolonga o comportamento da classe base (oposto a especialização). • Extensão: a classe derivada introduz novas funcionalidades à classe base, mas não altera as existentes. • Limitação: a classe derivada restringe as funcionalidades de uma classe base, como, por exemplo, restringir as funcionalidades da classe vector por forma a implementar só as funcionalidades pretendidas. • Combinação: utilização de herança múltipla por forma a criar novas classes de alto nível. Visibilidade externa de uma classe: class TESTE {public: // Pode ser acedido por qualquer função int f(); int x; protected: // Pode ser acedido por qualquer função membro, // função amiga ou classes derivadas; int g(); int y; private: // Só pode ser acedido pelas funções membro da // própria classe ou por funções membro amigas int h(); int z; }; LEITURA COMPLEMENTAR TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 49 A parte protected: da classe permite: • Definição de variáveis e métodos por forma a melhorar o acesso à classe base, por parte da classe derivada. • Obter uma maior eficiência no acesso à classe base. 1.1. Herança Simples class BASE {public: int x; protected: int y; int h(int a); private: int z; }; class NATO: public BASE {public: int f() { return(x + BASE::x + y); int g() { return( h() ); } private: int x; }; ou class NATO: private BASE {public: int f() { return(x + BASE::x + y); int g() { return( h() ); } private: int x; }; class NATO: public BASE Todos os membros public e protected da classe BASE são membros public e protected da classe NATO Todos os membros private da classe BASE não podem ser acedidos pela classe NATO. class NATO: private BASE Todos os membros public e protected da classe BASE são membros private da classe NATO Todos os membros private da classe BASE não podem ser acedidos pela classe NATO. 50 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS 1.2. Herança Múltipla class BASE1 { public: int x; }; class BASE2 { public: int y; }; class BASE3 { public: int z; }; class NATO: public BASE1, public BASE2, public BASE3 { public: void f() { return(BASE1::x+BASE2::y+BASE3::z); }; A Ordem de Derivação é Importante? É importante para a inicialização (por omissão) das variáveis das classes bases e derivadas (ver inicialização de construtores). Pode-se especificar várias vezes uma classe base numa classe derivada? Não. Não se pode especificar mais de uma vez como classe básica de uma classe derivada, uma vez que uma referência à classe base seria ambígua. class NATO: public BASE1, public BASE1 // erro { public: void f() { return(BASE1::x+BASE2::y+BASE3::z); }; Considere o seguinte conjunto de classes bases e derivadas, utilizando herança simples e múltipla. class L { TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 51 public: int x; }; class A: public L { public: int y; }; class B: public L { public: int z; }; class C: public A, public B { public: int f() { return(A::y + A::L::x + B::z + B::L::x + y + z); } }; Em problemas onde existam diversas herança, por vezes torna-se mais fácil visualizar a interligação destas classes, através da utilização de um esquema representativo da interligação (herança) entre as classes. Visualização da herança para melhor compreender heranças complicadas Como aceder à variável “x“ da classe “L“ pertencente à classe “A“? int main() { C derivada; derivada::A::x = 1; // aceder à variável “x“ da classe “L“ da classe “A“ derivada::B::x = 2; // aceder à variável “x“ da classe “L“ da classe “B“ } FONTE: Disponível em: <http://www.estig.ipbeja.pt/~rmcp/estig/20062007/1s/lp/cplusplus/ heranca.pdf>. Acesso em: 26 dez. 2014. 52 UNIDADE 1 | O PARADIGMA DA ORIENTAÇÃO A OBJETOS Cardinalidade Entenda quais são os tipos de relacionamentos e cardinalidade que usamos na análise de relacionamento no processo de modelagem de dados, o Modelo de Entidade e Relacionamento. Relacionamento entre entidades é o tipo de ocorrência existente entre entidades e aplicáveis no processo de modelar dados. Entender isso é importante pois um modelo consistente é a base para um banco de dados de sucesso. O símbolo que representa o relacionamento no Modelo de Entidade e Relacionamento (MER) é um losango com o nome do relacionamento escrito no seu interior, como no exemplo a seguir. Em um modelo de entidade e relacionamento, nem todas as entidades serão relacionadas, há casos em que não há ligação entre elas, nestes casos consideramos como entidades isoladas. Embora não seja tão comum, é importante levar em conta esta possibilidade. Mas quando as ligações existirem, elas serão classificadas de acordo com os tipos a seguir. Tipos de relacionamento Existem três tipos de relacionamento entre entidades: • um-para-um • um-para-muitos • muitos-para-muitos Relacionamento um-para-um O relacionamento um-para-um é usado quando uma entidade A se relaciona com uma entidade B e vice-versa. Este relacionamento é representado pelo sinal: 1:1 Veja o exemplo: Pertence Chefia1 1Gerente Seleção TÓPICO 3 | ESTRUTURAS E RELACIONAMENTOS 53 Relacionamento um-para-muitos O relacionamento um-para-muitos é usado quando uma entidade A pode se relacionar com uma ou mais entidades B. Este relacionamento é representado pelo sinal: 1:N Veja o exemplo: Relacionamento muitos-para-muitos O relacionamento muitos-para-muitos é usado quando várias entidades A se relacionam com várias entidades B. Este relacionamento é representado pelo sinal: N:N ou N:M Veja o exemplo: Cardinalidade A cardinalidade é um conceito importante para ajudar a definir o relacionamento, ela define o número de ocorrências em um relacionamento. Para determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento em ambas as direções. Um departamento possui quantos empregados? - no mínimo 1 e no máximo N. Um empregado está alocado em quantos departamentos? - no mínimo em 1 e no máximo em 1 Somando-se as cardinalidades, definimos o resultado final do relacionamento, ou seja, 1:N FONTE: Disponível em: <http://www.luis.blog.br/relacionamento-entre-entidades-tipos-e- cardinalidade.aspx> Acesso em: 26 dez. 2014. ForneceN NFornecedor Produto Trabalha1 NSeção Funcionário 54 RESUMO DO TÓPICO 3 Neste tópico, vimos: • As estruturas de relacionamento dos objetos, e como estas estruturas auxiliam os analistas e desenvolvedores na composição e apresentação dos objetos dentro do contexto de software, possibilitando, assim, uma melhor visualização do problema a ser estudado, facilitando a compreensão deste por parte de usuários de negócio e desenvolvedores. • O relacionamento entre os objetos ocorre quando um objeto se referencia ao outro, ou quando um método de um objeto é ativado por outro objeto. Assim, ao término deste tópico concluímos a Unidade 1. Com isso, você, acadêmico(a), está apto(a) a aplicar os conhecimentos de Orientação a Objetos em suas atividades diárias. Bom estudo! 55 AUTOATIVIDADE 1 Descreva os dois tipos básicos de estruturas que auxiliam os analistas na Análise e Orientação a Objetos: 2 É conhecida pelo conceito de associar indivíduos com atributos em comum, e ao mesmo tempo despreza as diferenças. Assinale a alternativa CORRETA para esta definição: a) ( ) Encapsulamento. b) ( ) Generalização-Especialização. c) ( ) Classe Abstrata. d) ( ) Todo-Parte.
Compartilhar