Foo

Escola Estadual de Educao Profissional - EEEP
Ensino Mdio Integrado Educao Profissional
Curso Tcnico em Informtica
Fundamentos de Orientao a Objeto
Governador Cid Ferreira Gomes Vice Governador Francisco Jos Pinheiro
Secretria da Educao Maria Izolda Cela de Arruda Coelho Secretrio Adjunto Maurcio Holanda Maia
Secretrio Executivo Antnio Idilvan de Lima Alencar
Assessora Institucional do Gabinete da Seduc Cristiane Carvalho Holanda Coordenadora de Desenvolvimento da Escola Maria da Conceio vila de Misquita Vins Coordenadora da Educao Profissional SEDUC Thereza Maria de Castro Paes Barreto
Escola Estadual de Educao Profissional [EEEP]
Fundamentos de Orientao a Objeto

Carga Horria: 40 H EMENTA
Paradigma de orientao a objetos. Linguagens orientadas a objetos. Abstrao e tipos abstratos. Classes, mtodos, encapsulamento, interface. Mensagens, instncias e inicializao. Herana e composio. A combinao de herana e composio. Polimorfismo: variveis polimrficas, sobrecarga, construtores. Linguagem de Modelagem Unificada UML.
OBJETIVOS
Detalhar o conhecimento a cerca dos conceitos e paradigmas da orientao a objetos; Apresentar a linguagem de modelagem unificada para desenvolvimento orientado a objetos.
HABILIDADES E COMPETNCIAS
O aluno dever compreender os paradigmas da programao orientada a objetos, alm de conhecer os diagramas para modelagem de sistemas orientados a objetos.
CONTEDO PROGRAMTICO
1. Orientao a Objetos 1.1. Abstrao e tipos abstratos 1.2. Paradigmas da orientao a objetos 1.3. Histrico da orientao a objetos 1.4. Linguagens orientadas a objetos 1.5. Vantagens 2. Paradigmas da orientao a objetos 2.1. Objetos e classes 2.2. Atributos e mtodos 2.3. Mensagens 2.4. Encapsulamento 2.5. Interface e Classe Abstrata 3. Herana 3.1. Definio 3.2. Especializao e Generalizao 3.3. Composio e Agregao 3.4. Herana mltipla 4. Polimorfismo 4.1. Definio 4.2. Variveis polimrficas 4.3. Mtodos construtores 4.4. Sobrecarga de mtodo 5. Linguagem de Modelagem Unificada - UML 5.1. Conceitos 5.2. Histrico 5.3. Diagramas da UML 5.3.1. Diagrama de Classe 5.3.2. Diagrama de Caso de Uso 5.3.3. Diagrama de Implantao 5.3.4. Diagrama de Estado 5.3.5. Diagrama de Seqncia 5.4. Ferramentas CASE
BIBLIOGRAFIA BSICA PINHEIRO, Francisco. Fundamentos de Computao e Orientao a Objetos CORNELL, Gary. Core JAVA
2: Fundamentos. Editora Alta Books. usando JAVA. Editora LTC;
WAZLAWICK, Raul Sidnei. Anlise e projeto de sistemas de informao orientados a objetos. Editora Elsevier; GUEDES, Gilleanes. UML: uma abordagem prtica. Novatec
Editora.
BORATTI, Isaias. Programao Orientada a Objetos em JAVA. Editora Visual Books.
Informtica Fundamentos de Orientao a Objetos
1. Orientao a Objetos A orientao a objetos um paradigma de anlise, projeto e programao de sistemas de software baseado na composio e interao entre diversas unidades de software chamadas de objetos. Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programao. De fato, o paradigma "orientao a objeto", tem bases conceituais e origem no campo de estudo da cognio, que influenciou a rea de inteligncia artificial e da lingustica, no campo da abstrao de conceitos do mundo real. Na qualidade de mtodo de modelagem, tida como a melhor estratgia para se eliminar o "gap semntico", dificuldade recorrente no processo de modelar o mundo real do domnio do problema em um conjunto de componentes de software que seja o mais fiel na sua representao deste domnio. Facilitaria a comunicao do profissional modelador e do usurio da rea alvo, na medida em que a correlao da simbologia e conceitos abstratos do mundo real e da ferramenta de modelagem (conceitos, terminologia, smbolos, grafismo e estratgias) fosse a mais bvia, natural e exata possvel. A anlise e projeto orientados a objetos tm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se d atravs do relacionamento e troca de mensagens entre estes objetos. Na programao orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definido nos mtodos) e estados possveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. C++, C#, Java, Object Pascal, Objective-C, Python, SuperCollider, Ruby e Smalltalk so exemplos de linguagens de programao orientadas a objetos. ActionScript, ColdFusion, Javascript, PHP (a partir da verso 4.0), Perl (a partir da verso 5) e VB.NET so exemplos de linguagens de programao com suporte a orientao a objetos. 1.1. Abstrao e tipos abstratos Abstrao consiste de focalizar nos aspectos essenciais inerentes a uma entidade e ignorar propriedades acidentais. Em termos de desenvolvimento de sistemas, isto significa concentrar-se no que um objeto e faz antes de se decidir como ele ser implementado. O uso de abstrao preserva a liberdade para tomar decises de desenvolvimento ou de implementao apenas quando h um melhor entendimento do problema a ser resolvido. Muitas linguagens de programao modernas suportam o conceito de abstrao de dados; porm, o uso de abstrao juntamente com polimorfismo e herana, como suportado em orientao a objetos, um mecanismo muito mais poderoso. O uso apropriado de abstrao permite que um mesmo modelo conceitual (orientao a objetos) seja utilizado para todas as fases de desenvolvimento de um sistema, desde sua anlise at sua documentao. Em computao, o TAD (Tipo Abstrato de Dado) uma especificao de um conjunto de dados e operaes que podem ser executadas sobre esses dados. Alm disso, uma metodologia de programao que tem como proposta reduzir a informao necessria para a criao/programao de um algoritmo atravs da abstrao das variveis envolvidas em uma nica entidade fechada. Com operaes prprias sua natureza.
2
Um exemplo prtico disto o de um estudante. Em um projeto anterior teoria de TAD, um estudante seria representado por variveis soltas, como seu nome, sua idade e sua matrcula. Que sero operadas em separado, sem que haja uma ligao lgica entre elas, alm do conhecimento do programador de que a varivel trata-se do nome da "entidade" estudante. Conceitualmente passou a se projetar um programa ento pensando que no h o nome, idade e matrcula do estudante. Mas simplesmente o tipo estudante. Este tipo, como um tipo simples (como um inteiro ou uma string) deve ter operadores prprios. Assim o estudante deve possuir operaes desejveis ao programador, como de duplicar sua informao, validar a matrcula, verificar a idade, etc. Na prtica, o TAD implementado usando-se um tipo composto (struct/record estrutura/registro) com os valores pertencentes ao TAD (nome, idade, matrcula). E por funes que operam esta estrutura.
Exemplo: estrutura Estudante{ Nome Idade Matricula } funcao Estudante_MaiorDeIdade(Estudante estudante) retorna booleano; funcao Estudante_ValidaMatricula(Estudante estudante);
A abstrao de informaes atravs do TAD permitiu a melhor compreenso dos algoritmos, maior facilidade de programao, e por consequncia, aumentou a complexidade dos programas. Tornando-se fundamental em qualquer projeto de software a modelagem de seus dados previamente. Um dos problemas que so enfrentados no TAD que ele uma estrutura metafrica gerada pela modelagem. Porm, a nvel de implementao, no h nenhuma segurana que as operaes e regras de operao desejadas para este tipo sejam respeitadas. Posteriormente, essa metodologia foi incorporada prpria linguagem de programao, para um prottipo do que hoje a orientao a objetos (OOP - Object Oriented Programming). Permitindo o controle do acesso s informaes de um tipo, a herana e o polimorfismo. 1.2. Paradigmas da orientao a objetos Linguagens orientadas a procedimentos, que foi o paradigma de programao que mais se desenvolveu em 1970, possuem como foco principal os subprogramas e bibliotecas de subprogramas. Neste caso, dados so enviados para serem processados nos subprogramas. Por exemplo, um vetor de valores inteiros que precisam ser ordenados enviado como parmetro para um subprograma que o ordena. Programao "baseada em dados" tem como foco os tipos abstratos de dados. Neste paradigma, o processamento de um objeto de dado especificado atravs da chamada de subprogramas associados com o objeto. Se um objeto vetor necessita ser ordenado, a operao de ordenao definida no tipo abstrato de dado para o vetor. O processo de ordenao realizado atravs da chamada desta operao no objeto vetor especfico.
3
O paradigma de programao OO tornou-se popular apenas na dcada de 80. Uma linguagem OO deve fornecer suporte para trs caractersticas chave: tipos abstratos de dados, herana e um tipo particular de amarrao dinmica. Um modelo OO tem como entidade fundamental o objeto, que recebe e envia mensagens, executa processamentos e possui um estado local que ele pode modificar. Problemas so resolvidos atravs de objetos que enviam mensagens uns para os outros. Assim, pode-se dizer que um modelo OO formado por quatro componentes bsicos: objetos, mensagens, mtodos e classes, descritos a seguir. Objeto: Um objeto consiste em um conjunto de operaes encapsuladas (mtodos) e um estado (determinado pelo valor dos atributos) que grava e recupera os efeitos destas operaes. Em outras palavras um objeto possui tudo o que necessrio para conhecer a si prprio. Um objeto executa uma operao em resposta a uma mensagem recebida que associada com aquela operao. O resultado da operao depende tanto do contedo da mensagem recebida como do estado do objeto quando ele recebe a mensagem. Um objeto tambm pode, como parte da sua operao, enviar mensagens para outros objetos e para si mesmo. Para ilustrar, pode-se dizer que objetos representam uma coleo de dados relacionados com um tema em comum.
Mensagem: Mensagens so requisies enviadas de um objeto para outro, para que o objeto receptor fornea algum resultado desejado atravs da execuo de uma operao. A natureza das operaes realizadas para alcanar o resultado requerido determinada pelo objeto receptor. Mensagens tambm podem ser acompanhadas por parmetros que so aceitos pelo objeto receptor e podem ter algum efeito nas operaes realizadas. Estes parmetros so os prprios objetos. Resumindo, trata-se de um ciclo completo onde uma mensagem enviada a um objeto, operaes so executadas dentro desse e uma mensagem contendo o resultado da operao enviada ao objeto solicitante. Funciona como uma fbrica ilustrada na figura abaixo, que recebe uma ordem de produo (mensagem de solicitao), processa essa ordem (operaes) utilizando matria-prima (atributos) e gera um produto final (mensagem de resposta).
Mtodos: Mtodos so similares a procedimentos e funes e consistem nas descries das operaes que um objeto executa quando recebe uma mensagem. H, portanto, uma correspondncia um para um entre mensagens e mtodos que so executados quando a mensagem recebida atravs de um dado objeto. A mesma mensagem pode resultar em mtodos diferentes quando for enviada para objetos diferentes. O mtodo associado com a mensagem pr-definido. Atributos: Um atributo consiste em um dado ou informao de estado, para o qual cada objeto de uma classe tem seu prprio valor. Existem dois tipos de atributos em um sistema orientado a objetos: os atributos de objetos e os atributos de classes. O primeiro trata-se dos atributos que descrevem valores (estados) mantidos em um objeto. Diferentes objetos de uma mesma classe no compartilham os atributos de objetos, ou seja, cada um possui sua prpria cpia do atributo. Os atributos de classe so aqueles cujo valor todos os seus objetos devem compartilhar. Classes: Uma classe define as caractersticas de uma coleo de objetos. Classes consistem em descries de mtodos e atributos que objetos que pertencem classe iro possuir. Uma classe similar a um tipo abstrato de dado no sentido que ela define uma estrutura interna e um conjunto de operaes que todos os objetos que so instncias daquela classe iro possuir. Desta forma desnecessrio redefinir cada objeto que possui as mesmas propriedades. Uma classe tambm um prprio objeto e por isso pode aceitar mensagens e ter mtodos e um estado interno. Em outras palavras uma classe representa uma idia ou um conceito simples e categoriza objetos que possuem propriedades similares.
Encapsulamento: Cada objeto visto como o encapsulamento do seu estado interno, suas mensagens e seus mtodos. A estrutura do estado e dos pares "mensagem mtodo" so todas definidas atravs da classe qual o objeto pertence. O valor atual do estado interno determinado atravs dos mtodos que o objeto executa em resposta s mensagens recebidas. Encapsulamento constitui-se no "corao" da programao orientada a objetos, a unio da ao e da informao em novos tipos de dados que "sabem" o que supostamente devem fazer, separando, assim, um servio da sua implementao. Polimorfismo: a propriedade que permite que a mesma mensagem seja enviada a diferentes objetos e que cada objeto execute a operao que apropriada sua classe. Mais importante, o objeto emissor no precisa conhecer a classe do objeto receptor e como este objeto ir responder mensagem. Isto significa que, por exemplo, a mensagem print pode ser enviada para um objeto sem a necessidade de saber se o objeto um caracter, um inteiro ou um string. O objeto receptor responde com o mtodo que apropriado classe a qual ele pertence. Herana: uma das propriedades mais importantes do modelo de orientao a objetos. A herana permitida atravs da definio de uma hierarquia de classes, isto , uma rvore de classes onde cada uma possui zero ou mais subclasses. Herana refere-se ao fato de que uma subclasse herda todos os componentes da classe pai, incluindo uma estrutura de estado interna e pares "mensagem - mtodo". Qualquer propriedade herdada pode ser redefinida na definio da subclasse, substituindo a definio herdada. Mas, componentes que permanecem iguais no requerem redefinio. Esta propriedade encoraja a definio de novas classes sem uma grande duplicao do cdigo. 1.3. Histrico da orientao a objetos Os caminhos da programao tm mudado dramaticamente desde a inveno do computador. A primeira razo para as mudanas acomodar o aumento da complexidade dos programas. Por exemplo, quando os computadores foram inventados, a programao era feita por chaveamentos em instrues binrias de mquina, usando-se o painel frontal. Enquanto os programas continham somente algumas centenas de instrues, esse mtodo funcionava. Quando cresceram, a linguagem assembly foi inventada para permitir a um programador manipular complexidades. A primeira linguagem de alto nvel difundida foi, obviamente, FORTRAN. Ainda que o FORTRAN tenha dado um primeiro passo bastante considervel, uma linguagem que somente torna os programas mais claros e fceis de entender do que o assembly, sem introduzir mudanas considerveis no estilo de programao. Nos anos 60 nasceu a programao estruturada. Esse o mtodo estimulado por linguagens como C e Pascal. Usando-se linguagens estruturadas, foi possvel, pela primeira vez, escrever programas moderadamente complexos de maneira razoavelmente fcil. Entretanto, com programao estruturada, quando um projeto atinge um certo tamanho, torna-se extremamente difcil e muito custoso efetuar sua manuteno e fazer qualquer modificao. A cada marco no desenvolvimento da programao, mtodos foram criados para permitir ao programador tratar com complexidades incrivelmente grandes. Cada passo combinava os melhores elementos dos mtodos anteriores com elementos mais avanados. Atualmente, muitos projetos esto prximos ou no ponto em que o tratamento estruturado
6
no mais funciona. Para resolver esse problema, a programao orientada a objetos foi criada. A programao orientada a objetos aproveitou as melhores idias da programao estruturada e combinou-as com novos conceitos poderosos que levam a ver na tarefa de programao uma nova luz, permitindo que um problema seja mais facilmente decomposto em subgrupos relacionados. Ento, usando-se a linguagem, pode-se traduzir esses subgrupos em objetos. A primeira linguagem a incorporar facilidades para definir classes de objetos genricos na forma de uma hierarquia de classes e subclasses foi a linguagem Simula, que foi idealizada em 1966, na Noruega, como uma extenso da linguagem ALGOL 60. Uma classe em Simula, um mdulo englobando a definio da estrutura e do comportamento comuns a todas as suas instncias (objetos). Como o nome indica, uma linguagem adequada programao de simulaes de sistemas que podem ser modelados pela interao de um grande nmero de objetos distintos. As idias de Simula serviram de base para as propostas de utilizao de Tipos Abstratos de Dados, e tambm para Smalltalk. Smalltalk foi desenvolvida no Centro de Pesquisas da Xerox durante a dcada de 70, e incorporou, alm das idias de Simula, um outro conceito importante, devido a Alan Kay, um de seus idealizadores: o princpio de objetos ativos, prontos a reagir a mensagens que ativam comportamentos especficos do objeto. Ou seja, os objetos em Smalltalk deixam de ser meros dados manipulados por programas, e passam a ser encarados como processadores idealizados individuais e independentes, aos quais podem ser transmitidos comandos em forma de mensagens. Outras linguagens orientadas para objetos tem sido desenvolvidas. Notadamente C++, uma extenso de C, Objetive-C, outra extenso de C, menos popular que a anterior, Pascal orientado a objetos, Eiffel e mais recentemente, no Brasil, TOOL. Alm da Xerox, que criou a ParcPlace Systems especialmente para comercializar Smalltalk-80 e seus sucedneos (objectWorks), a Digitalk lanou em 1986 uma verso de Smalltalk para ambiente DOS, e mais recentemente a verso para Windows, o que contribuiu para uma maior difuso da linguagem. Smalltalk, uma das mais populares linguagens orientadas a objetos, assim como outras linguagens orientadas para objetos, tem sido usada em aplicaes variadas onde a nfase est na simulao de modelos de sistemas, como automao de escritrios, animao grfica, informtica educativa, instrumentos virtuais, editores de texto e bancos de dados em geral, entre outras. Tais aplicaes diferem substancialmente daquelas em que a nfase est na resoluo de problemas atravs de algoritmos, tais como problemas de busca, otimizao e resoluo numrica de equaes. Para essas aplicaes, mais adequado o uso de linguagens algortmicas convencionais, como Pascal, Algol e Fortran. 1.4. Linguagens orientadas a objetos Simula A primeira linguagem a incorporar facilidades para definir classes de objetos genricos na forma de uma hierarquia de classes e subclasses. Foi idealizada em 1966, na Noruega, como uma extenso da linguagem ALGOL 60. Uma classe em Simula um mdulo englobando a definio da estrutura e do comportamento comuns a todas as suas instncias (objetos).
Smalltalk Smalltalk foi desenvolvida no Centro de Pesquisas da Xerox durante a dcada de 70. Em Smalltalk tudo objeto: os nmeros, as classes, os mtodos, blocos de cdigo, etc. No h tipos primitivos, ao contrrio de outras linguagens orientadas a objeto; strings, nmeros e caracteres so implementados como classes em Smalltalk, por isso esta linguagem considerada puramente orientada a objetos. Tecnicamente, todo elemento de Smalltalk um objeto de primeira ordem. Os programadores definem classes de objetos em suas aplicaes para imitar (ou simular) o mundo real. Estas classes de objeto so organizadas hierarquicamente, de modo que seja possvel fazer novos objetos com caractersticas de outros objetos, com poucas mudanas. Smalltalk relativamente fcil de aprender comparado a linguagens como C++ e ADA. O cdigo-fonte Smalltalk fcil de ler, o que o torna a linguagem de programao ideal para iniciantes. C++ O C++ (em portugus l-se "c mais mais") uma linguagem de programao multiparadigma e de uso geral. A linguagem considerada de mdio nvel, pois combina caractersticas de linguagens de alto e baixo nveis. Desde os anos 1990 uma das linguagens comerciais mais populares, sendo bastante usada tambm na academia por seu grande desempenho e base de utilizadores. Bjarne Stroustrup desenvolveu o C++ (originalmente com o nome C with Classes,[1] que significa C com classes em portugus) em 1983 no Bell Labs como um adicional linguagem C. Novas caractersticas foram adicionadas com o tempo, como funes virtuais, sobrecarga de operadores, herana mltipla, gabaritos e tratamento de excees. Aps a padronizao ISO realizada em 1998 e a posterior reviso realizada em 2003, uma nova verso do padro da linguagem est em desenvolvimento. Conhecida informalmente como C++0x,[2] seu lanamento est previsto para 2011. Ada Ada uma linguagem de programao criada atravs de um concurso realizado pelo U.S. Departament of Defense (DoD). O principal projetista da equipe foi o francs Jean Ichbiah. Esse concurso foi feito para por ordem na situao, o DoD em 1974 usava cerca de 450 linguagens ou dialetos de programao. A linguagem foi primeiramente padronizada em 1983 pelo ANSI e em 1985 a Organizao Internacional de Padronozao (ISO). Eiffel Eiffel uma Linguagem de Programao avanada, puramente orientada a objeto que enfatiza o projeto e construo de software reusvel e de alta qualidade. Eiffel foi criada por Bertrand Meyer que tinha uma extensa experincia com programao orientada a objeto, particularmente com SIMULA. Object Pascal O Object Pascal uma linguagem orientada a objetos, isto , todas as informaes so tratadas como objetos. Todos estes objetos pertencem a uma classe, que so categorias de objetos. Delphi / Kylix / Lazarus so exemplos de ferramentas que utilizam esta linguagem.
Java O Java ao mesmo tempo um ambiente e uma linguagem de programao desenvolvida pela Sun Microsystems, Inc.. Trata-se de mais um representante da nova gerao de linguagens orientadas a objetos e foi projetado para resolver os problemas da rea de programao cliente/servidor. Os aplicativos em Java so compilados em um cdigo de bytes independente de arquitetura. Esse cdigo de bytes pode ento ser executado em qualquer plataforma que suporte um interpretador Java. O Java requer somente uma fonte e um binrio e, mesmo assim, capaz de funcionar em diversas plataformas, o que faz dele um sonho de todos os que realizam manuteno em programas. Common Lisp Common Lisp uma implementao especfica da linguagem de programao Lisp multi-paradigma que suporta programao funcional e procedural. Foi criada por Guy L. Steele nos anos 1980 a partir da linguagem Lisp com o intuito de combinar aspectos de diversos dialetos Lisp anteriores, incluindo Scheme. Foi proposto inicialmente o nome de "Standard Lisp" para a linguagem, mas em virtude de de um dialeto Lisp j existir com este nome, se buscou um nome similar, resultando no nome "Common Lisp"[1]. Em 1994 foi publicada no padro ANSI Information Technology - Programming Language - Common Lisp, registro X3.226-1994 (R1999).[2]. bem maior e semnticamente mais complexa que Scheme uma vez que foi projetada para ser uma linguagem comercial e ser compatvel com os diversos dialetos Lisp dos quais derivou. C# C# (ou C Sharp) uma linguagem de programao orientada a objetos, fortemente tipada desenvolvida pela Microsoft como parte da plataforma .NET. A sua sintaxe orientada a objetos foi baseada no C++ mas inclui muitas influncias de outras linguagens de programao, como Object Pascal e Java. Durante o desenvolvimento da plataforma .NET, as bibliotecas foram escritas originalmente numa linguagem chamada Simple Managed C (SMC), que tinha um compilador prprio. Mas, em Janeiro de 1999, uma equipe de desenvolvimento foi formada por Anders Hejlsberg, que fora escolhido pela Microsoft para desenvolver a linguagem. D-se inicio criao da linguagem chamada Cool. Um pouco mais tarde, em 2000, o projeto .NET era apresentado ao pblico na Professional Developers Conference (PDC), e a linguagem Cool fora renomeada e apresentada como C#. Perl Perl uma linguagem de programao estvel e multiplataforma, usada em aplicaes de misso crtica em todos os setores, sendo destacado o seu uso no desenvolvimento web de todos os tipos. Permite a criao de programas em ambientes UNIX, MSDOS, Windows, Macintosh, OS/2 e outros sistemas operacionais. Alm de ser muito utilizada para programao de formulrios www e em tarefas administrativas de sistemas UNIX - onde a linguagem nasceu e se desenvolveu - possui funes muito eficientes para manipulao de textos. Perl uma das linguagens preferidas por administradores de sistema e especialmente verstil no processamento de cadeias (strings), manipulao de texto e no pattern matching implementado atravs de expresses regulares, alm de ser bastante adequada para o desenvolvimento de projetos utilizando uma metodologia gil.
9
Python Python uma linguagem de programao de alto nvel[3], interpretada, imperativa, orientada a objetos, de tipagem dinmica e forte. Foi lanada por Guido van Rossum em 1991.[1] Atualmente possui um modelo de desenvolvimento comunitrio, aberto e gerenciado pela organizao sem fins lucrativos Python Software Foundation. Apesar de vrias partes da linguagem possurem padres e especificaes formais, a linguagem como um todo no formalmente especificada. O padro de facto a implementao CPython. A linguagem foi projetada com a filosofia de enfatizar a importncia do esforo do programador sobre o esforo computacional. Prioriza a legibilidade do cdigo sobre a velocidade ou expressividade. Combina uma sintaxe concisa e clara com os recursos poderosos de sua biblioteca padro e por mdulos e frameworks desenvolvidos por terceiros. O nome Python teve a sua origem no grupo humorstico britnico Monty Python[4], criador do programa Monty Python's Flying Circus, embora muitas pessoas faam associao com o rptil do mesmo nome 1.5. Vantagens Abstrao de dados: os detalhes referentes s representaes das classes sero visveis apenas aos seus atributos; Compatibilidade: as heursticas para a construo das classes e suas interfaces levam a componentes de software que so fceis de combinar; Diminuio da complexidade: as classes delimitam-se em unidades naturais para a alocao de tarefas de desenvolvimento de software; Reutilizao: o encapsulamento dos mtodos e representao dos dados para a construo de classes facilitam o desenvolvimento de software reutilizvel, auxiliando na produtividade de sistemas; Extensibilidade: facilidade de estender o software devido a razes como, a herana; Manutenibilidade: a modularizao natural em classes facilita a realizao de alteraes no software; Maior dedicao fase de anlise, preocupando-se com a essncia do sistema; Mesma notao utilizada desde a fase de anlise at a implementao.
10
2. Paradigmas da orientao a objetos A orientao a objetos no uma coleo de bibliotecas ou simples adio de novas funcionalidades a uma linguagem de programao, um novo paradigma avanado. O conceito de paradigma tem como definio: conjunto de teorias, padres e mtodos que, juntos, representam um modo de organizar conhecimento. A programao orientada a objeto consiste em abordar a resoluo de um problema, atravs da anlise das entidades e seus relacionamentos, dentro do contexto onde se situa o problema. A partir dessa anlise construdo um Modelo de Resoluo que represente, da melhor maneira possvel, aquilo que acontece no mundo real. A anlise e projeto orientados a objetos tm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se d atravs do relacionamento e troca de mensagens entre estes objetos. uma forma mais adequada de pensar em como fazemos clculos, manipulamos dados dentro do computador e de que forma abstramos o mundo real para o virtual. 2.1. Objetos e classes Um modelo de objetos busca capturar a estrutura esttica de um sistema mostrando os objetos existentes, seus relacionamentos, e atributos e operaes que caracterizam cada classe de objetos. atravs do uso deste modelo que se enfatiza o desenvolvimento em termos de objetos ao invs de mecanismos tradicionais de desenvolvimento baseado em funcionalidades, permitindo uma representao mais prxima do mundo real. Uma vez que as principais definies e conceitos da abordagem de orientao a objetos esto definidos, possvel introduzir o modelo de objetos que ser adotado ao longo deste texto. O modelo apresentado um subconjunto do modelo OMT (Object Modeling Technique), proposto por Rumbaugh e outro. OMT tambm introduz uma representao diagramtica para este modelo, a qual ser tambm apresentada aqui. Objeto definido neste modelo como um conceito, abstrao ou coisa com limites e significados bem definidos para a aplicao em questo. Objetos tm dois propsitos: promover o entendimento do mundo real e suportar uma base prtica para uma implementao computacional. No existe uma maneira correta de decompor um problema em objetos; esta decomposio depende do julgamento do projetista e da natureza do problema. Todos objetos tm identidade prpria e so distinguveis. Uma classe de objetos descreve um grupo de objetos com propriedades (atributos) similares, comportamento (operaes) similares, relacionamentos comuns com outros objetos e uma semntica comum. Por exemplo, Pessoa e Companhia so classes de objetos. Cada pessoa tem um nome e uma idade; estes seriam os atributos comuns da classe. Companhias tambm podem ter os mesmos atributos nome e idade definidos. Entretanto, devido distino semntica elas provavelmente estariam agrupados em outra classe que no Pessoa. Como se pode observar, o agrupamento em classes no leva em conta apenas o compartilhamento de propriedades. Todo objeto sabe a que classe ele pertence, ou seja, a classe de um objeto um atributo implcito do objeto. Este conceito suportado na maior parte das linguagens de programao orientada a objetos, tais como C ++, Java, etc. OMT define dois tipos de diagramas de objetos, diagramas de classes e diagramas de instncias. Um diagrama de classe um esquema, ou seja, um padro ou gabarito que descreve as muitas possveis instncias de dados. Um diagrama de instncias descreve como
11
um conjunto particular de objetos est relacionado. Diagramas de instncias so teis para apresentar exemplos e documentar casos de testes; diagramas de classes tm uso mais amplo. A Figura abaixo apresenta a notao adotada para estes diagramas.
Objeto Um objeto pode ser real ou abstrato. Os objetos possuem informaes (contm dados) e desempenham aes (possuem funcionalidade). Qualquer coisa qual um conceito ou tipo de objeto se aplica uma instncia de um conceito ou tipo de objeto. Um objeto uma instncia de uma classe. Exemplo: Uma fatura; Uma organizao; Um vo de avio; Uma pessoa; Um lugar. Classe Uma classe uma implementao de um tipo de objeto. Uma classe especifica uma estrutura de dados e os mtodos operacionais permissveis que se aplicam a cada um de seus objetos. Uma classe pode ter sua prpria estrutura de dados e mtodos, bem como herda - l de sua superclasse. Exemplo:
12
2.2. Atributos e mtodos Um atributo um valor de dado assumido pelos objetos de uma classe. Nome, idade e peso so exemplos de atributos de objetos Pessoa. Cor, peso e modelo so possveis atributos de objetos Carro. Cada atributo tem um valor para cada instncia de objeto. Por exemplo, o atributo idade tem valor 29 no objeto Pedro Y. Em outras palavras, Pedro Y tem 29 anos de idade. Diferentes instncias de objetos podem ter o mesmo valor para um dado atributo. Cada nome de atributo nico para uma dada classe, mas no necessariamente nico entre todas as classes. Por exemplo, ambos Pessoa e Companhia podem ter um atributo chamado endereo. No diagrama de classes, atributos so listados no segundo segmento da caixa que representa a classe. O nome do atributo pode ser seguido por detalhes opcionais, tais como o tipo de dado assumido e valor default.
Uma operao uma funo ou transformao que pode ser aplicada a ou por objetos em uma classe. Por exemplo, abrir, salvar e imprimir so operaes que podem ser aplicadas a objetos da classe Arquivo. Todos os objetos em uma classe compartilham as mesmas operaes. Toda operao tem um objeto-alvo como um argumento implcito. O comportamento de uma operao depende da classe de seu alvo. Como um objeto sabe qual sua classe, possvel escolher a implementao correta da operao. Alm disto, outros argumentos (parmetros) podem ser necessrios para uma operao. Uma mesma operao pode se aplicar a diversas classes diferentes. Uma operao como esta dita ser polimrfica, ou seja, ela pode assumir distintas formas em classes diferentes. Um mtodo a implementao de uma operao para uma classe. Por exemplo, a operao imprimir pode ser implementada de forma distinta, dependendo se o arquivo a ser impresso contm apenas texto ASCII, um arquivo de um processador de texto ou binrio. Todos estes mtodos executam a mesma operao -- imprimir o arquivo; porm, cada mtodo ser implementado por um diferente cdigo. A assinatura de um mtodo dada pelo nmero e tipos de argumentos do mtodo, assim como por seu valor de retorno. Uma estratgia de desenvolvimento recomendvel manter assinaturas coerentes para mtodos implementando uma dada operao, assim como um comportamento consistente entre as implementaes. Em termos de diagramas OMT, operaes so listadas na terceira parte da caixa de uma classe. Cada nome de operao pode ser seguida por detalhes opcionais, tais como lista de argumentos e tipo de retorno. A lista de argumentos apresentada entre parnteses aps o nome da operao. Uma lista de argumentos vazia indica que a operao no tem argumentos; da ausncia da lista de argumentos no se pode concluir nada. O tipo
13
de resultado vem aps a lista de argumentos, sendo precedido por dois pontos (:). Caso a operao retorne resultado, este no deve ser omitido -- esta a forma de distingu-la de operaes que no retornam resultado.
2.3. Mensagens Os objetos se comunicam apenas atravs de mensagens. Quando um objeto deseja alguma tarefa de um outro objeto, ele envia uma mensagem contendo o nome do objetoorigem, nome do objeto-destino, nome do mtodo a ser ativado no objeto-destino e, se necessrio, parmetros que permitem especificar alguma funo especial a ser executada pelo mtodo. Este conceito se assemelha a chamada de uma rotina em uma linguagem tradicional. O conjunto de mensagens que um objeto pode responder definido como protocolo de comunicao. Em resumo: A comunicao entre os objetos ocorre pela troca de mensagens; Um objeto solicita informaes de outro objeto para realizar suas funes; Uma mensagem a execuo de uma operao; Uma mensagem pode ou no enviar parmetros para outro objeto, bem como receber ou no uma resposta do mesmo. 2.4. Encapsulamento Encapsulamento vem de encapsular, que em programao orientada a objetos significa separar o programa em partes, o mais isoladas possvel. A idia tornar o software mais flexvel, fcil de modificar e de criar novas implementaes. Para exemplificar, podemos pensar em uma dona de casa (usurio) utilizando um liquidificador (sistema). O usurio no necessita conhecer detalhes do funcionamento interno do sistema para poder utiliz-lo, precisa apenas conhecer a interface, no caso, os botes que controlam o liquidificador. Outro exemplo clssico de encapsulamento o padro de projeto chamado Mediator. Uma grande vantagem do encapsulamento que toda parte encapsulada pode ser modificada sem que os usurios da classe em questo sejam afetados. No exemplo do liquidificador, um tcnico poderia substituir o motor do equipamento por um outro totalmente diferente, sem que a dona de casa seja afetada - afinal, ela continuar somente tendo que pressionar o boto. O encapsulamento protege o acesso direto (referncia) aos atributos de uma instncia fora da classe onde estes foram declarados. Esta proteo consiste em se usar modificadores de acesso mais restritivos sobre os atributos definidos na classe. Depois devem ser criados mtodos para manipular de forma indireta os atributos da classe.
14
Encapsular atributos tambm auxilia a garantir que o estado e o comportamento de um objeto se mantenha coeso. Por exemplo, no caso da classe Semaforo poderiamos ter um mtodo de acesso chamado lerCor(), e um modificador chamado proximaCor(). O estado mantido pois os usurios da classe no podem alterar as cores de um semforo ao seu bel prazer e, por exemplo, fazer a seguinte troca de cores: vermelho-amarelo-vermelho. comum usar o padro get<nomeDoAtributo> para o mtodo que retorna o valor atual do atributo e set<nomeDoAtributo> para o mtodo que modifica o valor de um atributo do objeto, como no exemplo abaixo: setComProtecao e getComProtecao. Exemplos: Sem encapsulamento
class NaoEncapsulado { //implicitamente h modificador, mas no o mais restritivo int semProtecao; } public class TesteNaoEncapsulado { public static void main(String[] args) { NaoEncapsulado ne = new NaoEncapsulado(); //ne uma instncia de NaoEncapsulado ne.semProtecao = 10; //acesso direto ao atributo System.out.println("Valor sem proteo: " + ne.semProtecao); //acesso direto aos atributos ou nao estupor } }
Com encapsulamento
class Encapsulado { //private um modificador de acesso de restrio mxima private int comProtecao; void setComProtecao(int valor){ comProtecao = valor; } int getComProtecao(){ return comProtecao; } } public class TesteEncapsulado { public static void main(String[] args) { Encapsulado e = new Encapsulado(); //"e" uma instncia de Encapsulado //acesso direto a um atributo protegido implicar erro de compilao e.comProtecao = 10; //deve-se acessar o atributos de forma indireta, encapsulada e.setComProtecao(10); System.out.println("Valor com proteo: " + e.getComProtecao()); } }
15
2.5. Interface e Classe Abstrata Em algumas linguagens de programao, o termo interface uma referncia caracterstica que permite a construo de interfaces que isolam do mundo exterior os detalhes de implementao de um componente de software. Um exemplo clssico de utilizao de interfaces o do sistema operacional que, atravs de uma interface de programao de aplicativos, permite que os programas utilizem os recursos do sistema (memria, CPU e etc) sem que os seus detalhes de implementao sejam conhecidos do programador. Este esquema isola e protege o sistema operacional de eventuais erros cometidos pela aplicao. Os componentes de software utilizam interfaces padronizadas para criar uma camada de abstrao que facilite a reutilizao e a manuteno do software. Neste cenrio, a interface de um mdulo de software A deve ser mantida em separado da sua implementao e qualquer outro mdulo B, que interaja com A (cliente de A), deve ser forado a faz-lo apenas atravs da interface. Este mecanismo permite que no caso de uma alterao em A, o mdulo B continue funcionando; desde que a utilizao do mdulo A pelo mdulo B satisfaa as especificaes da interface. Uma interface disponibiliza tipos variados de acesso entre componentes, como por exemplo: constantes, tipos de dado, procedimentos, especificao de excees e assinaturas de mtodos. Em alguns casos mais apropriado definir as variveis como parte das interfaces. O princpio da interface um alicerce da programao modular que, por sua vez, precursora e parte da programao orientada a objeto. Na programao orientada a objeto, a interface de um objeto consiste de um conjunto de mtodos que um objeto deve suportar. importante notar que as variveis de instncia no fazem parte da interface de um objeto pois devem ser acessadas somente pelos "mtodos de acesso". Historicamente, as interfaces so derivadas dos arquivos de cabealho da Linguagem C (normalmente arquivos com extenso ".h") que separam o contexto sinttico de um mdulo (ou prottipos de funes) da sua implementao. Algumas linguagens de programao orientadas a objeto exigem que a interface do objeto seja especificada de forma separada da implementao do objeto, enquanto outras no fazem esta exigncia. Por exemplo, em linguagens de programao como Objective-C, a classe do objeto define a sua interface e declarada em um arquivo de cabealho (header em ingls) e, por outro lado, a implementao da classe mantida em um arquivo chamado de "arquivo fonte". Devido tipagem dinmica existente na Objective-C, que permite o envio de mensagens para qualquer objeto, a interface de uma classe importante para determinar para quais mtodos um objeto de uma classe responde. A linguagem de programao Java, que recebeu influncia da Objective-C, utiliza outra abordagem para o conceito de interface, assim como outras linguagens orientadas a objeto, onde a interface especifica um conjunto de mtodos ou funcionalidades comuns a um conjunto de classes. Uma classe abstrata desenvolvida para representar entidades e conceitos abstratos. A classe abstrata sempre uma superclasse que no possui instncias. Ela define um modelo (template) para uma funcionalidade e fornece uma implementao incompleta a parte genrica dessa funcionalidade - que compartilhada por um grupo de classes derivadas. Cada uma das classes derivadas completa a funcionalidade da classe abstrata adicionando um comportamento especfico.
16
Uma classe abstrata normalmente possui mtodos abstratos. Esses mtodos so implementados nas suas classes derivadas concretas com o objetivo de definir o comportamento especfico. O mtodo abstrato define apenas a assinatura do mtodo e, portanto, no contm cdigo.
3. Herana Herana um princpio de orientao a objetos, que permite que classes compartilhem atributos e mtodos, atravs de "heranas". Ela usada na inteno de reaproveitar cdigo ou comportamento generalizado ou especializar operaes ou atributos. O conceito de herana de vrias classes conhecido como herana mltipla. Como exemplo pode-se observar as classes 'aluno' e 'professor', onde ambas possuem atributos como nome, endereo e telefone. Nesse caso pode-se criar uma nova classe chamada, por exemplo, 'pessoa', que contenha as semelhanas entre as duas classes, fazendo com que aluno e professor herdem as caractersticas de pessoa, desta maneira pode-se dizer que aluno e professor so subclasses de pessoa. 3.1. Definio Herana um mecanismo da OO que permite criar novas classes a partir de classes j existentes, aproveitando-se das caractersticas existentes na classe a ser extendida. Este mecanismo muito interessante, pois promove um grande reuso e reaproveitamento de cdigo existente. Com a herana possvel criar classes derivadas (subclasses) a partir de classes bases (superclasses). As subclasses so mais especializadas do que as suas superclasses, mais genricas. As subclasses herdam todas as caractersticas de suas superclasses, como suas variveis e mtodos. Imagine que dentro de uma organizao empresarial, o sistema de RH tenha que trabalhar com os diferentes nveis hierrquicos da empresa, desde o funcionrio de baixo escalo at o seu presidente. Todos so funcionrios da empresa, porm cada um com um cargo diferente. Mesmo a secretria, o pessoal da limpeza, o diretor e o presidente possuem um nmero de identificao, alm de salrio e outras caractersticas em comum.
17
Essas caractersticas em comum podem ser reunidas em um tipo de classe em comum, e cada nvel da hierarquia ser tratado como um novo tipo, mas aproveitando-se dos tipos j criados, atravs da herana.
Os subtipos, alm de herdarem todas as caractersticas de seus supertipos, tambm podem adicionar mais caractersticas, seja na forma de variveis e/ou mtodos adicionais, bem como reescrever mtodos j existentes na superclasse (polimorfismo). A herana permite vrios nveis na hierarquia de classes, podendo criar tantos subtipos quanto necessrio, at se chegar ao nvel de especializao desejado. Podemos tratar subtipos como se fossem seus supertipos, por exemplo, o sistema de RH pode tratar uma instncia de Presidente como se fosse um objeto do tipo Funcionrio, em determinada funcionalidade. Porm no possvel tratar um supertipo como se fosse um subtipo, a no ser que o objeto em questo seja realmente do subtipo desejado e a linguagem suporte este tipo de tratamento, seja por meio de converso de tipos ou outro mecanismo. Algumas linguagens de programao permitem herana mltipla, ou seja, uma classe pode estender caractersticas de vrias classes ao mesmo tempo. o caso do C++. Outras linguagens no permitem herana mltipla, por se tratar de algo perigo se no usada corretamente. o caso do Java. Na Orientao a Objetos as palavras classe base, supertipo, superclasse, classe pai e classe me so sinnimos, bem como as palavras classe derivada, subtipo, subclasse e classe filha tambm so sinnimos. 3.2. Especializao e Generalizao Uma subclasse herda as propriedades de sua classe-me; uma subclasse herda as propriedades das subclasses e assim por diante. Uma subclasse pode herdar a estrutura de dados e os mtodos, ou alguns dos mtodos, de sua superclasse. Ela tambm tem mtodos e s vezes, tipos de dados prprios. Subclasse uma classe que um subtipo de uma ou mais classes (denominadas superclasses). Como tal, ela herda todas as caractersticas de suas superclasses. Em outras palavras, todas as caractersticas de uma classe so reusveis por suas subclasses. Se a classe B herda de A, ento dizemos que B uma subclasse de A.
18
Superclasse Uma classe que um supertipo de uma ou mais classes (tb chamadas de subclasses). Como tal, ela uma classe a partir da qual todas as suas caractersticas so herdadas por suas subclasses. Em outras palavras, todas as caractersticas de uma superclasse so reusveis por aquelas classes que so seus subtipos. Se a classe B herda de A, ento dizemos que A uma superclasse de B.
Herana o termo em orientao a objetos que se refere criao de novas classes a partir de existentes onde os atributos e operaes comuns so agrupados para fins de reutilizao de cdigo. Observe as duas classes abaixo:
Perceba que h muitos atributos comuns entre elas e isso demanda muito trabalho para definir e alter-los. Alm disso, o que estas duas classes tm em comum? Elas fazem parte de um sistema de controle de pessoal e representam os funcionrios de uma empresa. Com base nesses fatos, aplicaremos a tcnica da generalizao para eliminar as duplicidades e deixar o modelo mais elegante. Para implementar a generalizao, criamos uma terceira classe generalista para agrupar os membros comuns de Gerente e Secretaria (matricula, nome, salario e depto). Essa classe deve receber um nome que tambm seja uma generalizao de gerente e secretria e, por isso, escolhemos Funcionario.
19
A classe pai, tambm chamada de superclasse, ou ancestral, quem possui os atributos comuns. A classe filha, ou subclasse, a classe que herda os membros da superclasse e ainda possui os seus especficos (por isso, a subclasse tende a ser maior que a superclasse). Assim, o passo seguinte retirar os atributos comuns das duas subclasses, deixando apenas os especficos:
Criamos um relacionamento de generalizao (cuja notao uma reta com um tringulo na ponta) entre Gerente e Funcionrio e outro entre Secretria e Funcionrio. A ponta da seta sempre deve apontar para a superclasse.
Outra forma de representao pode ser vista na figura abaixo. Para fazer isso na ferramenta JUDE, selecione um relacionamento, clique na ponta da seta, arraste e solte sobre a ponta da outra seta.
3.3. Composio e Agregao Em anlise e projeto orientado objetos, uma associao representa um relacionamento entre objetos. Por exemplo, vrios alunos podem estar associados um nico professor e um nico aluno pode estar associado vrios professores. Neste caso, no existe um relacionamento de posse entre esses objetos. Todos os objetos so independentes. Um aluno pode existir sem a necessidade de um professor, da mesma forma que possvel existir um professor sem a necessidade da existncia de um aluno.
20
Agregao e composio so tipos especiais de associaes. Agregao um tipo especial de associao onde tenta-se demonstrar que as informaes de um objeto precisam ser complementadas pelas informaes contidas em um ou mais objetos de outra classe, demonstrando um relacionamento todo-parte entre elas. interessante ressaltar que para ser agregao, as classes podem viver independentemente. Vejamos um exemplo onde temos as classes Time e Jogador. Um time pode ser composto de nenhum ou vrios jogadores. Um jogador pode estar contido no mximo em um time.
Poderamos apenas fazer uma associao entre Time e Jogador e extrair as cardinalidades, mas queremos dar um enfoque que as informaes do time so completadas pelos seus jogadores, ou seja, que os jogadores fazem parte do time. Entretanto, se eu excluir o time, os jogadores continuam existindo. Assim, utilizamos a notao da agregao que uma reta com um losango na ponta ligada classe do lado todo (que contm):
A composio uma variao da agregao onde se tenta representar um vnculo mais forte entre os objetos todo-parte ao ponto de um no existir sem o outro. Vejamos o exemplo entre as classes Revista e Edio. Uma revista deve ser composta de no mnimo um artigo, mas pode conter vrios. Um artigo obrigatoriamente deve pertencer a uma e somente uma revista.
Poderamos fazer apenas uma associao entre Revista e Artigo, mas queremos demonstrar que revista e artigos formam um nico conjunto e que um no existe sem o outro. O smbolo da composio diferencia-se graficamente da agregao por utilizar um losango preenchido que, da mesma forma, deve ficar do lado do objeto-todo:
Uma revista pode ter vrios artigos, mas se a revista for excluda, teremos que excluir tambm os artigos. No faz sentido ter um objeto artigo que ele esteja vinculado a uma revista. Sua nica razo de existir "compr" a revista. Agregao x Composio x Associao Imagine um cenrio onde temos duas classes "A" e "B" e estamos na dvida de qual relacionamento colocar entre elas. Inicie fazendo a seguinte pergunta:
21
1 - Se A for excludo, terei que excluir tambm o B? Sim = utilize relacionamento de composio No = pode ser agregao ou simplesmente uma associao. V para a pergunta 2. 2 B tem alguma utilidade sozinha? Sim = utilize uma associao comum No = utilize relacionamento de agregao 3.4. Herana mltipla A herana mltipla o fato de uma classe possuir mais de uma superclasse. Em outros termos, significa construir uma classe que herde as caractersticas de mais de uma classe ao mesmo tempo. Linguagens de programao como C++ permitem tal recurso, embora Java no o permita diretamente. Java permite apenas que haja herana mltipla de vrias interfaces.
Conceitualmente, a herana mltipla necessria para modelar o mundo real de maneira mais precisa. Na prtica, ela pode levar a problemas na implementao, pois nem todas as linguagens de programao orientadas a objetos suportam herana mltipla.
Em Java, uma interface especifica um conjunto de operaes que devem ser oferecidas por objetos que a implementarem.
22
package poo; public abstract interface InterfaceTest { public static final int CONSTANTE1 = 1; public static int CONSTANTE2 = 2; int CONSTANTE3 = 3; public abstract void metodo1(); public void metodo2(); }
Interfaces permitem a herana de tipos, no a herana de comportamento. Desta forma, no permitem a reutilizao de cdigo. 4. Polimorfismo Na programao orientada a objetos, o polimorfismo permite que referncias de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam. Assim, possvel tratar vrios tipos de maneira homognea (atravs da interface do tipo mais abstrato). O termo polimorfismo originrio do grego e significa "muitas formas" (poli = muitas, morphos = formas). 4.1. Definio Polimorfismo significa ter muitas formas, que significa um nico nome representando um cdigo diferente, selecionado por algum mecanismo automtico. Um nome, vrios comportamentos. O Polimorfismo no um pensamento novo para ns. Ele est contido em nosso dia a dia, principalmente na linguagem. Veja os exemplos: 1. Ontem sai para danar com uns amigos, mas acabamos danando porque no conseguimos encontrar um lugar que nos agradasse. 2. Jos cantou a noite inteira no Karaoke e Joo cantou a noite inteira a namorada de Jos. 3. O cachorro do Joo no foi passear ontem. Pensando mais em objetos e funcionalidades, pense agora no termo abrir, por exemplo. Voc pode abrir uma porta, uma caixa, uma janela e uma conta bancria. A palavra abrir pode ser aplicada a muitos objetos do mundo real sendo que cada objeto interpreta abrir de sua prpria maneira. Porm, voc pode simplesmente dizer abrir, para descrever a ao. Uma linguagem polimrfica a que suporta polimorfismo (Actionscript, Java), j a linguagem monomrfica no suporta polimorfismo (Pascal, ASP).
23
4.2. Variveis polimrficas Variveis polimrficas so do tipo da classe-pai e tambm podem referenciar objetos de qualquer uma das subclasses da mesma. Variveis polimrficas so ponteiros ou referncias. Considere um mtodo M sobreposto nas subclasses. Quando M invocado por uma varivel polimrfica, esta chamada vinculada dinamicamente ao mtodo da classe apropriada. Isto permite a extenso e a manuteno de sistemas com muito mais facilidade. Exemplo: Varivel polimrfica cathedral do tipo French_Gothic pode referenciar os mtodos draw de Reims, Amien e Chartres. Quando cathedraw for usada para chamar draw, esta chamada ser vinculada dinamicamente verso correta de draw. Se o exemplo das catedrais fosse escrito em C, os trs tipos de catedrais poderiam estar um struct. Haveria uma nica funo draw que usaria uma instruo switch, do seguinte modo: um parmetro por valor seria enviado a draw para especificar qual item do switch contm as diretivas de desenho corretas. Se adicionarmos uma nova catedral do tipo Paris, temos que modificar o switch e repensar o protocolo de draw. Com orientao a objetos, basta criar uma nova subclasse com seu mtodo sobreposto. No h necessidade de alterar o cdigo existente. 4.3. Mtodos construtores Vimos anteriormente que simples criar uma classe. Mas, para realmente conseguirmos utilizar a classe, ela deve conter pelo menos um mtodo construtor. O mtodo construtor desenvolvido da mesma forma que uma funo, a nica diferena que ele tem o mesmo nome da classe. Isso se deve ao fato de que um objeto deve ser construdo cada vez que chamamos a classe. E a responsabilidade de fazer isso do construtor. Isso parte do princpio que podemos ter dois objetos com a mesma caracterstica, mas que no so os mesmos objetos. Ou seja, ns podemos ter uma TV de 29" ligada no canal 15 e nosso amigo tem uma outra TV que tambm de 29" e est ligada no canal 15. Perceba que ambas as TVs tm as mesmas caractersticas, mas continuam sendo duas TVs diferentes. Sempre que criamos uma classe, Java automaticamente vincula um mtodo construtor padro interno com o mesmo nome da classe, mas sem inicializar nenhum atributo. Para demonstrar um mtodo construtor, criaremos um construtor padro sem argumentos no qual j contm os valores dos atributos definidos por ns mesmos. Ento, vamos imaginar que sempre que uma TV construda, o seu padro tamanho 21", desligada e no canal 0. Ento, podemos defin-lo como:
class TV { int tamanho; int canal; boolean ligada; TV(){ tamanho=21; canal=0; ligada=false; } }
24
Pronto! Com isso, ns j somos capazes de instanciar nossa classe. Objetos so estruturas de dados definidas e agrupas dentro de uma classe. Sempre que utilizamos um objeto ou classe devemos reservar espao em memria para que aquele objeto seja manipulado sem maiores problemas. Alm do mais, tambm podemos utilizar a mesma classe (com todos os seus mtodos e atributos) para manipular outros objetos que sero tratados de forma diferente (mesmo se tiverem as mesmas caractersticas do objeto anterior), pois sero dois endereos de memria diferentes. A vantagem de Java nos possibilitar uma instanciao rpida e simples, sem termos que nos preocupar com referncia a endereos e alocao dinmica de memria, pois quem trata de manipular a memria o prprio Java. Sem contar que, se um objeto no mais referenciado dentro do programa, o prprio Java trata de liberar os recursos de memria consumidos pelo objeto usando o Garbage Colletor - Coletor de Lixo. Quem faz o papel de instanciador em Java o new. New trata de reservar memria o suficiente para o objeto e criar automaticamente uma referncia a ele. Para new conseguir determinar o objeto, precisamos usar o mtodo construtor que ser usado como base para instanciar a classe e gerar o objeto. Tecnicamente, declaramos uma varivel qualquer como sendo do tipo da classe (ex.: TV minhaTV; ), depois instanciamos o objeto atribuindo a varivel o resultado obtido por new mais o mtodo construtor (ex.: minhaTV = new TV(); ). Apesar de parecer muitos detalhes, isso fica mais facilmente visualizado no cdigo abaixo.
public class TV { int tamanho; int canal; boolean ligada; TV() { tamanho = 21; canal = 0; ligada = false; } public static void main(String[] args) { TV objeto1 = new TV(); TV objeto2; objeto2 = new TV(); } }
No cdigo acima, criamos uma classe chamada TV com os mesmos atributos do exemplo da pgina Criao de Classes, e criamos um mtodo construtor que inicializa os atributos da classe TV com alguns valores. Declaramos duas variveis chamadas objeto1 e objeto2 sendo do tipo TV. Depois, instanciamos o objeto usando new e o mtodo construtor. Em resumo: Garantir que os objetos sero inicializados de forma correta; Tem o mesmo nome da classe; sempre executado quando o objeto criado; No retorna valor; No pode ser chamado diretamente;
25
Pode haver um ou mais mtodos construtores (com diferentes parmetros); Um mtodo construtor default um mtodo sem parmetros. 4.4. Sobrecarga de mtodo Sobrecarga de mtodo permite a existncia de vrios mtodos de mesmo nome, porm com assinaturas levemente diferentes, ou seja, variando no nmero, tipo de argumentos, no valor de retorno e at variveis diferentes. Ficar a cargo do compilador escolher de acordo com as listas de argumentos os procedimentos ou mtodos a serem executados. Suponha a seguinte classe escrita em Java: public class Soma { public int Soma(int x, int y) { return x+y; } public String Soma(String x, String y) { return x+y; } public double Soma(double x, double y) { return x+y; } } O mtodo que ser executado depende estritamente do tipo do parmetro passado e esta deciso ser feita pelo compilador. Exemplo da sobrecarga no diagrama UML
A importncia de permitir a sobrecarga de mtodos no reside em uma mera convenincia para evitar que se tenha que escolher e usar nomes novos para cada definio, ou para evitar conflitos entre nomes existentes em um determinado escopo e, assim, evitar a "poluio" do espao de nomes usados em programas. A sobrecarga de mtodos tem, outrossim, a propriedade fundamental de permitir que expresses e nomes definidos por meio do uso de smbolos sobrecarregados possam ser usados em contextos que requerem valores de tipos distintos, permitindo assim que sejam definidas novas abstraes polimrficas. Como um exemplo bastante simples, considere que o smbolo + sobrecarregado para adio de inteiros e nmeros de ponto flutuante. Nesse caso, podemos ter uma nica definio para computar a soma dos inteiros em uma lista, seja ela uma lista de inteiros ou uma lista de nmeros de ponto flutuante. Em outras palavras, podemos fazer uma nica definio, polimrfica, da mesma forma como ocorre no caso, to justamente louvado, do polimorfismo paramtrico.
26
5. Linguagem de Modelagem Unificada - UML A Unified Modeling Language (UML) uma linguagem de modelagem no proprietria de terceira gerao. A UML no uma metodologia de desenvolvimento, o que significa que ela no diz para voc o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notao grfica, a UML tambm especifica significados, isto , semntica. uma notao independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. Os objetivos da UML so: especificao, documentao, estruturao para subvisualizao e maior visualizao lgica do desenvolvimento completo de um sistema de informao. A UML um modo de padronizar as formas de modelagem. Embora a UML defina uma linguagem precisa, ela no uma barreira para futuros aperfeioamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em tcnicas antigas e marcantes da orientao a objetos, mas muitas outras influenciaro a linguagem em suas prximas verses. Muitas tcnicas avanadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessrio redefinir a sua estrutura interna. A UML ser a base para muitas ferramentas de desenvolvimento, incluindo modelagem visual, simulaes e ambientes de desenvolvimento. Em breve, ferramentas de integrao e padres de implementao baseados em UML estaro disponveis para qualquer um. A UML integrou muitas ideias adversas, e esta integrao acelera o uso do desenvolvimento de softwares orientados a objetos. 5.1. Conceitos A UML no um mtodo uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem a notao que o mtodo utiliza para expressar projetos enquanto que o processo indica quais passos seguir para desenvolver um projeto. A especificao da UML consiste de duas partes: Semntica - especifica a sintaxe abstrata e a semntica dos conceitos de modelagem esttica e dinmica de objetos; Notao especifica a notao grfica para a representao visual da semntica. A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental o processo de desenvolvimento de sistemas em pequenos passos. Uma iterao um lao de desenvolvimento que resulta na liberao de um subconjunto de produtos que evolui at o produto final percorrendo as seguintes atividades: Anlise de requisitos Anlise Projeto Implementao Teste
27
O detalhamento de cada etapa destas atividades define o mtodo de desenvolvimento de sistemas. A etapa de anlise de requisitos se caracteriza pela definio do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o relacionamento entre o ambiente e o sistema. Deve ser uma definio de necessidades do usurio e no uma proposta de soluo. O usurio deve indicar os requisitos prioritrios para o sistema. O grupo de anlise deve identificar as necessidades do usurio. Decises do projeto impostas no so caractersticas essenciais do domnio do problema. A anlise de requisitos compe-se dos seguintes diagramas: Diagrama de caso de uso; Diagrama de seqncia; Diagrama de colaborao; Para realizar a anlise de requisitos, primeiramente deve-se: Identificar objetivo e caractersticas do sistema; Identificar os requisitos essenciais; Descrever as necessidades do usurio; Elaborar diagrama de caso de uso; Elaborar diagrama de seqncia; Elaborar diagrama de colaborao A arquitetura de um sistema pode ser descrita atravs de 5 vises interligadas. Cada viso constitui uma projeo na organizao e estrutura do sistema, cujo foco est voltado para determinado aspecto desse sistema. A UML uma linguagem muito expressiva, abrangendo todas as vises necessrias ao desenvolvimento e implantao de sistemas: Viso de caso de uso: focaliza os comportamentos de um sistema devendo ser transparente a todos os envolvidos: gerentes, analistas, programadores e usurios finais. Viso de Projeto: focaliza a estrutura de um sistema atravs da definio de classes, colaboraes e as interfaces do sistema. Viso de Processo: focaliza as questes de desempenho e escalabilidade do sistema. Viso de Implementao: focaliza os artefatos fsicos (programas, bibliotecas, banco de dados) para a efetiva montagem do sistema. Viso de Implantao: focaliza a topologia do hardware, liberao e instalao do sistema.
28
Utilizamos a modelagem para compreender melhor o sistema que estamos desenvolvendo. Em um sentido mais amplo, um modelo uma simplificao da realidade. A modelagem visual com a UML torna a arquitetura do sistema mais tangvel, permitindo a avaliao em dimenses mltiplas. A UML permite avaliar a aderncia e a qualidade da arquitetura atravs de iteraes precoces com o usurio quando os defeitos podem ser corrigidos antes de comprometer o sucesso do projeto. Utilizando uma linguagem de modelagem padro como a UML, os diferentes membros da equipe tanto de desenvolvimento como business podem comunicar suas decises sem que haja ambiguidades ou diferenas de interpretao. A modelagem visual permite que os detalhes do processo sejam expostos ou escondidos conforme a necessidade, auxiliando o desenvolvimento de projetos complexos e extensos. Alm disto, a UML ajuda a manter a consistncia entre a especificao e a implementao atravs do desenvolvimento iterativo e do planejamento de testes em cada iterao. Com o desenvolvimento focado no usurio e no business, o resultado final diminuir o ciclo de vida e garantir a qualidade do sistema. 5.2. Histrico As linguagens de modelagem orientadas a objetos surgiram entre a metade da dcada de 1970 e o final da dcada de 1980, medida que o pessoal envolvido com metodologia, diante de um novo gnero de linguagens de programao orientadas a objeto e de aplicaes cada vez mais complexas, comeou a experimentar mtodos alternativos de anlise e projeto. A quantidade de mtodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o perodo de 1989 a 1994. Muitos usurios desses mtodos tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender inteiramente s suas necessidades. Destacaram-se algumas linguagens como o Booch, o OOSE (Object-Oriented Software Engineering) de Jacobson, e o OMT (Object Modeling Technique) de Rumbaugh. Podemos citar outros mtodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram mtodos completos, alguns se destacavam em algum ponto, porm tinham suas limitaes. O mtodo Booch destacava-se durante as fases de projeto e construo de sistemas, o OOSE fornecia excelente suporte para captura de requisitos, a anlise e o projeto em alto nvel; o OMT-2 era mais til com a anlise e sistemas de informaes com uso de dados. Na metade da dcada de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh (General Electrics) criadores de mtodos orientados a objetos, comearam a pegar as melhores idias e partiram para a criao de uma linguagem unificada de modelagem. Com isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com os quais os desenvolvedores de ferramentas pudessem criar uma ferramenta mais utilizvel. Usando tcnicas orientadas a objeto criariam uma linguagem que iria desde o conceito at o sistema executvel, no somente a sistemas complexos mas tambm a sistemas menores e tambm a outros problemas que no fossem sistemas de informao, podendo ser utilizado por seres humanos e mquinas. A criao da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificao dos mtodos Booch e OMT. O esboo da verso 0.8 do Mtodo Unificado foi lanado em outubro de 1995. Mais
29
ou menos na mesma poca Jacobson se associou Rational com a finalidade de incorporar o OOSE no escopo inicial da verso 0.8, resultando o lanamento da verso 0.9 da UML em junho de 1996. Foi ento aprovada pela comunidade de engenharia de software em geral. Muitas empresas ficaram interessadas, foi ento criada um consrcio com vrias empresas interessadas em dedicar recursos com o propsito de trabalhar uma definio mais forte e completa da UML. A criao da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. O foco inicial do projeto era a unificao dos mtodos Booch e OMT. O esboo da verso 0.8 do Mtodo Unificado foi lanado em outubro de 1995. Mais ou menos na mesma poca Jacobson se associou Rational com a finalidade de incorporar o OOSE no escopo inicial da verso 0.8, resultando o lanamento da verso 0.9 da UML em junho de 1996. Foi ento aprovada pela comunidade de engenharia de software em geral. Muitas empresas ficaram interessadas, foi ento criada um consrcio com vrias empresas interessadas em dedicar recursos com o propsito de trabalhar uma definio mais forte e completa da UML. Empresas que contriburam para a definio da UML 1.0, Digital Equipment Corporationm Hewlett-Packard, I-Logix, Intel-licorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments e Unisys. Resultando uma linguagem de modelagem bem definida , expressiva, poderosa, e que poderia ser aplicada a uma grande variedade de tipos de problemas. A UML foi oferecida para a OMG (Object Management Group) em janeiro de 1997, em resposta solicitao do prprio OMG de propostas para uma linguagem padro de modelagem. Entre janeiro a julho de 1997, o grupo original se expandiu, passando a incluir virtualmente todos os participantes e colaboradores da resposta inicial ao OMG, entre os quais se encontravam Andersen Consulting, Ericson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software e Taskon. Um grupo foi formado, liberado por Cris Kobryn da MCI Systemhouse e administrado por Ed Eykholt da Rational, com o propsito de formalizar a especificao da UML e de integrar a linguagem a outros esforos de padronizao. A verso 1.1 foi entregue a OMG em julho de 1997. Em setembro do mesmo ano, essa verso foi aceita pela ADTF (Analysis and Design Task Force) e pelo Architecture Board do OMG e, posteriormente submetida a votao de todos os membros da OMG. A verso 1.1 foi adotada pela OMG em 14 de novembro de 1997. A manuteno da UML foi ento assumida pela RTF (Revision Task Force) do OMG, sob a responsabilidade de Cris Kobryn. A RTF lanou uma reviso editorial, a UML 1.2., em junho de 1998. No final do mesmo ano, a RTF lanou a UML 1.3. Numa histria mais recente, a UML chegou a sua diagramao proposta pela nova verso UML 2.0, onde vrios diagramas sofreram reformulaes e novas adaptaes ao modelo, destacando tambm o surgimento de alguns novos diagramas de modelagem de sistemas com base na UML. Este padro UML 2.0 vem sendo trabalho em novas verses UML 2.1, 2.2 e 2.3.
30
5.3. Diagramas da UML A Unified Modelling Language (UML) uma linguagem ou notao de diagramas para especificar, visualizar e documentar modelos de 'software' orientados por objetos. O UML no um mtodo de desenvolvimento, o que significa que no lhe diz o que fazer primeiro ou o que fazer depois ou como desenhar o seu sistema, mas ajuda-o a visualizar o seu desenho e a comunicar com os outros. O UML controlado pelo Object Management Group (OMG) e a norma da indstria para descrever graficamente o 'software'. O UML est desenhado para o desenho de 'software' orientado por objetos e tem uma utilizao limitada para outros paradigmas de programao. A UML composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software. Os elementos UML so usados para criar diagramas, que representam um determinada parte, ou um ponto de vista do sistema. A Linguagem Unificada de Modelagem possui diagramas (representaes grficas do modelo parcial de um sistema) que so usados em combinao, com a finalidade de obter todas as vises e aspectos do sistema. Os Diagramas da UML esto divididos em Estruturais e Comportamentais. Diagramas Estruturais De Classe: Este diagrama fundamental e o mais utilizado na UML e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de classes com seus atributos e mtodos e os relacionamentos entre classes. De Objeto: O diagrama de objeto esta relacionado com o diagrama de classes e, praticamente um complemento dele. Fornece uma viso dos valores armazenados pelos objetos de um Diagrama de Classe em um determinado momento da execuo do processo do software. De Componentes: Est associado linguagem de programao e tem por finalidade indicar os componentes do software e seus relacionamentos. De implantao: Determina as necessidades de hardware e caractersticas fsicas do Sistema.
31
De Pacotes: Representa os subsistemas englobados de forma a determinar partes que o compem. De Estrutura: Descreve a estrutura interna de um classificador. Diagramas Comportamentais De Caso de Uso (Use Case): Geral e informal para fases de levantamento e anlise de Requisitos do Sistema. De Mquina de Estados: Procura acompanhar as mudanas sofridas por um objeto dentro de um processo. De Atividades: Descreve os passos a serem percorridos para a concluso de uma atividade. De Interao: Dividem-se em: a) De Sequncia: Descreve a ordem temporal em que as mensagens so trocadas entre os objetos. b) Geral interao: Variao dos diagramas de atividades que fornece viso geral dentro do sistema ou processo do negcio. c) De comunicao: Associado ao diagrama de Seqncia, complementando-o e concentrando-se em como os objetos esto vinculados. d) De tempo: Descreve a mudana de estado ou condio de uma instncia de uma classe ou seu papel durante o tempo.
5.3.1. Diagrama de Caso de Uso Objetivo O Diagrama de Use Cases tem o objetivo de auxiliar a comunicao entre os analistas e o cliente. Um diagrama de Use Cases descreve um cenrio que mostra as funcionalidades do sistema do ponto de vista do usurio. O cliente deve ver no diagrama de Use Cases as principais funcionalidades de seu sistema.
32
Notao O diagrama de Use Cases representado por: atores; use cases; relacionamentos entre estes elementos. Estes relacionamentos podem ser: associaes entre atores e use cases; generalizaes entre os atores; generalizaes, extends e includes entre os use cases. Estes use cases podem opcionalmente estar envolvidos por um retngulo que representa os limites do sistema. Em maiores detalhes: Atores Um ator representado por um boneco e um rtulo com o nome do ator. Um ator um usurio do sistema, que pode ser um usurio humano ou um outro sistema computacional. Use case Um use case representado por uma elipse e um rtulo com o nome do use case. Um use case uma funcionalidade do sistema.
Relacionamentos Ajudam a descrever os use cases Entre um ator e um use case o Associao Define uma funcionalidade do sistema do ponto de vista do usurio.
Entre atores o Generalizao - Os use cases de B so tambm use cases de A - A tem seus prprios use cases
33
Entre use cases o Include Um relacionamento include de um use case A para um use case B indica que B essencial para o comportamento de A. o Extend Um relacionamento extend de um use case A para um use case B indica que o use case A pode ser acrescentado para descrever o comportamento de B (no essencial). A extenso inserida no ponto de extenso do use case B. Ponto de extenso em um use case uma indicao de que outros use cases podero ser adicionados a ele. Quando o use case for invocado, ele verificar se suas extenses devem ou no serem invocadas. Generalizao ou Especializao (_um) Use case B _um use case A (A uma generalizao de B, ou B uma especializao de A). Um relacionamento entre um use case genrico para um mais especfico, que herda todas as caractersticas de seu pai.
34
Sistema Limites do sistema: representado por um retngulo envolvendo os use cases que compem o sistema. Nome do sistema: Localizado dentro do retngulo. Exemplo
5.3.2. Diagrama de Classe Objetivo Descrever os vrios tipos de objetos no sistema e o relacionamento entre eles. Perspectivas Um diagrama de classes pode oferecer trs perspectivas, cada uma para um tipo de observador diferente. So elas: Conceitual Representa os conceitos do domnio em estudo. Perspectiva destinada ao cliente.
35
Especificao Tem foco nas principais interfaces da arquitetura, nos principais mtodos, e no como eles iro ser implementados. Perspectiva destinada as pessoas que no precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.
Implementao - a mais utilizada de todas Aborda vrios detalhes de implementao, tais como navegabilidade, tipo dos atributos, etc. Perspectiva destinada ao time de desenvolvimento.
36
Um diagrama de classes contm: Entidades
Classe Representao grfica Classe Concreta Uma classe representada na forma de um retngulo, contendo duas linhas que separam 3 partes. A primeira contm no nome da classe, a segunda os atributos da classe e a ltima os mtodos da mesma. Classe Abstrata A representao de uma classe abstrata em UML quase igual representao de uma classe concreta, a nica diferena o estilo da fonte do nome da classe, que, neste caso, est em itlico. Interface Representao Grfica Representao Icon
Representao Label
Perspectivas:
Conceitual Apenas classes so utilizadas. Neste tipo de perspectiva, uma classe interpretada como um conceito. Apenas atributos so utilizados.
Especificao
37
Tanto classes como interfaces so utilizados neste tipo de perspectiva. O foco consiste em mostrar as principais interfaces e classes juntamente com seus mtodos. No necessrio mostrar todos os mtodos, pois o objetivo deste diagrama nesta perspectiva prover uma maior entendimento da arquitetura do software a nvel de interfaces.
Implementao Nesta perspectiva, vrios detalhes de implementao podem ser abordados, tais como: visibilidade de atributos e mtodos; parmetros de cada mtodo, inclusive o tipo de cada um; o tipos dos atributos e dos valores de retorno de cada mtodo.
o o
Relacionamentos
Papel Descreve o relacionamento.
Multiplicidade (utilizado em todas as perspectivas de forma uniforme) Notaes possveis Significa Zero ou uma instncia. A notao n..m 0..1 indica n para m instncias. 0..* ou No existe limite para o nmero de * instncias. 1 Exatamente uma instncia. 1..* Ao menos uma instncia. Exemplos: Tipos
38
Associao (utilizado em todas as perspectivas) Representao Grfica Associao
Perspectiva:
Conceitual Define um relacionamento entre duas entidades conceituais do sistema.
Especificao Define responsabilidades entre duas classes. Implica que existem mtodos que tratam desta responsabilidade.
Implementao Permite saber quem est apontando para quem, atravs da representao grfica da navegabilidade. Alm disto, possvel compreender melhor de que lado est a responsabilidade.
public class A { private B b; public A( ){ } public void setB( B b ){ this.b = b; } public B getB( ) { return b; } } public class B { public B( ){ } }
Herana ou Generalizao (utilizado em todas as perspectivas)

39
Representao Grfica
Perspectiva: Seja B uma generalizao (extenso) de A.

o
Conceitual Considera que B um subtipo ou um tipo especial de A. O que vlido para A, tambm vlido para B.
Especificao Ocorre uma herana de interface.
Implementao Ocorre uma herana de implementao.
Exemplo de uma herana de implementao:
Navegabilidade (utilizado apenas na perspectiva de implementao) Um relacionamento sem navegabilidade implica que ele pode ser lido de duas formas, isto , em suas duas direes. Ex.:
Uma empresa possui um trabalhador, como tambm um trabalhador trabalha em uma empresa. Utilizando a propriedade de navegabilidade, podemos restringir a forma de ler um relacionamento. Isto , em
40
vez de termos duas direes, teremos apenas uma direo (de acordo com a direo da navegao). Ex.:
Uma empresa possui um trabalhador.
Agregao (utilizado apenas na perspectiva de implementao) Definio Agregao uma associao em que um objeto parte de outro, de tal forma que a parte pode existir sem o todo. Em mais baixo nvel, uma agregao consiste de um objeto contendo referncias para outros objetos, de tal forma que o primeiro seja o todo, e que os objetos referenciados sejam as partes do todo. A diferena entre os relacionamentos de associao e agregao ainda algo de bastante discusso entre os gurus. De forma geral, utiliza-se agregao para enfatizar detalhes de uma futura implementao (perspectiva de implementao). Representao grfica Agregao com navegabilidade
public class A { private B b; public A( ){ } public void setB( B b ){ this.b = b; } public B getB( ) { return b; } } public class B { public B( ){
41
} }
Composio (utilizado apenas na perspectiva de implementao) Definio Em mais baixo nvel, em termos de passagem por parmetro, seria uma passagem por valor. Enquanto que agregao seria uma passagem por referncia. O todo contm as partes (e no referncias para as partes). Quando o todo desaparece, todas as partes tambm desaparecem. Representao Grfica
public class A { private B b; public A( ){ b = new B(); } } public class B { public B( ){ } }
Implementao (utilizado apenas na perspectiva de implementao)
Definio Utilizado para indicar que uma classe implementa uma interface Representao Grfica
42
Exemplo Implementao de uma interface representada por um crculo Implementao de uma interface representada por um retngulo
Exemplo contendo as notaes
5.3.3. Diagrama de Seqncia Em um sistema computacional orientado a objeto os servios (casos de uso) so fornecidos atravs da colaborao de grupos. Os objetos interagem atravs de comunicaes de forma que juntos, cada um com suas responsabilidades, realizem os casos de uso. O Diagrama de seqncia uma ferramenta importante no projeto de sistemas orientados a objetos. Embora a elaborao dos diagramas possa consumir um tempo considervel para sistemas maiores ou mais complexos, eles oferecem a seguir as bases
43
para a definio de uma boa parte do projeto como: os relacionamentos necessrios entre as classes, mtodos e atributos das classes e comportamento dinmico dos objetos. Um diagrama de seqncia um diagrama de objetos, ou seja, ele contm como primitiva principal um conjunto de objetos de diferentes classes. O objetivo dos diagramas de seqncia descrever as comunicaes necessrias entre objetos para a realizao dos processos em um sistema computacional. Os diagramas de seqncia tm este nome porque descrevem ao longo de uma linha de tempo a seqncia de comunicaes entre objetos. Como podem existir muitos processos em um sistema computacional, sugere-se proceder construo dos diagramas de seqncia por caso de uso. Assim, tomar-se-ia separadamente cada caso de uso para a construo de seus diagramas de seqncia. De uma forma geral, para cada caso de uso constri-se um diagrama de seqncia principal descrevendo as seqncias normais de comunicao entre objetos e diagramas complementares descrevendo seqncias alternativas e tratamento de situaes de erro. Utiliza-se tambm o termo cenrio associado com os diagramas de seqncia. Um cenrio uma forma de ocorrncia de um caso de uso. Como o processo de um caso de uso pode ser realizado de diferentes formas, para descrever a realizao de um caso de uso pode ser necessrio estudar vrios cenrios. Cada cenrio pode ser descrito por um diagrama de seqncia. No exemplo do caso de uso Cadastrar Aluno do sistema de controle acadmico, podem-se considerar os cenrios de incluso, alterao e excluso de aluno. A notao UML para descrio de diagramas de seqncia envolve a indicao do conjunto de objetos envolvidos em um cenrio e a especificao das mensagens trocadas entre estes objetos ao longo de uma linha de tempo. Os objetos so colocados em linha na parte superior do diagrama. Linhas verticais tracejadas so traadas da base dos objetos at a parte inferior do diagrama representando a linha de tempo. O ponto superior destas linhas indica um instante inicial e, medida que se avana para baixo evolui-se o tempo. Retngulos colocados sobre as linhas de tempo dos objetos indicam os perodos de ativao do objeto. Durante um perodo de ativao, o objeto respectivo esta em execuo realizando algum processamento. Nos perodos em que o objeto no esta ativo, ele esta alocada (ele existe), mas no esta executando nenhuma instruo. A figura abaixo ilustra a estrutura bsica de um diagrama de seqncia para o cenrio Incluso de Aluno do caso de uso Cadastrar Aluno.
Outra primitiva importante dos diagramas de seqncia a troca de mensagem. Esta primitiva utilizada para indicar os momentos de interao ou comunicao entre os objetos. Utiliza-se como notao para trocas de mensagens segmentos de retas
44
direcionadas da linha de tempo de um objeto origem para a linha de tempo de um objeto destino. Uma seta colocada na extremidade do objeto destino. As linhas representando troca de mensagens so desenhadas na horizontal, pois se presume que a troca de uma mensagem consome um tempo desprezvel. O objeto destino de uma mensagem deve receber a mensagem e processa-la. Desta forma, no recebimento de uma mensagem o objeto destino ativado para tratamento da mensagem. A figura abaixo ilustra a troca de mensagens entre objetos e entre atores e objetos.
As mensagens trocadas entre um objeto ou entre um objeto e um ator podem ter trs significados:
Chamada de Funo ou Procedimento
Uma das interaes mais freqentes entre objetos a chamada de funo. Uma chamada de funo significa que um objeto esta solicitando a execuo de uma funo (um mtodo) de um outro objeto. Este conceito segue estritamente o processo de chamada de funo ou de procedimento utilizado nas linguagens de programao. Obviamente, para que um objeto possa chamar um mtodo de outro objeto necessrio que o mtodo seja declarado como publico na classe respectiva. Como ser visto a seguir, a sintaxe, no caso de mensagens que representem chamadas de funo, semelhante quela das linguagens de programao.
Envio de Mensagem
Objetos tambm podem comunicar-se com outros objetos atravs do envio explcito de uma mensagem. O envio de uma mensagem, ao contrario da chamada de funo, no uma interao direta entre dois objetos. Na verdade, quando um objeto envia uma mensagem a outro objeto, a mensagem roteada ou encaminhada por algum mecanismo de entrega de mensagens. Normalmente, este servio prestado pelo sistema operacional atravs de mecanismos como Message Queries (filas de mensagens) ou servios de notificao.
45
Ocorrncia de Evento
Existem tambm outras formas de interao entre objetos atravs de eventos. Esta tambm a forma padro de interao entre objetos e atores. Basicamente, um evento algum acontecimento externo ao software, mas que a ele notificado, pois lhe diz respeito. A notificao, ou seja, a indicao de que um determinado evento ocorreu , na maioria dos casos, feita pelo sistema operacional. Eventos podem tambm ser gerados pelo software para o sistema operacional. Exemplos so as sadas para dispositivos (monitor, porta serial, disco) feitos atravs de servios do sistema operacional.
Tipos de Mensagens
Nos exemplos das figuras utilizou-se como notao grfica para as trocas de mensagens segmentos de reta com uma seta aberta em uma das extremidades. Esta a notao genrica para mensagens que pode ser utilizada nas primeiras verses dos diagramas de seqncia. Em diagramas mais detalhados, entretanto, ser utilizada outra notao deforma a indicar tambm o tipo das mensagens. Existem dois tipos de mensagens chamadas mensagens sncronas e assncronas.
Mensagens Sncronas
Mensagens sncronas so mensagens que implicam um sincronismo rgido entre os estados do objeto que envia a mensagem e os do objeto de destino da mensagem. Um sincronismo entre objetos pode ser entendido, de uma forma geral, como uma dependncia na evoluo de estado de um objeto sobre o estado de um segundo objeto. De uma forma mais direta, pode-se dizer que uma mensagem sncrona implica que o objeto que enviou a mensagem aguarde a concluso do processamento da mensagem (entendida como um sinal de sincronismo) feito pelo objeto destino, para ento prosseguir seu fluxo de execuo. O exemplo mais comum de mensagem sncrona a chamada de funo. Em uma chamada de funo o objeto que faz a chamada empilhado e fica neste estado at a concluso do processamento da funo chamada. Trata-se, portanto, de um sincronismo rgido entre o objeto chamador e o objeto chamado. Alguns sistemas operacionais oferecem tambm mecanismos de troca de mensagens sncronas de forma que o objeto que envia a mensagem fique em estado de espera at a concluso do tratamento da mensagem. A notao UML para uma mensagem sncrona a de um segmento de reta com uma seta cheia em uma das extremidades
Mensagens Assncronas
Mensagens assncronas so mensagens enviadas de um objeto a outro sem que haja uma dependncia de estado entre os dois objetos. O objeto de origem envia a mensagem e prossegue seu processamento independentemente do tratamento da mensagem feita no objeto destino. Os mecanismos de envio de mensagens suportados pelos sistemas operacionais so o exemplo mais comum deste tipo de mensagem. Alm disso, de uma forma geral, todas as comunicaes entre atores e objetos representam trocas de mensagem assncronas. Considere, por exemplo, uma operao para apresentao de uma
46
mensagem no monitor. Um objeto executa uma instruo print (ou print ou write) e o sistema despacha a mensagem para o ator (o monitor). O objeto prossegue seu processamento independentemente do desfecho na operao. Observe que os softwares no bloqueiam quando o monitor no apresenta alguma informao. A notao UML para uma mensagem assncrona a de um segmento de reta com uma meia seta em uma das extremidades. Autodelegao Um objeto pode enviar mensagens para outros objetos e pode tambm enviar mensagens para ele prprio. Uma mensagem enviada de um objeto para ele prprio chamase uma Autodelegao. Mensagens de Autodelegao podem ser sncronas ou assncronas. O caso mais comum de mensagens assncronas o envio de uma mensagem de um objeto para ele mesmo atravs de mecanismos de envio de mensagens do sistema operacional. O caso mais comum de mensagens de Autodelegao sncronas a chamada de funo de um objeto pelo prprio objeto.
5.3.4. Diagrama de Estado Usando uma interao (diagrama de seqncia ou de colaborao), voc pode fazer a modelagem do comportamento de uma sociedade de objetos que trabalham em conjunto. Usando a mquina de estados, voc pode fazer a modelagem do comportamento de um objeto individual. Modela o comportamento dos objetos de uma classe ao longo do seu tempo de vida. Especifica as seqncias de estados pelas quais um objeto passa durante seu tempo de vida. So utilizados somente para classes cuja mudana de estado relevante ou significativa para o sistema. Ou seja, somente para objetos cujo comportamento atual depende do seu passado. O Estado de um objeto caracterizado pelos valores de um ou mais de seus atributos. Um dos diagramas da UML para a modelagem de aspectos dinmicos de um sistema.
47
Pode ser utilizado para a modelagem dos estados (tempo de vida) de um objeto ou do sistema inteiro. As mudanas de estado so, em geral, ocasionadas pelos eventos recebidos pelos objetos. Um Evento pode ser um Sinal (estmulo assncrono), uma Operao (estmulo sncrono) ou a Passagem do Tempo.
Um Estado representa uma situao ou condio na qual um objeto pode se encontrar ao longo da sua existncia no sistema. O Estado de um objeto muda ao longo do tempo. Diagramas de Estado possuem um nico Estado Inicial e um ou mais Estados Finais. Estados iniciais e finais so na realidade pseudo-estados. O Diagrama de Estados determina eventos, aes e condies possveis ao objeto. Transio: Uma Transio representa uma mudana de estado. Transies podem ser automticas ou geradas por eventos. Partes de uma transio: Evento: aciona a transio de estado. Pode ser gerado por um ator externo ao sistema ou por um objeto do sistema. Condio (ou condio de guarda): indica quando a transio de estado deve ocorrer. Ao: indica um mtodo do objeto que deve ser executado quando a transio de estado se realizar. Obs.: todas as partes de uma transio so opcionais.
Es tado 1
Evento[ condio ] / ao
Es tado 2
48
matricular[ docs. incompletos ] / emitir comprovante Incio matricular[ docs. completos ] / emitir comprovante
Em Aberto
entrega docs.[ docs. completos ]
Regular
reabrir matrcula[ incio perodo ] trancar matrcula[ 1 per. concludo ]
Trancada
Um Estado tem vrias partes: 1. Nome. 2. Aes de entrada/sada: aes executadas na entrada ou sada do estado, respectivamente. 3. Transies internas: transies que no causam a mudana do estado. 4. Sub-estados: a estrutura aninhada de um estado, envolvendo subestados disjuntos (seqencialmente ativos) ou concorrentes (concorrentemente ativos). 5. Eventos adiados: uma lista de eventos que no so manipulados neste estado, mas, em vez disso, so adiados e colocados em fila para serem manipulados pelo objeto em outro estado. Uma Transio um relacionamento entre dois estados. Uma Transio tem cinco partes: 1. Estado de origem: o estado afetado pela transio. 2.Estado destino: o estado que est ativo aps a concluso da transio. 3.Evento de ativao. 4.Condio: expresso booleana que avaliada quando a transio iniciada pela recepo do evento de ativao; se for verdadeira, a transio ocorre; seno, a transio cancelada. 5. Ao. Obs.: Uma transio pode ser iniciada quando um objeto receber o evento de ativao da transio e a condio de proteo (ou de guarda), se houver, for satisfeita.
49
Disponibilizada
estud ante solicita ins cri o / co ntado rEstudantes = 0
estudante solicita inscrio[ contadorEstudantes < 10 ]
[ contadorEstudantes = 10 ]
Aberta
entry/ registrar estudante; contadorEstudantes ++
Fechada
cancelar turma
cancelar turma
Cancelada entry/ notificar estudantes registrados
5.4. Ferramentas CASE A sigla CASE significa Computer-Aided Software Engineering. Traduzindo para um bom portugus: Engenharia de Software Auxiliada por Computador. Uma ferramenta CASE um aplicativo que auxilia os profissionais envolvidos na tarefa de produzir sistemas. O tipo de ajuda que a ferramenta fornece, depende exclusivamente da proposta do fabricante. Por este motivo, as ferramentas se dividem em trs categorias. So elas: Lower CASE - ferramentas de codificao (front-end); Upper CASE - ferramentas de anlise, projeto e implementao; Integrated CASE - unio de Upper e Lower CASE; Um dos componentes indispensveis de uma ferramenta CASE a modelagem visual, ou seja, a possibilidade de representar, atravs de modelos grficos, o que est sendo definido. No nosso caso, anlise orientada a objetos atravs da UML. Alguns exemplos: StarUML um software que modela vrios tipos de diagramas. um projeto elaborado para trabalhar no Windows de maneira flexvel e com ferramentas prticas. Desenhar fluxogramas til para que voc possa visualizar todos os processos que ocorrem em uma seqncia de tarefas, por exemplo. Na barra superior de StarUML, voc encontra opes para formatao, como alterar fonte, estilos de linhas das caixas do seu diagrama, alterar o layout, etc. A opo Model (Modelo) permite que voc adicione diagramas e verifique se seus projetos esto de acordo com as especificaes de UML, bem como converter diagramas seqnciais para diagramas de elaborao, e vice-versa.
50
ArgoUML uma aplicao open source que usa UML para modelar o desenho de software de computador. A aplicao corre na maior parte das plataformas uma vez que implementada em Java. Est distribuda sob a licena BSD. Providencia suporte para quase todos os tipos de diagrama da UML padro e inclui suporte cognitivo. A Software Development Magazine realiza uma premiao anual entre ferramentas populares de desenvolvimento de software em vrias categorias. Em 2003 o ArgoUML foi um dos finalistas na categoria "Ferramentas de Design e Anlises". Ele recebeu um prmio de revelao, derrotando vrias ferramentas comerciais. Apesar disso, at a verso 0.20, o ArgoUML estava ainda incompleto. Ele no tinha conformidade completa com o padro UML e no oferecia suporte total a alguns tipos de diagramas, incluindo diagramas de seqncias.
51
JUDE/Community uma ferramenta de modelagem UML gratuita com funcionalidades bsicas. Ele rico em funcionalidade, oferecendo caractersticas como edio e impresso de diagramas UML 2.0, importa/exporta cdigo fonte Java, sada de grficos e disposio automtica.
52
Hino Nacional
Ouviram do Ipiranga as margens plcidas De um povo herico o brado retumbante, E o sol da liberdade, em raios flgidos, Brilhou no cu da ptria nesse instante. Se o penhor dessa igualdade Conseguimos conquistar com brao forte, Em teu seio, liberdade, Desafia o nosso peito a prpria morte! Ptria amada, Idolatrada, Salve! Salve! Brasil, um sonho intenso, um raio vvido De amor e de esperana terra desce, Se em teu formoso cu, risonho e lmpido, A imagem do Cruzeiro resplandece. Gigante pela prpria natureza, s belo, s forte, impvido colosso, E o teu futuro espelha essa grandeza. Terra adorada, Entre outras mil, s tu, Brasil, Ptria amada! Dos filhos deste solo s me gentil, Ptria amada,Brasil! Deitado eternamente em bero esplndido, Ao som do mar e luz do cu profundo, Fulguras, Brasil, floro da Amrica, Iluminado ao sol do Novo Mundo! Do que a terra, mais garrida, Teus risonhos, lindos campos tm mais flores; "Nossos bosques tm mais vida", "Nossa vida" no teu seio "mais amores." Ptria amada, Idolatrada, Salve! Salve! Brasil, de amor eterno seja smbolo O lbaro que ostentas estrelado, E diga o verde-louro dessa flmula - "Paz no futuro e glria no passado." Mas, se ergues da justia a clava forte, Vers que um filho teu no foge luta, Nem teme, quem te adora, a prpria morte. Terra adorada, Entre outras mil, s tu, Brasil, Ptria amada! Dos filhos deste solo s me gentil, Ptria amada, Brasil!
Hino do Estado do Cear

Poesia de Thomaz Lopes Msica de Alberto Nepomuceno Terra do sol, do amor, terra da luz! Soa o clarim que tua glria conta! Terra, o teu nome a fama aos cus remonta Em claro que seduz! Nome que brilha esplndido luzeiro Nos fulvos braos de ouro do cruzeiro! Mudem-se em flor as pedras dos caminhos! Chuvas de prata rolem das estrelas... E despertando, deslumbrada, ao v-las Ressoa a voz dos ninhos... H de florar nas rosas e nos cravos Rubros o sangue ardente dos escravos. Seja teu verbo a voz do corao, Verbo de paz e amor do Sul ao Norte! Ruja teu peito em luta contra a morte, Acordando a amplido. Peito que deu alvio a quem sofria E foi o sol iluminando o dia! Tua jangada afoita enfune o pano! Vento feliz conduza a vela ousada! Que importa que no seu barco seja um nada Na vastido do oceano, Se proa vo heris e marinheiros E vo no peito coraes guerreiros? Se, ns te amamos, em aventuras e mgoas! Porque esse cho que embebe a gua dos rios H de florar em meses, nos estios E bosques, pelas guas! Selvas e rios, serras e florestas Brotem no solo em rumorosas festas! Abra-se ao vento o teu pendo natal Sobre as revoltas guas dos teus mares! E desfraldado diga aos cus e aos mares A vitria imortal! Que foi de sangue, em guerras leais e francas, E foi na paz da cor das hstias brancas!

Foo

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Foo

Încărcat de

Drepturi de autor:

Formate disponibile

Escola Estadual de Educao Profissional - EEEP

Ensino Mdio Integrado Educao Profissional

Curso Tcnico em Informtica

Fundamentos de Orientao a Objeto

Governador Cid Ferreira Gomes Vice Governador Francisco Jos Pinheiro

Secretrio Executivo Antnio Idilvan de Lima Alencar

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Fundamentos de Orientao a Objeto

BORATTI, Isaias. Programao Orientada a Objetos em JAVA. Editora Visual Books.

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Informtica Fundamentos de Orientao a Objetos

Escola Estadual de Educao Profissional [EEEP]

Ensino Mdio Integrado Educao Profissional

Escola Estadual de Educao Profissional [EEEP]