OO - Monografia

Universidade Federal da Paraba Centro de Cincias Exatas e da Natureza Departamento de Informtica
Monografia
Desenvolvimento de Sistemas Utilizando Orientao a Objetos
Soila Mara Pereira Rosado
JOO PESSOA PB julho de 2003
Universidade Federal da Paraba Centro de Cincias Exatas e da Natureza Departamento de Informtica
Desenvolvimento de Sistemas Utilizando Orientao a Objetos
Soila Mara Pereira Rosado
Monografia apresentada coordenao do Curso de Especializao em Sistemas de Informao e Redes do Departamento de Informtica da Universidade Federal da Paraba UFPB, como requisito parcial para a obteno do grau de Especialista. Orientador: lvaro Francisco de Castro Medeiros- Dr. (Orientador)
JOO PESSOA PB julho de 2003

Monografia Desenvolvimento de Sistemas utilizando Orientao a Objetos Soila Mara Pereira Rosado
Muitos so os planos do corao do homem, mas o propsito do Senhor que permanecer. Provrbios 19,21.
Resumo Este documento busca transmitir uma idia bsica do desenvolvimento de sistemas orientados a objetos, no sendo aqui demonstrado nenhuma metodologia em especial. Devido grande variedade de mtodos e ferramentas, procurei manter o documento o mais genrico possvel, de modo a demonstrar apenas os tpicos relevantes em uma introduo ao desenvolvimento OO. O pblico alvo so os analistas e desenvolvedores iniciantes na arte da OO. O assunto aqui selecionado abrange os aspectos da OO, algumas tcnicas utilizadas por desenvolvedores muito experientes e introduz os conceitos mais utilizados da UML para desenvolvimento OO. Alguns padres de desenvolvimento so apresentados como um complemento ao desenvolvimento e por se tratar de um assunto extremamente relacionado ao desenvolvimento de um sistema bem estruturado.
Sumrio
RESUMO......................................................................................................................................................... 4 LISTA DE FIGURAS ................................................................................................................................... 7 INTRODUO .............................................................................................................................................. 8

1.1 Objetivos .................................................................................................................................. 9 1.2 Objetivo Geral ......................................................................................................................... 9 1.3 Objetivos Especficos ............................................................................................................ 9
ORIENTAO A OBJETOS .................................................................................................................. 10 2.1 Histrico ................................................................................................................................. 10 2.2 Benefcios .............................................................................................................................. 11 2.3 Desvantagens da OO .......................................................................................................... 12 2.4 Introduo abordagem OO .............................................................................................. 12 2.5 Principais Conceitos ............................................................................................................ 12 2.5.1 Objetos ........................................................................................................................ 13 2.5.2 Classes ........................................................................................................................ 15 2.5.3 Herana ....................................................................................................................... 17 2.5.4 Polimorfismo................................................................................................................ 19 TCNICAS DE MODELAGEM ORIENTADAS A OBJETOS...................................................... 22 3.1 Histrico ................................................................................................................................. 22 3.2 Diferenas em Relao Anlise estruturada ................................................................ 23 UML ................................................................................................................................................................ 24 4.1 Histrico ................................................................................................................................. 24 4.2 O que a UML .................................................................................................................... 25 4.4 Modelo de Elemento ............................................................................................................ 28 4.4.1 Classes ........................................................................................................................ 28 4.4.2 Casos de Uso .............................................................................................................. 29 4.4.3 Componentes ..............................................................................................................32 4.4.4 Colaboraes .............................................................................................................. 33 4.4.5 Pacote.......................................................................................................................... 33 4.4.6 Interface....................................................................................................................... 33 4.5 Relacionamentos.................................................................................................................. 34 4.5.1 Associaes ................................................................................................................ 34 4.5.2 Agregao ................................................................................................................... 35 4.5.3 Generalizaes/Especializaes ................................................................................ 35 4.5.4 Composio/ Decomposio ...................................................................................... 36 4.5.5 Dependncia ............................................................................................................... 37 4.5.6 Mecanismos Gerais..................................................................................................... 37 4.6 Diagramas ............................................................................................................................. 38
4.6.1 Diagramas de Iterao ................................................................................................ 39 4.6.3 Diagrama de Classes .................................................................................................. 41 4.6.4 Diagrama de Objetos .................................................................................................. 42 4.6.5 Diagrama de Estados.................................................................................................. 43 4.6.6 Diagrama de Atividades .............................................................................................. 44 4.6.7 Diagrama de Componentes ........................................................................................ 45 4.6.8 Diagrama de Execuo............................................................................................... 45 4.7 Ciclo de desenvolvimento ................................................................................................... 46 4.8 Fases de Desenvolvimento de Sistemas ......................................................................... 47 4.8.1 Anlise de Requisitos.................................................................................................. 47 4.8.2 Anlise ......................................................................................................................... 47 4.8.3 Design.......................................................................................................................... 52 4.8.4 Programao ............................................................................................................... 52 4.8.5 Testes .......................................................................................................................... 52 PADRES .................................................................................................................................................... 53 5.1 Grasp...................................................................................................................................... 54 5.1.1 Expert .......................................................................................................................... 55 5.1.2 Creator......................................................................................................................... 55 5.1.3 Low Coupling............................................................................................................... 56 5.1.4 High Cohesion ............................................................................................................. 57 5.1.5 Controller ..................................................................................................................... 57 CONCLUSO.............................................................................................................................................. 58 REFERNCIAS BIBLIOGRFICAS .................................................................................................... 59 ARTIGOS E SITES CONSULTADOS NA INTERNET .................................................................. 59
Lista de Figuras Figura 1 -Representao para um objeto .....................................................................13 Figura 2 Representao para a passagem de mensagens entre objetos. ...............14 Figura 3 - Representao de uma classe .....................................................................16 Figura 4 Representao de Herana.........................................................................18 Figura 5 Diferentes Vises do Sistema.....................................................................26 Figura 6 Representao de uma viso do sistema. .................................................27 Figura 7 Representao de uma classe e seus mtodos. ........................................28 Figura 8 - Representao de Ator.................................................................................31 Figura 9 - Representao do Caso de Uso Registrar Emprstimo..............................31 Figura 10 Representao de Componente...............................................................32 Figura 11 Representao de Pacote. ........................................................................33 Figura 12 - Representao de Interface ......................................................................34 Figura 13 Representao de Associao..................................................................35 Figura 14 Representao de Agregao...................................................................35 Figura 15 Representao de Generalizao .............................................................36 Figura 16 Representao de Composio ................................................................37 Figura 18 Representao de um ornamento .............................................................38 Figura 19 - Diagrama de seqncia..............................................................................40 Figura 20 - Diagrama de Colaborao..........................................................................40 Figura 21 Representao para um Diagrama de Casos de Uso ..............................41 Figura 22 Representao para Diagrama de Classes ..............................................42 Figura 23 Representao para um Diagrama de Objetos........................................43 Figura 24 Representao para um Diagrama de Estados ........................................44 Figura 25 Representao para um Diagrama de Atividades ....................................44 Figura 26 Representao para um Diagrama de Componentes ..............................45 Figura 27 Representao para um Diagrama de Execuo .....................................46 Figura 28 Representao de Modelo Conceitual ......................................................51 Figura 29 Representao da Atribuio de responsabilidade ..................................56 Figura 30 Representao de uma classe para Controller.........................................58
Introduo O termo baseados em objetos identifica um software estruturado como uma coleo de objetos que incorporam tanto a estrutura quanto o comportamento dos dados. O oposto, que o modelo convencional de programao, possui pouca ou nenhuma vinculao entre a estrutura e o comportamento dos dados. A aplicao da OO durante o desenvolvimento de software ainda bastante reduzida devido dificuldade de encontrar profissionais capacitados para esta tarefa e falta de credibilidade nos benefcios desta tcnica. O mercado est utilizando algumas caractersticas da orientao a objetos, mas nem tudo aplicado, o que dificulta o aproveitamento de todas as suas vantagens. Muitas vezes, quando se desenvolve um projeto, feita uma Anlise OO mas o projeto desenvolvido em ferramentas que no permitem que se apliquem os conceitos oferecidos, isto em geral acaba gerando dvidas quanto aos benefcios da OO e desestimulando o profissional, fazendo com que utilize a metodologia tradicional, como a anlise estruturada ou essencial e a programao convencional baseada em rotinas e eventos. Para se obter um sistema OO necessrio que se utilize a OO durante toda a fase do ciclo de desenvolvimento, aplicando-se de forma correta as regras existentes, o que s possvel se houver o domnio da metodologia e a disponibilidade de ferramentas adequadas.
1.1 Objetivos
1.2 Objetivo Geral Compreender as tcnicas encontradas nos padres de desenvolvimento propostos por Craig Larman, que incentivam o desenvolvimento de sistemas utilizando metodologias OO e permitindo uma viso de como possvel empreg-los na prtica. 1.3 Objetivos Especficos Apresentar um resumo da metodologia OO e da UML. Analisar as vantagens de utilizao desta metodologia durante a fase de implementao de sistemas. Apresentar exemplos mostrando o emprego das tcnicas propostas.
10
Orientao a Objetos Devido grande dificuldade de desenvolver um sistema que se adapte facilmente s mudanas nas regras de negcio que ocorrem ao longo do ciclo de vida do software, este trabalho tem como principal objetivo descrever uma viso geral dos benefcios da utilizao de uma tcnica de modelagem baseada em objetos, mostrando os conceitos mais utilizados e como aplic-los, utilizando-se de uma linguagem de fcil compreenso, especialmente para aquelas pessoas que esto iniciando o estudo da OO. Portanto, o material aqui apresentado ir parecer bastante bvio para pessoas experientes em OO, mas certamente apresentar dicas importantes para aqueles que esto acostumados a desenvolver de forma procedural conceitos bsicos da OO. 2.1 Histrico A utilizao de OO para o desenvolvimento de sistemas no novidade, pois vem sendo estudada desde a dcada de 70. Entretanto, a prtica durante todo o ciclo de desenvolvimento, isto , da anlise at a codificao, s foi aplicada a partir da dcada de 80 por Booch. A partir da muitos trabalhos foram desenvolvidos por pessoas da rea que possuam a capacidade de influenciar outros profissionais a aplicarem este novo paradigma. Se por um lado isto facilitou a divulgao das tcnicas, por outro dificultou a especificao de um conceito nico, pois muitos desses desenvolvedores de renome criaram suas prprias notaes, dando origem a denominaes diferentes para um mesmo conceito. Aps esta fase inicial de desordem, buscou-se um concenso, o que reuniu grandes conhecedores da metodologia OO com o objetivo de criar uma linguagem unificada que pudesse ser utilizada de forma coerente. Eles criaram uma notao grfica, smbolos padres para a representao dos conceitos e driagramas que facilitassem o entendimento entre profissionais, o que deu origem aos conceitos de UML. Devido ao sucesso dessas tcnicas, grandes empresas como Oracle, IBM, Microsoft e HP montaram um consrcio e contriburam para a verso final de UML. e que desejam aplicar os
11
A tcnica foi logo reconhecida como padro pelo OMG(Object Managment Group), que o rgo principal fornecedor de diretrizes para o desenvolvimento de software. 2.2 Benefcios Agrupar os conceitos do mundo real e represent-los atravs de objetos um dos maiores benefcios oferecidos pela OO, pois para ns seres humanos se torna bem mais fcil a compreenso. Pode-se citar tambm como benefcios da OO: A Reutilizao de cdigo considerada a grande vantagem oferecida pela OO; Utilizao da mesma notao, durante todo o ciclo de vida do software, da anlise, projeto at a implementao;[Rumbaugh] Facilita o reaproveitamento de cdigo, pois temos objetos que se comportam formas semelhantes alm de permitir reduo no tempo de desenvolvimento; Herana torna o programa menor e facilita a manuteno. Utiliza-se as classes para implementar novas funcionalidades podendo-se herdar o comportamento (que est codificado) de outras classes anteriormente implementadas. Escalabilidade, que a capacidade de uma aplicao adaptar-se facilmente s exigncias de novos requisitos do sistema sem aumentar muito a sua complexidade e sem comprometer o desempenho. Para aumentar a escalabilidade a aplicao construda utilizando-se a composio de objetos e a troca de mensagens entre estes objetos. O encapsulamento no permite que seja feito o acesso direto ao estado interno de um objeto, isto , oculta e protege as informaes dos objetos. O acesso aos mesmos deve ser feito atravs das mensagens que o objeto pode receber. O programador no necessita conhecer o cdigo, precisa apenas da documentao dos objetos para que possa utiliz-los. A apropriao, que possibilita agrupar em classes os objetos com comportamento semelhante e estas classes podem ser agrupadas em hierarquias de herana , pode ser uma vantagem e tambm uma desvantagem. A vantagem podermos utilizar um agrupamento de objetos e fornecermos uma soluo para um problema. A desvantagem que estes objetos sero tratados em grupos e no de forma individual. de
12
2.3 Desvantagens da OO A apropriao, uma desvantagem por tratar de forma genrica diversos objetos. Isto nem sempre soluciona problemas de forma adequada, pois objetos similares so agrupados segundo uma classificao rgida. O problema que ao ocorrer uma mudana nos requisitos do sistema pode haver a necessidade de reagrupar estes objetos, o que geralmente no simples de ser feito. Quando se deseja classificar objetos necessrio que isto seja feito de forma precisa e inflexvel, pois no possvel utilizar regras dinmicas para classificao de objetos, isto , para a definio das classes. ao ocorrer uma mudana nos relacionamentos entre as classes, A apropriao traz o problema da fragilidade nas definies, isto outra desvantagem, pois pode-se ter que redefinir a hierarquia de classes. A fim de evitar tais problemas, deve-se realizar uma boa anlise e esquematizar o projeto buscando evitar tais problemas, embora isto requeira maiores prazos e investimentos. 2.4 Introduo abordagem OO A utilizao da Tecnologia OO j uma realidade nas empresas, entretanto no est sendo largamente empregada devido geralmente falta de profissionais com experincia no desenvolvimento das aplicaes e dificuldade de se formar estes profissionais. Alm disso, nem todas as ferramentas de bancos de dados suportam todos os conceitos de OO e as que existem so extremamente caras. Empresas que utilizam a OO muitas vezes se questionam da real vantagem de sua utilizao, pois devido falta de experincia, existe dificuldade em se estimar complexidade e prazos para o desenvolvimento, o que torna a tarefa de execuo mais rdua . 2.5 Principais Conceitos A abstrao de dados permite definir uma forma de representar objetos na OO. Os objetos so representados de forma abstrata para que se possa utiliz-los na soluo de um problema. O comportamento destes objetos especificado atravs de mtodos da sua interface. A abstrao de dados um conjunto de operaes e valores que especifica o comportamento de um objeto. O princpio do encapsulamento o que permite o ocultamento das informaes de um objeto e que alteraes na operaes desse objeto fiquem restritas sua classe.
13
2.5.1 Objetos So utilizados
para
representar
conceitos
do
mundo
real
ou
seja
informaes(estruturas de dados) e a forma como sero manipuladas(procedimentos) estas informaes. Um objeto composto de propriedades, comportamento e identidade e rene os conceitos de dados e procedimentos conjuntamente. - Propriedades: so as informaes que representam o estado interno e atual do objeto e que somente esto acessveis a outros objetos atravs de mensagens enviadas a eles. - Comportamento: so as operaes, implementadas atravs de mtodos que atuam sobre as propriedades do objeto. Os mtodos so executados ao se enviar uma mensagem solicitando a sua execuo. Em geral, a mensagem possui o mesmo nome do mtodo que ele executa. Os mtodos so declarados na interface do objeto. - Identidade Os dados so subdivididos em entidades distintas denominadas objetos. Cada objeto tem identidade prpria, mesmo que possua atributos idnticos. Estes objetos podem ser concretos(ex. um arquivo, uma bicicleta, um polgono) ou conceituais(ex. uma regra dentro de um sistema).
Mtodos do Objeto Atributos do Objeto
Figura 1 -Representao para um objeto
Podemos identificar com facilidade um objeto, como uma lpis, uma borracha e uma rgua. Este o conceito utilizado na OO, entretanto, tambm podemos considerar objeto um problema do mundo real ou uma entidade que pode ser modelada dentro do sistema e no somente os objetos conhecidos do mundo real.
14
A utilizao de objetos traz benefcios como: - a modularidade, pois o cdigo deve ser escrito independentemente do fonte de outros objetos e pode-se utilizar este objeto em outros sistemas. - o ocultamento das informaes, permitindo o acesso ao objeto somente atravs de mensagens ou mtodos declarados em sua interface pblica o que facilita a sua utilizao. A propriedade de ocultamento, que tambm pode ser chamada de abstrao de dados, permite que no seja necessrio o desenvolvedor saber como o objeto foi codificado, mas apenas conhecer os seus mtodos da interface para poder utiliz-lo. As mensagens enviadas aos objetos permitem a interao entre estes e aumentam a funcionalidade, permitindo implementar comportamentos mais complexos. A mensagem possui trs componentes bsicos: - o objeto ao qual se deseja enviar a mensagem, que chamado receptor; - o nome do mtodo que ser executado; - os parmetros(se existirem) necessrios para que o mtodo seja executado. Exemplo: Um objeto A deseja executar um mtodo de B. Neste caso, o objeto A envia uma mensagem para o objeto B, chamando o nome do mtodo e passando os parmetros necessrios para execuo do mesmo.
Objeto A
Objeto B
Mensagem
Figura 2 Representao para a passagem de mensagens entre objetos.
15
2.5.1.1 Mtodos Os mtodos implementam o comportamento de um objeto. O comportamento o modo como um objeto responde a uma mensagem recebida. O mtodo uma funo ou procedimento que definido em uma classe de objetos e usada para realizar operaes que alteram o estado interno de um objeto. As operaes de uma classe so os mtodos implementados na linguagem escolhida, podendo haver diversos mtodos para uma mesma operao. Ao chamar o mtodo, a linguagem de programao baseada em objetos o faz automaticamente baseando-se no nome da operao e na classe do objeto que est sendo utilizado para realizar a chamada. Ex.: Mtodo ReservarLivro(objeto:Livro); Poderemos ter no objeto Livro um mtodo ReservarLivro com os parmetros cdigo do Livro e data da reserva, que seria chamado da seguinte forma: Livro.ReservarLivro(10,07/10/2002);
Para se criar um objeto preciso termos um mtodo construtor e para destru-lo , um mtodo destrutor. Os construtores criam e inicializam uma nova instncia de um objeto, isto , alocam memria para o mesmo. Exemplo1: Considerando-se que temos definido anteriormente uma classe TLivro, o Livro := TLivro.Create(application); O destrutor libera a rea de memria que foi alocada no ato da criao do objeto. Exemplo2 : Livro.Free; 2.5.2 Classes Os objetos com construtor para criar um novo livro poder ser chamado da seguinte forma :
mesma
estrutura
de
dados(atributos)
mesmo
comportamento(operaes) so agrupados em uma classe. A classe descreve um conjunto infinito de objetos. Cada objeto uma instncia de sua classe e possui valor prprio para cada atributo.
16
O conceito de classe serve para identificar objetos semelhantes, por isso pode-se dizer que este conceito relativo ao que voc deseja considerar como uma classe. Pode-se dizer que Livro, carro, cavalo, computador fazem parte da classe Patrimnio, se estivssemos pensando em termos de bens com valores financeiros. Entretanto, estes mesmos objetos podem ser agrupados em classes diferentes como Livros,Imveis, Animais, Automveis , Equipamentos. Representao grfica da classe Livro
Nome da Classe
Atributos da Classe
Livro Ttulo : String Assunto : String Autor : String Editora : String Seo : String Adiciona() Remove() ObtemTitulo() ObtemAssunto() ObtemAutor() ObtemSecao()
Operaes da Classe
Atributos : Ttulo, Autor, Assunto, Editora, Seo Operaes : Adiciona(), Remove(),ObtemAutor.
Figura 3 - Representao de uma classe

Podemos considerar que as classes so objetos, mas como no so objetos do mundo real, devemos cham-las de metaobjetos. Os metaobjetos descrevem objetos, que possuem suas prprias classes, que so descritas por suas metaclasses. As classes possuem atributos, que armazenam informaes para novos objetos criados a partir de uma classe e possuem um valor comum para toda uma classe de objetos. Autor, Assunto, Editora, Preo so atributos da classe Livro. As operaes de uma classe so funes que so executadas sobre ela prpria. As instncias de uma classe herdam todas as operaes da classe.
17
Podemos citar como exemplo
a criao de uma nova instncia da classe, que
necessariamente deve ser uma operao da classe a partir da qual ser criada uma nova instncia. Esta operao no poderia ser da nova classe instanciada pois o objeto ainda no foi criado. Podemos ter uma mesma operao que se aplica a classes diferentes. Este tipo conhecida como operao polimrfica, pois toma formas diferentes em classes diferentes. As operaes de uma classe so implementadas atravs dos mtodos. No exemplo acima, temos a operao ObterDadosdaPessoa, que ser um mtodo da classe Pessoa. Esta operao poder ser implementada com o mesmo nome nas classes usurio e funcionrio, que sero subclasses da classe Pessoa, entretanto, tero formatos diferentes em cada uma dessas classes. Classes Concretas e Classes Abstratas Uma classe abstrata no poder jamais ser instanciada diretamente, somente suas subclasses, desde que estas sejam concretas. As classes abstratas so utilizadas para encapsular classes que participam da mesma associao ou agregao e para definir mtodos que sero herdados pelas subclasses, Uma classe abstrata possui operaes abstratas, que so mtodos que sero implementados nas subclasses concretas. As classes concretas so instanciveis diretamente. A classe Pessoa pode ser implementada como uma classe abstrata. Classes concretas no possuem operaes abstratas, entretanto, a classe poder ser refinada e se tornar uma classe abstrata, bastando que para isto acrescentemos um mtodo abstrato na subclasse. Uma classe abstrata poder ser refinada em uma classe concreta, desde que sua subclasse no possua mtodos abstratos. As classes so descritas graficamente em um diagrama de classes.
2.5.3 Herana o compartilhamento de atributos e operaes entre classes baseado em um relacionamento hierrquico. A herana o mecanismo da OO que possibilita a
18
reutilizao das propriedades de uma classe na definio de outras classes e permite tambm a construo de sistemas reutilizando componentes existentes. Podemos definirmos uma classe, chamada subclasse, que herda a definio de uma classe pr-existente, chamada superclasse. A subclasse herdar todas as operaes da superclasse, podendo tambm ser implementados outros mtodos para esta nova classe. Podemos exemplificar a herana da seguinte maneira: A subclasse usurio herda as caractersticas da superclasse Pessoa. Neste caso, a classe usurio herdar todo o comportamento e o estado de sua superclasse. Na classe usurio pode-se incluir novos mtodos ou mesmo redefinir mtodos da superclasse Pessoa. Os mtodos que forem adicionados iro tornar a subclasse cada vez mais especializada. As alteraes que ocorrerem na superclasse iro se refletir na subclasse, conseqentemente, podero comprometer a implementao de suas subclasses. Existem linguagens OO que permitem a herana mltipla que consiste em fazer com que uma subclasse herde caractersticas de mais de uma superclasse. Ex.: Define-se uma classe geral Pessoa e posteriormente refina-se esta classe em subclasses como usurio, Professor, Funcionrio. A classe Pessoa possui operaes genricas como InserirNovaPessoa(), AlterarDadosPessoa(), ObterDadosPessoa() . A classe usurio herda todas os atributos e operaes da classe Pessoa, porm pode-se acrescentar outras operaes e outros atributos que sero somente da classe usurio e das subclasses dela derivada, como exemplo CadastrarNovoUsurio (). Cada objeto conhece sua classe atravs da herana.
Pessoa
Funcionrio
(from Use Case View)
Usurio
Figura 4 Representao de Herana
19
2.5.4 Polimorfismo A aplicao do polimorfismo torna o cdigo mais legvel, mais enxuto e facilita a manuteno dos sistemas pois permite que se utilize mtodos com o mesmo nome para objetos diferentes. A mesma operao, que foi implementada atravs da codificao de um mtodo, pode atuar de modo diferente em classes diferentes. Isto significa que objetos diferentes podem responder a uma mesma mensagem de forma diferente. Ex.: Ao tentarmos inserir uma nova pessoa, precisaramos de trs mtodo diferentes, um para usurio, um para Professor e um mtodo para Funcionrio. If Pessoa then {mtodo} If Pessoa = Professor then Pessoa.InsereProfessor else if Pessoa = usurio then Usurio.InsereUsurio else if Pessoa = Funcionrio then Funcionrio.InsereFuncionrio Professor.InsereProfessor; {chamada do mtodo} Usurio.InsereUsuario; Funcionrio.InsereFuncionario; Professor, Usurio e Funcionrio so instncias de objetos das respectivas subclasses Professor, Usurio e Funcionrio. Utilizando-se o polimorfismo, teremos trs classes e apenas um mtodo Insere: Pessoa.Insere; {mtodo} Professor.Insere;{chamada do mtodo} Usurio.Insere; Funcionrio.Insere;
20
O exemplo mostra que a operao Insere pode atuar de forma diferente em objetos diferentes. A utilizao do polimorfismo no facilita a reutilizao de cdigo, mas diminui o nmero de linhas de forma significativa quando temos muitos objetos com comportamentos ligeiramente diferentes. Este conceito no exige que se conhea a implementao do mtodo insere para cada objeto. O tipo de polimorfismo acima um exemplo de mtodos com implementao diferente com o mesmo nome em classes diferentes. Existe outro tipo de polimorfismo, chamado polimorfismo paramtrico ou sobrecarga de operadores, onde podemos ter mtodos com o mesmo nome, implementados na mesma classe, mas que diferem apenas pelo nmero de parmetros que utilizam. Algumas linguagens OO implementam o polimorfismo com ligao(binding) dinmica ou com ligao esttica.
21
A ligao dinmica feita em tempo de execuo e poder ser alterada durante a execuo do programa, entretanto, esta facilidade torna a execuo do sistema mais lenta. A ligao esttica feita em tempo de compilao ou interligao (linking) no podendo mais ser alterada no decorrer da execuo do programa.
22
Tcnicas de Modelagem Orientadas a Objetos 3.1 Histrico A necessidade de uma tcnica para desenvolvimento de sistemas OO surgiu medida que as linguagens de programao OO tambm se desenvolviam. A linguagem inicial OO foi a Simula, utilizada na dcada de 80. A partir da surgiram outras linguagens, como C++ e Smaltalk. Muitos mtodos foram criados para dar apoio ao desenvolvimento OO: - O mtodo Booch Criado por Grady Booch,permitia que o sistema fosse analisado utilizando-se uma srie de diagramas, que eram construdos atravs de diferentes vises do sistema. Estas vises eram construdas atravs de micro e macro anlises dos processos do sistema, utilizando para isso um processo interativo. Por ser um mtodo muito extenso, no se tornou amplamente utilizado. - TMO - A Tcnica de Modelagem a Objetos (OMT - Object Modeling Tecnique), um mtodo desenvolvido na General Eletric onde James Rumbaugh (um dos criadores da UML), havia trabalhado. Era um processo voltado para testes. O sistema era descrito por vrios modelos: o modelo para objetos, o modelo dinmico, o modelo funcional, e o modelo use-case. Cada modelo complementava o outro dando uma descrio completa do sistema. O mtodo OMT tambm era muito prtico nas descries de como fazer um desenho de sistema, levando em conta a ocorrncia e as relaes entre os sistemas; - OOSE/Objectory: formulado por Ivar Jacbson ,os mtodos OOSE e Objectory foram construdos sob o mesmo ponto de vista bsico. O mtodo OOSE uma viso de Jacobson de um mtodo Orientado a Objetos. O mtodo Objectory usado para construo de vrios sistemas (como o das telecomunicaes para a Ericsson, ou financeiro para as empresas de Wall Street). Ambos os mtodos se baseiam no uso de caixas, que define as caractersticas principais do sistema vistas pelo ator externo. Essas caixas so usadas em todas as fases do desenvolvimento do sistema; - Fuso: O mtodo de fuso vem da Hewlett-Packard. Foi chamada de segunda gerao de mtodos porque baseada nas experincias de muitos dos mtodos iniciais. Herdou uma srie de importantes idias usadas j anteriormente. Incluiu tcnicas para a especificao das operaes e interaes entre os objetos. Este mtodo usa um grande nmero de modelos de diagramas;
23
- Coad/Yourdon: Este mtodo, tambm conhecido como OOA/OOD foi um dos primeiros mtodos usados na anlise e projeo da orientao a objetos. O mtodo era prefervel por ser simples e facilmente compreensvel e porque trabalhava bem a terminologia da linguagem orientada a objetos. Contudo, a notao e o mtodo eram apenas teis em sistemas limitados. Conseqentemente, muito pouco usado. Cada um desses mtodos tinha sua prpria notao (os smbolos e desenhos das orientaes), processos (as atividades eram executadas em diferentes partes do desenvolvimento), e ferramentas (a caixa de ferramentas que dava suporte e notao para o processo). Isso tudo fazia da escolha do mtodo mais adequado uma deciso muito importante, e freqentemente levava a longas discusses sobre qual mtodo era o melhor, o mais avanado e o correto para cada projeto especfico. No chegando a ponto nenhum, j que cada mtodo tinha seus pontos fortes e fracos, desenvolvedores experientes escolhiam um mtodo e adaptavam boas idias de outros. Para evitar esses problemas que foi criada a UML. 3.2 Diferenas em Relao Anlise estruturada A anlise estruturada baseia-se em processos e funes (Yordon). A nfase na especificao e decomposio da funcionalidade do sistema. Caso os requisitos mudem pode ser necessria uma grande reestruturao no sistema. Na anlise OO, procuramos decompor o problema identificando os conceitos que pertencem ao domnio e documentar estes conceitos em um modelo conceitual. A TMO busca primeiro identificar os objetos contidos no domnio da aplicao e depois em estabelecer os procedimentos relativos a eles. Durante a programao, a herana da estrutura de dados e do seu comportamento permite o compartilhamento por diversas subclasses sem redundncias. Logo, o compartilhamento de cdigo devido utilizao da herana representa uma das principais vantagens das linguagens baseadas em objetos.
24
UML 4.1 Histrico O desenvolvimento da UML - Unified Modeling Language renomados desenvolvedores
teve incio em 1994 pelos
Grady Booch e James Rumbaugh, da Rational Software
Corporation. Eles buscavam unir os seus mtodos(Booch e OMT2) com objetivo principal de criar um mtodo novo, o Mtodo Unificado (Unified Method). Em 1995, Ivar Jacobson (desenvolvedor dos mtodos OOSE e Objectory), uniu-se a eles. A Rational Software comprou a Objective Systems, companhia que distribua o Objectory, e ento os trs principais pesquisadores empenharam-se na criao do que se tornaria conhecido como Unified Modeling Language , a linguagem de modelagem unificada - UML. Surgiram diversas verses de teste da UML para utilizao dos desenvolvedores que faziam uso da OO. A partir da, muitas foram as sugestes para melhorar a linguagem. A verso 1.0 da Uml foi oficialmente lanada em Janeiro de 1997. A UML uma linguagem padro de modelagem, ou seja, uma linguagem cujo vocabulrio e regras tm seu foco voltado para a representao conceitual e fsica de um sistema. Entretanto, nenhum modelo inteiramente suficiente. Sempre so necessrios vrios modelos, conectados entre si, para tornar possvel entender qualquer aspecto, ainda que o sistema seja simples. No caso de sistemas que fazem uso intenso de software, torna-se essencial uma linguagem capaz de abranger as diferentes vises relacionadas arquitetura de linguagem e de como essa arquitetura evolui ao longo do ciclo de vida de desenvolvimento de um sistema complexo. do software. A UML uma linguagem para visualizao, especificao, construo e documentao
25
4.2 O que a UML Inicialmente, necessrio entender as diferenas entre Mtodo e Linguagem de Modelagem. Um mtodo no o mesmo que a linguagem de modelagem. Um mtodo uma forma, uma regra para a estruturao de pensamentos e aes. Um mtodo diz ao usurio o que fazer, como fazer, quando fazer, e por que isso feito.Os mtodos dispem de modelos que so usados para descrever algo e para mostrar os resultados do mtodo utilizado. Um mtodo difere de uma linguagem de modelagem principalmente porque a linguagem, como o caso da UML, no possui um processo ou instrues para o que fazer, como fazer, quando fazer e por que algo feito. A estruturao de nossos pensamentos demonstrada atravs da construo de um modelo, que possui um propsito para que se saiba como utiliz-lo. Entretanto, para expressarmos um modelo fazemos uso de uma linguagem de modelagem, que uma notao, que possui smbolos para a construo do modelo desejado. Alm disso so especificadas regras sintticas, semnticas e pragmticas que definem como usar estes smbolos. As regras sintticas esclarecem como os smbolos devem ser e como combin-los na linguagem de modelagem. A sintaxe define como agrupar, em que seqncia e de que forma usar estes smbolos. Comparando linguagem humana, como falar, como formar as frases, ou seja, como agrupar estas palavras para dar sentido uma orao. As regras semnticas indicam o significado de cada smbolo e como interpret-lo. As intenes dos smbolos so definidas pelas regras pragmticas para que sejam compreensveis s pessoas. O entendimento dessas regras nos permite utilizarmos bem uma linguagem de modelagem. Podemos comparar um escritor que deseja descrever uma estria em linguagem comum, sendo esta apenas uma ferramenta que o escritor deve dominar e ficando a cargo do autor escrever uma boa histria. Portanto, devemos lembrar que a UML fases. no um mtodo de desenvolvimento de sistemas, mas apenas uma linguagem que pode e deve ser usada em todas as suas
26
4.3Vises Mostram os diferentes aspectos do sistema que est sendo modelado, consiste em uma abstrao apoiada em Diagramas. Ao definirmos as vises, especificamos os aspectos particulares do sistema que cada uma mostrar, enfocando diferentes nveis de abstrao e ento teremos uma figura completa do sistema. Podem existir alguns casos de sobreposio entre os diagramas, o que significa que um destes pode fazer parte de mais de uma viso. Os diagramas compem a viso dos modelos de elementos do sistema.
Figura 5 Diferentes Vises do Sistema

As vises tambm podem servir de ligao entre a Linguagem de Modelagem e o mtodo de desenvolvimento escolhido. As vises so complementares entre si. Por exemplo, um caso de uso envolver a colaborao de algumas classes que foram definidas. Determinado agrupamento de classes ser empacotado em um nico componente programa fonte. Um conjunto de programas fontes sero compilados e daro origem a um programa executvel que, por sua vez, ser executado em determinado n da rede. Todas essas informaes reunidas especificam a arquitetura do sistema.
27
Caso de Uso
Classe
Atributo Classe Classe Classe Classe Atributo
Desenho
Operao
Atributo
Atributo
Operao
Atributo
Operao Operao
Operao
Componente
Fonte
Fonte
Fonte
Fonte
OCX
EXE C
Processo
Distribuio
Servidor NT
Cliente Win
Figura 6 Representao de uma viso do sistema.

28
4.4 Modelo de Elemento So modelos estruturais, isto , so os substantivos utilizados em modelos da UML. Atualmente, a UML possui diversos modelos, sendo alguns deles : classes, associaes, generalizaes, relacionamentos, interface, colaboraes, casos de uso, componentes, ns, classes, objetos, estados, pacotes. Cada modelo de elemento possui uma representao grfica distinta. Um mesmo elemento pode existir em diversos tipos de diagramas, porm , existem regras para definir que elementos podero ser mostrados em cada tipo de diagrama. Os relacionamentos tambm so modelos de elementos e so usados para conectar outros modelos de elementos entre si. 4.4.1 Classes Um software OO utiliza-se do conceito de classes de objetos e no de estruturas procedurais. As classes so conjuntos de objetos com as mesmas propriedades(atributos), apresentam o mesmo tipo de comportamento(operaes) e Uma classe a
relacionam-se(associaes) da mesma maneira com outros objetos.
descrio de um tipo de objeto. Todos os objetos so instncias de classes, onde a classe descreve as propriedades e comportamentos daquele objeto. Objetos s podem ser instanciados de classes. As classes so representadas no Diagrama de Classes, que tambm mostram atributos e operaes de uma classe e as restries no que se refere comunicao com outros objetos. O Diagrama de classes salienta definies para classes de software e de interfaces de uma aplicao. Os mtodos de uma classe implementam a sua funcionalidade. So usados para enviar mensagens para outras classes do diagrama. Exemplo: classe Pessoa
Pessoa Nome : String DataNasc : Data Cadastro() Remove() ListaPessoas()
Figura 7 Representao de uma classe e seus mtodos.

29
Objetos A UML utiliza-se do conceito de OO para definir um objeto e sua representao feita atravs de uma classe. Deve-se usar o nome do objeto sublinhado, para representar uma instncia da classe. Estado O estado uma propriedade de um objeto que representa a condio atual deste objeto. O estado de um objeto geralmente alterado por eventos que executam operaes no objeto e que alteram os seus atributos. O estudo dos estados de um objeto permite que se determine os comportamentos possveis do mesmo. Podemos representar para uma classe de objetos um diagrama de Estados. Este tipo de diagrama demonstra o comportamento de uma nica classe de objetos, visto que os objetos de uma classe possuem o mesmo comportamento. 4.4.2 Casos de Uso Os casos de uso so utilizados para identificar os requisitos funcionais que o sistema deve atender, mas no especificam explcitamente estes requisitos. A finalidade ao se especificar um caso de uso melhorar a compreenso dos requisitos do sistema, pois um documento feito em forma de narrativa que descreve os processos do domnio. Um caso de uso descreve a sequncia de eventos executados por um ator, isto , processos do negcio que representam os casos de utilizao de um sistema efetuados por um agente externo(o ator, que o usurio do sistema). Os Modelos de casos de uso iro conter os diagramas de caso de uso do sistema. Os casos de uso so agentes externos ao sistema e no se deve esperar correlao entre eles e as classes do sistema. Os casos de uso no representam passos individuais nem operaes ou transaes. No podemos ter um caso de uso que represente uma sequncia como Imprimir comprovante de Emprstimo, Pagar Atraso de Devoluo. O caso de uso descreve uma seqncia do incio ao fim de um grande processo, que possui muitos passos ou transaes. Podemos, entretanto, dividir um caso de uso extenso em subcasos, os quais sero casos de uso abstratos, podendo estes chegarem a descrever passos individuais, porm isto no a regra. Para a identificao dos casos de uso podemos fazer uso de brainstorming e revises de documentos dos requisitos do sistema. O ideal comearmos inicialmente identificando
30
os atores e para cada ator identificar os processos que so iniciados por ele ou dos quais o ator participa. Outra forma de identificar os casos de uso identificar os eventos externos aos quais o sistema deve responder e relacion-los a atores e a casos de uso. Atores Um ator um tipo (uma classe), e no uma instncia.. Um caso de uso sempre inicializado por uma mensagem enviada por um ator, o que chamamos de estmulo. Atores so entidades externas ao sistema que o estimulam com eventos de entrada ou que recebem algo do mesmo. Atores so descritos de acordo com o papel desempenhado em relao ao sistema. Um mesmo ator poder desempenhar diversos casos de uso. Um ator pode ser um ser humano, um sistema externo que utilize informaes do sistema atual. Quando um caso de uso executado, ele envia mensagens para um ou mais atores. Precisamos identificar o que externo e o que interno a um sistema, alm de
especificar as suas funcionalidades. Podemos dizer que as fronteiras do sistema so especificadas pelo software/ hardware de um dispositivo ou sistema de computador, um departamento ou organizao. Os atores representam somente o ambiente externo do sistema. Dessa forma, a definio do que externo ou no ao sistema relativa. Se escolhermos a biblioteca como a fronteira do sistema, ento o funcionrio est interno ao sistema e o usurio ser um recurso externo do sistema, isto , um ator. Se escolhermos o software como sistema, ento funcionrio e Usurio sero agentes externos. Usaremos esta ltima opo para representar os exemplos. Atores tambm podem ser definidos como ativos ou passivos. Um ator ativo aquele inicializa o estudo de caso, enquanto que o passivo nunca inicia um estudo de caso, mas apenas participa de outros usos de caso. Quando se identifica um ator, est se estabelecendo uma entidade interessada em usar e interagir com o sistema.. Apesar do ator no ter inicializado o caso de uso, o ator ir em algum momento se comunicar com um. O ator recebe um nome que reflita seu papel no sistema. Em UML, existem classes do tipo <<ator>>, e o nome da classe o nome do ator (como dito acima, refletindo seu papel), uma classe ator, como outra qualquer, possui atributos e mtodos, bem como documentao prpria descrevendo o ator.
31
Funcionrio
Figura 8 - Representao de Ator.
A UML no especifica um formato padro para a descrio de casos de uso, entretanto, no decorrer do uso destes casos de uso surgiu uma estrutura padro como mostrada a seguir. Inicialmente apresentamos informaes resumidas, seguindo o formato abaixo: Caso de Uso: Nome do caso de uso O nome do caso de uso deve iniciar com um verbo Reservar Livro para enfatizar que um processo. Atore(s) : Lista de atores, indicando qual ator inicia o caso de uso Finalidade : Objetivo do caso de uso Viso Geral: descrio resumida do caso de uso Tipo : primrio ou essencial Exemplo : Um usurio solicita o emprstimo de um livro, o funcionrio ir efetuar a tarefa de realizar emprstimo para o usurio. Exemplo1 : Funcionrio: Registrar Emprstimo
RegistraEmprstimo Funcionrio
Figura 9 - Representao do Caso de Uso Registrar Emprstimo

32
Descrio do caso de uso Registrar Emprstimo Seqncia Tpica de Eventos Caso de Uso : Registrar Emprstimo Aes do Ator 1. O funcionrio recebe do usurio livro(s) que deseja levar emprestado. 2. O funcionrio registra no sistema os 3. O sistema emite dados identificando que dados do livro para verificar se possvel o realizar o emprstimo 4. Considerando que o livro livro para emprstimo (ou para consulta). para 5. O sistema emite confirmao de que o Resposta do Sistema
emprstimo, o funcionrio registra os dados usurio est apto a obter o emprstimo. do usurio. 6. O funcionrio confirma o emprstimo. 7. O sistema registra os dados e emite comprovante de emprstimo para o usurio com dados do usurio, dados do livro e a data da devoluo.
4.4.3 Componentes So partes fsicas e substituveis de um sistema, que proporcionam a realizao de um conjunto de interfaces. Em um sistema, encontram-se diferentes tipos de componentes que so artefatos do processo de desenvolvimento, como os arquivos de cdigo-fonte e dlls. Tipicamente, representam o pacote fsico de elementos lgicos diferentes, como classes, interfaces e colaboraes. Graficamente so representados como retngulos com abas.
dll Pessoa
Figura 10 Representao de Componente.
33
4.4.4 Colaboraes Definem as iteraes, o comportamento cooperativo resultado da soma das funes dos elementos. Assim, as colaboraes contm dimenses estruturais e comportamentais. Graficamente so representadas como elipses tracejadas com seu nome.
4.4.5 Pacote O pacote utilizado para a agrupar elementos que esto relacionados. Um pacote um componente puramente conceitual, ou seja, s existe em tempo de execuo. Graficamente representado como diretrios com guias. O pacote proprietrio de elementos como tipos e classes. Para um modelo conceitual devemos fazer com que todos os seus elementos pertenam a um mesmo pacote. Podemos, por exemplo, definir pacotes que agrupem funes de uso geral dentro do sistema e cham-lo Geral.
pk_Pessoa
pk_Aluno
Figura 11 Representao de Pacote.
4.4.6 Interface uma coleo de operaes que especificam servios de uma classe ou componente. Ou seja, uma interface representa todo o comportamento externamente visvel do elemento. Pode representar todo o comportamento de uma classe ou componente, ou apensa parte desse comportamento. A interface define um conjunto de especificaes de operaes, mas nunca um conjunto de implementaes de operaes.Uma interface raramente aparece sozinha.
34
Emprstimo
<<implementa>>
<<Interface>> Inicializa InicializarExecuo()
Figura 12 - Representao de Interface
4.5 Relacionamentos Os relacionamentos interligam classes e objetos, mostrando as relaes existentes entre estes. Estes relacionamentos entre as classes so mostrados no diagrama de classes. Existem basicamente trs grupos de relacionamentos que so as associaes, generalizaes, as dependncias e os refinamentos. 4.5.1 Associaes So ligaes entre classes, isto , entre objetos e suas classes.Utilizando o conceito de UML, podemos dizer que existe uma associao quando dois objetos de tipos diferentes existem independentemente um do outro e encontram-se estreitamente ligados por um relacionamento parte-todo.As associaes guardar informaes de relacionamentos so usadas quando temos interesse em entre conceitos. Podemos citar um as
relacionamento entre usurio e livro. Precisamos saber qual instncia de livro que foi emprestado est associada a uma instncia de usurio que levou este livro. A partir desta associao poderemos listrar por exemplo, quantos livros o usurio tomou emprestado, quais livros esto emprestados, qual a data do emprstimo e da devoluo. Papis Cada extremo de uma associao um papel, que pode ter um nome, uma expresso de multiplicidade e uma opo de navegabilidade. A multiplicidade demonstra quantas instncias do tipo A podem estar associadas a um tipo B. Por exemplo , a uma instncia de usurio podemos ter associadas muitas instncias de livro. No se deve desperdiar muito tempo buscando associaes. O mais importante na fase de anlise descobrir os conceitos do domnio do problema. Posteriormente, na fase de projeto, definiremos quais associaes possuem a necessidade de implementao.
35
Existem diversas maneiras de implementar associaes em uma linguagem orientada a objetos. A forma mais comum usar atributos que apontam para uma instncia da classe associada.
Emprstimo
Contm
1..*
ItensdoEmprstimo
Figura 13 Representao de Associao

4.5.2 Agregao A agregao uma forma especial de associao. Usando a agregao, indicamos que o relacionamento entre classes do tipo parte-todo. Um computador um exemplo de agregao, pois formado por um conjunto de outros objetos, como teclado, mouse, monitor, cpu. Identificamos a agregao atravs de questionamentos do tipo consiste de, contm, parte de.
Acervo
Livro
Figura 14 Representao de Agregao
4.5.3 Generalizaes/Especializaes
A relao deste tipo ocorre quando possvel agruparmos duas ou mais classes em uma nica classe genrica. A generalizao um relacionamento entre um elemento mais geral e um mais especfico. O mais especfico contm informaes adicionais.
Exemplo Classe Usurio e Classe Funcionrio Podemos agrup-las em uma nica classe chamada Pessoa(classe genrica), que uma generalizao da subclasses Usurio e Funcionrio(classes especializadas). Como iremos utilizar a herana na implementao destas duas classes derivadas, ento estas herdaro todo o comportamento e as propriedades da superclasse Pessoa. Podemos
36
criar uma generalizao quando houver pelo menos uma propriedade que diferencie as classes que sero especializadas. No exemplo de Usurio e Funcionrio, podemos dizer que o usurio ter caractersticas como Curso e o Funcionrio poder exercer uma Funo, fato que o diferencia de usurio. Exemplo de generalizao Pessoa/Usurio/Funcionrio.
Pessoa
Funcionrio
Usurio
Figura 15 Representao de Generalizao
4.5.4 Composio/ Decomposio A composio tambm conhecida como agregao e permite que objetos sejam agregados para compor outros objetos ou componentes. Instncias de objetos de uma classe so agrupadas para formar novas classes. Os componentes fazem parte do agregado. Podemos ter agregados que so compostos por outros agregados. Os componentes de um agregado podero ou no existir fora do agregado. A agregao diferente da generalizao porque relaciona-se a instncias de classes de objetos, sendo chamada de relacionamento-e ou relacionamento parte-de. A generalizao se relaciona a classes e chamada relacionamento-ou ou relacionamento tipo-de. A generalizao torna um objeto instncia da superclasse e uma instncia da subclasse. Uma universidade uma agregao de seus vrios departamentos, entretanto no uma agregao de seus usurios pois estes so objetos independentes. Uma associao no um fluxo de dados, nem uma conexo de objetos
37
O contrrio, a decomposio, mostra que um objeto composto por instncias de outras classes. Exemplo de composio/decomposio
Acervo
Livro
Figura 16 Representao de Composio

4.5.5 Dependncia usada para ligar dois modelos de elementos, onde um depende de outro. um tipo de relacionamento onde um elemento dependente e o outro independente. Uma mudana no elemento independente afeta o dependente. Podemos exemplificar a dependncia com um pacote pk_Aluno que depende, no de forma estrutural, de uma pacote fornecedor, o pacote pk_Pessoa. A dependncia pode ocorrer entre quaisquer tipos de elementos, desde que o dependente seja do mesmo tipo do independente. 4.5.6 Mecanismos Gerais Fornecem informaes extras, comentrios ou semntica sobre cada elemento do modelo. 4.5.6.1 Nota A nota apenas um smbolo para representar restries e comentrios anexados a um elemento. Geralmente usa-se uma nota para aprimorar os diagramas. Graficamente representada por um retngulo com um dos cantos com uma dobra na pgina.
Nota
Figura 17 Representao de Nota 4.5.6.2 Ornamentos

38
Servem para acrescentar um significado e so adicionados aos modelos de elementos. Podemos ornamentar um elemento ao adicionarmos algo em sua representao para diferenci-lo de outro semelhante. O nome de um tipo de elemento pode ser representado em negrito para se diferenciar de sua instncia, que escrito sublinhado. Em um relacionamento, podemos representar sua multiplicidade e desta forma identificar quantas instncias de um tipo podem fazer parte deste relacionamento.
:Livro
Contm
1..*
:ItensdoEmprstimo
Figura 18 Representao de um ornamento

Ao representarmos a instncia da classe Livro, utilizamos :Livro(dois pontos e
sublinhado) para diferenciar a instncia da classe Livro. 4.6 Diagramas
A UML representa as diferentes vises do sistema atravs dos diagramas. Devido ao fato dos sistemas apresentarem uma estrutura esttica e um comportamento dinmico, existem diagramas especficos para representar estes modelos do sistema. A estrutura esttica do sistema representada pelo diagrama de classes e pelo diagrama de objetos, incluindo os relacionamentos existentes entre as classes. A estrutura dinmica, que representa os aspectos do sistema que sofrem modificaes ao longo do tempo, descrita atravs dos diagramas de seqncia, de colaborao, de estado e de atividade. necessrio representar tambm as transformaes nos valores dos dados de um sistema, que so os aspectos funcionais do sistema. Para represenar este modelo funcional, a UML dispe dos diagramas de componente e de execuo.
39
Os diagramas de use case so utilizados para especificar os requisitos do sistema. Como os atores e os use cases so classes, eles tambm possuem associaes(entre use case e ator) e generalizaes.
4.6.1 Diagramas de Iterao Criados na fase de projeto, estes diagramas so utilizados em UML para mostrar como so passadas as mensagens para que ocorra interao entre os objetos e estes cumpram suas tarefas. Podemos utilizar dois modelos de diagramas, os de Seqncia e os de Colaborao. 4.6.1.1 Diagramas de Seqncia Os diagramas de seqncia so criados na fase de anlise e auxiliam na construo do sistema desejado. Ilustram os eventos gerados pelos atores e as operaes que devem ser executadas. Descrevem o comportamento do sistema, que so informaes so dinmicas, isto , o que ele faz , no como faz,. A criao destes diagramas deve ser feita aps a concluso dos casos de uso pois dependem diretamente dos mesmos. O diagrama de seqncia abaixo mostra uma seqncia de eventos dentro de um caso de uso, os atores externos que interagem com o sistema, o sistema e os eventos do sistema que so gerados pelos atores.
40
Registrar Emprstimo :Funcionrio :Sistema
EntrarDadosLivro(CdigoLivro) Repetir para cada Livro
DadosdoLivro()
RegistrarEmprstimo()
Texto explicativo Sobre a lgica
Eventos do sistema(dis param uma d
Figura 19 - Diagrama de seqncia

O evento do sistema um evento externo de entrada gerado por um ator para um sistema. Um evento inicia uma operao de resposta do sistema. Uma operao a execuo de uma operao do sistema em resposta a um evento do sistema.Craig Larman[1]. 4.6.1.2 Diagramas de Colaborao So descritos no formato de grafos ou redes e mostram as interaes que ocorrem entre instncias de objetos(no modelo de objetos) e entre instncias de classes(no modelo de classes).
1: EntrarDadosLivro(CdigoLivro) 3: RegistrarEmprstimo() :Funcion rio 2: DadosdoLivro() :Sistema
Figura 20 - Diagrama de Colaborao

41
4.6.2Diagrama de Casos de Uso Os requisitos funcionais de um sistema so representados utilizando-se este tipo de diagrama. A representao feita em funo de atores externos, use-cases e o domnio do sistema modelado. Conforme dito, os atores iniciam um evento do sistema e representam o papel de uma entidade externa ao sistema, podendo ser um usurio, outro software ou um hardware. O use-case a seqncia de aes que dispara um evento do sistema. As associaes conectam atores e use-cases, que so classes, podendo se relacionarem inclusive com generalizaes.
Funcionario
RegistraEmprstimo
SolicitaEmprstimo
Usuario
Figura 21 Representao para um Diagrama de Casos de Uso

4.6.3 Diagrama de Classes Demonstram especificaes para as classes, suas associaes, atributos e operaes. Devem ser construdos aps a concluso dos diagramas de interao e do modelo conceitual, pois a partir do diagrama podemos identificar as classes necessrias e o modelo conceitual permite identificar os atributos . Devemos modelar diversos diagramas de classes para um mesmo software, podendo haver repetio de uma ou outra classe em diagramas diferentes.
42
Pessoa
Funcionrio
(from Use Case Vi ew)
Usurio
(from Use Case Vi ew)
Figura 22 Representao para Diagrama de Classes
4.6.4 Diagrama de Objetos uma variao do diagrama de classes, inclusive utiliza-se da mesma notao, exceto que sublinha o nome da classe para identificar que demonstra instncias de objetos e suas associaes.
43
Pessoa
Pedro:Funcionrio Nome : Pedro da Silva DataAdmisso : 20/09/1997
Maria:Usurio Nome : Maria dos Santos Idade : 12 anos DataNascimento : 11/07/1990
Figura 23 Representao para um Diagrama de Objetos
4.6.5 Diagrama de Estados O estado a situao atual de um objeto, o valor de seus atributos e de seus relacionamentos com outros objetos. O estado a situao do objeto dentro de um intervalo entre dois eventos recebidos por ele(o objeto). Entretanto, nem sempre todos os atributos de um objeto so alterados por um evento. A mudana de estado de um objeto devido ao novo evento chamada de transio. O Diagrama de estados representa a sequncia de eventos e o consequente estado do objeto obtido aps o objeto responder a estes eventos. Este diagrama feito para descrever o comportamento de classes de objetos do sistema, visto que , por herana todos os objetos de uma classe possuem o mesmo comportamento. Pode tambm ser utilizado outros elementos como tipos(conceitos ) e para descrever a seqncia de eventos dos casos de uso. Devemos implementar este tipo de diagrama apenas para as classes que possuem um nmero conhecido e definido de estados e que possuem o comportamento afetado pelas alteraes dos diferentes estados.
44
Figura 24 Representao para um Diagrama de Estados

4.6.6 Diagrama de Atividades utilizado com o objetivo de demonstrar passo-a-passo, para uma operao especfica do sistema, o fluxo de atividades realizadas. Representam os resultados de uma ao(mtodo) sobre uma instncia de um objeto. Este diagrama deriva do diagrama de estados, com o diferencial que para representar as aes(atividades) para a mudana dos estados de um objeto. Podemos representar as interaes, incluindo como, quando e onde as atividades so executadas por este diagrama.
Figura 25 Representao para um Diagrama de Atividades

45
4.6.7 Diagrama de Componentes Possibilita representar os componentes de software e as dependncias existentes entre eles, incluindo a representao da estrutura do cdigo gerado. Representam os tipos definidos, como arquivos implementados em um ambiente de desenvolvimento, entretanto, estes tipos no possuem instncias, somente componentes executam podero t-las. Este diagrama demonstra os conceitos lgicos, que so as classes, objetos, seus relacionamentos e suas funcionalidades arquitetura do sistema. implementados fisicamente(componentes) na
Figura 26 Representao para um Diagrama de Componentes
4.6.8 Diagrama de Execuo O diagrama de execuo demonstra a arquitetura fsica do hardware e do software para o sistema, incluindo-se perifricos e suas conexes. Utiliza-se o mesmo modelo de elemento, os componentes, do diagrama de componentes para representar os objetos fsicos do domnio do sistema, como um host em uma LAN, um servidor e outros equipamentos para representar a arquitetura fsica do sistema.
46
Figura 27 Representao para um Diagrama de Execuo
4.7 Ciclo de desenvolvimento O ciclo de desenvolvimento onde tratamos um conjunto limitado de requisitos de um ou mais casos de uso, sendo que ao trmino do sistema teremos passado por diversos ciclos, e em cada ciclo, por suas diversas fases. A UML fornece um roteiro, no um mtodo, para o desenvolvimento de sistemas, entretanto no necessrio que o roteiro seja seguido na ntegra. Podemos seguir um roteiro mnimo, que representa as funcionalidades essenciais do sistema atravs da UML. O primeiro passo a Anlise de requisitos onde se deve definir claramente quais objetivos devem ser atingidos ao final da construo de um sistema. O passo seguinte a Anlise, onde necessrio definir os mecanismos que sero utilizados para solucionar o problema. Neste ponto surgem preocupaes com as abstraes usadas em UML, onde se exige a definio das classes e dos objetos. O terceiro passo a preocupao com o design, estendendo-se para solues tcnicas, incluindo perifricos, gerenciamento de bancos de dados e comunicao com outros sistemas. Esta fase fornece especificaes para a etapa de programao. A fase de programao onde as classes modeladas em UML so transformadas em cdigo. Deve-se exigir que sejam convertidas em cdigo exatamente todas as classes que foram especificadas, para que seja refletido exatamente o que foi modelado. A ltima fase a de testes, onde o sistema rodado em unidades do usurio.Deve-se testar a aceitao e a integrao do sistema, alm da verificao de que o sistema atenda os requisitos especificados.
47
Como exemplo, utilizamos a informatizao da biblioteca da universidade. Ao definirmos qual o objetivo a ser seguido, devemos buscar o que necessrio para atingi-lo. A especificao dos requisitos uma descrio de tudo o que preciso para construir o produto final que ir informatizar a biblioteca. Poderemos especificar estes requisitos da seguinte forma: Objetivos gerais: O sistema a ser construdo dever permitir a execuo de todas as tarefas necessrias em uma biblioteca no que se relaciona a emprstimo, devoluo e reserva de livros. Clientes: A biblioteca da universidade, onde o sistema ser instalado em terminais. Objetivo: Aumentar a rapidez no atendimento aos usurios da biblioteca. Funes do Sistema: Aqui devemos descrever o que o sistema deve fazer, por exemplo, Realizar a reserva de um livro. Atributos do Sistema: No so funes do sistema, mas caractersticas, como rapidez no tempo de resposta quando uma consulta realizada, facilidade de uso, tolerncia a falhas. 4.8 Fases de Desenvolvimento de Sistemas Basicamente, podemos dividir as fases de desenvolvimento de sistemas em cinco: Anlise de requisitos, Anlise, Design, Programao e Testes.
4.8.1 Anlise de Requisitos O passo nmero um e o mais importante ao iniciarmos a construo de um sistema a Anlise de Requisitos. onde definimos os casos de uso que iro retratar os requerimentos do cliente. O caso de uso descreve uma funcionalidade fornecida pelo sistema. Dessa forma, devemos implementar nesta etapa os casos de usos e seus relacionamentos com os atores, que sero representados em diagramas de casos de uso. A preocupao apenas em demonstrar os requerimentos do cliente, o que ele deseja, sem consideraes no que diz respeito a como implementar. Os diagramas de seqncia e de estado do sistema tambm so implementados nesta fase. 4.8.2 Anlise A fase seguinte a de anlise, onde surgem preocupaes com representao das abstraes da UML, como classes, objetos, os relacionamentos e colaboraes entre
48
estas classes. Nesta fase iremos construir o diagrama de Classes e iniciar a construo do modelo conceitual. Devemos modelar apenas as classes que iro fazer parte do domnio do problema e no classes tcnicas com definies de detalhes e solues do software, como classes de interface com o usurio e de definies de bancos de dados ou de comunicao. A fase analisar iniciada aps a identificao e documentao dos casos de uso. Nesta fase, iremos investigar os problemas do ciclo corrente. Devemos sempre lembrar em mostrar apenas solues para o domnio do problema. Para obter este resultado, inicialmente devemos projetar o modelo conceitual, que ir identificar os conceitos no domnio de uso. do sistema. Podemos implementar o modelo conceitual em partes, acrescentando novos conceitos a cada ciclo, medida que formos analisando cada caso Podemos tambm realizar refinamentos de casos de uso quando houver necessidade 4.8.2.1 Modelo Conceitual Durante a fase de anlise, procura-se decompor o problema em conceitos e objetos, por este motivo, o modelo conceitual considerado o artefato mais importante a ser criado nesta fase , pois este modelo que demonstra os conceitos em um domnio do problema. Em UML utilizamos um diagrama esttico desenvolvimento deste diagrama, ideal para representar o modelo conceitual, pois nele iremos representar conceitos do mundo real. Durante o que estejam prontos os casos de uso e documentos auxiliares para que seja possvel identificar os conceitos que sero representados no modelo. O modelo conceitual no representa nenhuma operao ou modelo de software, apenas conceitos, associaes entre estes conceitos e atributos dos conceitos. Um conceito uma idia, uma coisa ou um objeto que representado por um smbolo e definido por uma inteno. A extenso um conjunto de exemplos aos quais podemos aplicar este conceito. Como exemplo, podemos representar o acervo de livros da biblioteca por um smbolo Livros. A inteno do conceito Livros representar o conjunto de todos os livros da biblioteca. Devemos documentar todos os conceitos que acharmos necessrio e at mesmo aqueles que se acredita dispensveis. A identificao dos conceitos deve ser feita buscando-se substantivos e frases nos casos de uso e em
49
documentos, que podem representar conceitos ou atributos para incluso no modelo conceitual. Podemos utilizar a seguinte seqncia para construir um modelo conceitual - Listar os conceitos candidatos; - Incluir estes conceitos no modelo conceitual; - Incluir associaes para representar os relacionamentos que se deseja guardar informaes; - Adicionar os atributos para representar os requisitos de informaes. Para distinguir atributos de conceitos devemos pensar da seguinte forma, Conforme descreve Larman[1] : Se voc pensa em um conceito X como um nmero ou um texto no mundo real, ento X provavelmente um conceito e no um atributo. Construo do Modelo Conceitual: - Inicialmente, devemos identificar os conceitos necessrios para atender os requisitos do sistema. Para buscar estes conceitos, utilizaremos os casos de uso j definidos que so registrar Devoluo no prazo e Registrar Emprstimo. Nestes casos de uso buscaremos objetos, descries de coisas, lugares, transaes, papis desempenhados por pessoas que so relevantes para acrescentar ao modelo. Caso de Uso : Registrar Devoluo no prazo Aes do Ator 1. O funcionrio recebe do usurio o(s) livro(s) que levou emprestado. 2. O funcionrio registra no sistema os 3. O sistema emite dados identificando que dados do livro e do usurio para verificar se a devoluo est dentro do prazo. a devoluo est no prazo. 4. O funcionrio confirma a devoluo. 5. O sistema emite comprovante de devoluo com os dados da devoluo. Resposta do Sistema
50
Revisando o caso de uso acima, podemos identificar os seguintes conceitos: funcionrio(realiza um papel), usurio (realiza um papel),livro(objeto),devoluo( uma transao). Caso de Uso : Registrar Emprstimo Aes do Ator 1. O funcionrio recebe do usurio o(s) livro(s) que deseja levar emprestado. 2. O funcionrio registra no sistema os 3. O sistema emite dados identificando que dados do livro para verificar se possvel o realizar o emprstimo 4. Considerando que o livro livro para emprstimo (ou para consulta). para 5. O sistema emite confirmao de que o Resposta do Sistema
emprstimo, o funcionrio registra os dados usurio est apto a obter o emprstimo. do usurio. 6. O funcionrio confirma o emprstimo. 7. O sistema registra os dados e emite comprovante de emprstimo para o usurio com dados do usurio, dados do livro e a data do emprstimo .
O caso de uso acima acrescenta o conceito de emprstimo, que uma transao. Podemos dizer que os conceitos significativos do domnio da biblioteca so basicamente Livro, Funcionrio, Usurio e Emprstimo.
51
Modelo Conceitual
Gnero Acervo Livro 1 0..* ItensdoEmprstimo 1..* 1 Emprstimo 1 0..* Pessoa Usurio
Assunto
Editora Seo
Figura 28 Representao de Modelo Conceitual
52
4.8.3 Design A terceira fase o Design, onde os dados obtidos na Anlise sero repassados para implementaes tcnicas. Esta etapa equivalente fase projetar, conforme descrita por Larmam[1].Podemos incluir interfaces, especificaes de perifricos, solues para gerenciamento de bancos de dados e para a comunicao com outros sistemas, enfim, tudo o que est relacionado s especificaes de infra-estrutura para a fase de programao. Deve-se construir nesta fase os diagramas de pacotes, refinar os diagramas de interao, de casos de uso, de classes e de estados. 4.8.4 Programao A fase seguinte, de Programao ou construo, ser iniciada somente aps finalizadas as definies das classes em UML. Nesta etapa as classes sero convertidas para o cdigo fonte da linguagem orientada a objetos que foi escolhida. extremamente necessrio que seja implementado para cdigo fonte o que foi realmente definido na fase anterior, pois isto faz com que o sistema esteja de acordo com as especificaes. Ao dar seqncia ao andamento desta fase, podemos utilizar os padres sugeridos por Larman[1] para obter um software bem projetado. 4.8.5 Testes A fase final do desenvolvimento a de Testes. O objetivo desta etapa verificar se o sistema possui a funcionalidade especificada pelo consumidor.Neste momento devem ser realizados testes de integrao, pelo programador e testes de aceitao pelo cliente nas unidades onde o sistema ser implantado. Os testes devem ser feitos em blocos separados, testando inicialmente as classes e fazendo uso de diagramas e das definies das classes . Logo em seguida, deve-se integrar estes testes e testar o sistema como um todo, uma caixa preta, para verificar se ele realmente est realizando o que foi proposto. O teste de integrao utilizam, em geral, diagramas de componentes e diagramas e colaborao. Os testes de sistemas baseiam-se nos diagramas de caso de uso para realizar a validao do sistema. Estas etapas de desenvolvimento devero ser realizadas dentro de um ciclo de desenvolvimento, passando-se por diversos ciclos at a finalizao do software.
53
Padres Os padres surgiram da observao de que, durante o desenvolvimento de sistemas, existe a repetio de certos tipos de problemas. O interessante que estes problemas, por serem bastante parecidos, podem ser documentados em pares problema/soluo. A soluo a descrio da forma geral que seria aplicada para resolv-los. A soluo do problema obtida atravs da reutilizao a longo prazo de boas solues. A vantagem de aplicarmos um padro para resolver um problema evitar o desperdcio de tempo na busca da melhor soluo , pois justamente isso que o padro disponibiliza. A clareza das informaces, a facilidade para documentao e para o aprendizado por desenvolvedores novatos tambm outro bom motivo para a utilizao de padres de desenvolvimento. Atualmente, a inteno dos padres , alm de propor a melhor soluo para um problema e sua reutilizao, compartilhar conhecimento entre desenvolvedores de sistemas para documentar pares de problemas e suas respectivas solues, obtendo-se uma linguagem comum. A idia de padro surgiu atravs de trabalhos de Christopher Alexander, que era arquiteto e verificou a necessidade de uma padronizao nos projetos com o objetivo de melhorar a qualidade de vida das pessoas. O surgimento dos padres, ou Design Patterns, para desenvolvimento de sistemas ocorreu no final dos anos 80. Os primeiros padres e suas aplicaes foram desenvolvidas por Ward Cunningham e Kent Beck para desenvolvimento de interfaces em Smalltalk. Na mesma poca, Jim Coplien desenvolvia um catlogo de padres em C++ e Erich Gamma procurava documentar estruturas de projetos que apareciam repetidamente durante o desenvolvimento. O primeiro catlogo de padres surgiu em 1993. Um design pattern composto de um par problema/soluo em um determinado contexto. O problema o que se deseja resolver dentro de um contexto. A soluo a proposta de como resolver este problema aplicando-se a melhor soluo encontrada por desenvolvedores experientes. O contexto o conjunto onde se aplica o par problema/soluo. No domnio da orientao a objetos, um padro identifica classes e
54
objetos que se comunicam e que so utilizadas para resolver problemas repetitivos dentro de um contexto. Um padro no significa necessariamente nenhuma novidade para o desenvolvimento de um sistema. Em geral, um padro demonstra uma prtica comum, amplamente testada e que funciona. Oferece uma tcnica, com princpios de desenvolvimento que so seguidos como uma rotina, uma regra. Conforme Larman[1], um padro no prope nenhuma nova idia, trata-se exatamente do oposto - eles so uma codificao de princpios bsicos existentes e amplamente utilizados. Um padro representado atravs de pares problema/soluo, onde o problema/soluo descrito de forma genrica para que se possa extrair os possveis casos onde poderemos aplic-los.
5.1 Grasp
Os padres Grasp, desenvolvidos por Craig Larman, tm como objetivo principal definir as responsabilidades de um objeto do sistema. Segundo Larman[1], as responsabilidades esto relacionadas s obrigaes de um objeto em termos do seu comportamento. As responsabilidades principais so conhecer e fazer. O objeto tem a responsabilidade de fazer alguma coisa por ele mesmo, dar incio em aes em diferentes objetos e tambm controlar atividades de outros objetos. A responsabilidade de conhecer implica em obter dados privados de outras classes, conhecer objetos relacionados a ele e derivar ou calcular dados de outros objetos. No sistema de biblioteca, podemos definir que um emprstimo tem a responsabilidade de fazer a impresso dos dados do emprstimo. Um mtodo corresponde implementao de responsabilidade. Ao imprimir os dados do emprstimo, o mtodo ImprimirEmprstimo() ir satisfazer a responsabilidade da classe Emprstimo de imprimir seus prprios dados. Podemos utilizar os diagramas de interao para demonstrar a atribuio de responsabilidades a objetos.
55
5.1.1 Expert O padro Expert ou especialista apresenta o princpio de que a classe especialista, isto , a que tem o domnio da informao quem deve ter a responsabilidade de trabalhar com estes dados. Por exemplo, devemos atribuir a responsabilidade de imprimir os dados do emprstimo classe Emprstimo, porque esta classe possui todos os dados necessrios. Podemos investigar qual a classe a expert nos dados do emprstimo utilizando perguntas como Quem conhece os dados do emprstimo? A resposta simples, a prpria classe emprstimo, pois ela especialista na informao. H casos em que apenas uma classe no poder ser a responsvel por toda a tarefa e necessitar de outras classes, que conhecem parcialmente alguns dados. Podemos observar que para imprimir os dados do emprstimo tambm so necessrios dados do livro, como Cdigo e Ttulo. A classe Livro a especialista nestas informaes, portanto, ela quem dever fornecer estes dados atravs de uma mensagem enviada a ela pela classe emprstimo. Neste caso, dizemos que a classe livro uma especialista parcial . A vantagem da utilizao deste padro que, ao deixar a classe expert responsvel pela obteno dos dados, estamos encapsulando a informao na classe que a possui. 5.1.2 Creator Este padro tem por princpio atribuir a responsabilidade de criao de uma nova instncia de um objeto A a uma classe que contm,agrega ou usa objetos desta classe. Esta tarefa muito comum em sistemas OO, da a necessidade de um padro que definisse quem deve criar uma instncia de um objeto. Em geral, relacionamentos de agregao demonstram as classes que agregam, contm ou usam um objeto. O padro expert poder servir de base para definirmos a responsabilidade da criao, pois pode-se atribuir esta responsabilidade classe que possui os dados de inicializao necessrios criao do novo objeto. Os dados iniciais so passados durante a criao atravs de um mtodo de inicializao. Em delphi e em Java utilizamos um construtor que pode ou no receber parmetros. Podemos questionar quem deve ser o responsvel pela criao de uma nova instncia da classe ItensdoEmprstimo. A classe Emprstimo mais indicada por ser a conhecedora de dados iniciais dos itens pertencentes ao emprstimo em questo.
56
Os padres apresentados, expert e criator(criador) relacionam-se com outros padres que sero vistos a seguir.
Indica que a classe emprstimo deve ser responsvel pela impresso dos seus prprios dados
Imprimir() --> :Emprstimo
2:Imprimir() -->
:ItensdoEmprstimo
Figura 29 Representao da Atribuio de responsabilidade

5.1.3 Low Coupling O acoplamento fraco busca resolver o problema da reutilizao de uma classe. O acoplamento de uma classe refere-se ao quanto esta classe depende de outra. Quanto menos uma classe depende de outra, mais fracamente acoplada ela . Significa dizer que, quanto mais independente for a implementao de uma classe A, mais fcil sua manuteno pois uma mudana nas classes relacionadas no implica muitas mudanas em A. Tambm podemos dizer que mais fcil a sua reutilizao por outras classes, pois sua implementao a torna independente da implementao das outras classes. Como exemplo a criao de uma nova instncia de Assunto para uso da classe Livro conforme o modelo conceitual, poderia ser atribuda classe Acervo. Neste caso, seria preciso que acervo conhecesse a classe Assunto, o que a tornaria acoplada Assunto. O ideal que a classe Livro seja a responsvel pela criao de nova instncia de Assunto, pois Livro conhece Assunto. O mesmo raciocnio ir servir para Gnero e Editora. Desta forma estaremos favorecendo o baixo acoplamento da classe Acervo e tornando-a mais independente, sendo necessrio apenas que ela conhea a classe Livro . Este padro no til separadamente. sempre utilizado em conjunto com outros, como o creator e o expert e interessante em projetos que buscam a reutilizao de componentes.
57
5.1.4 High Cohesion A coeso mede quanto as responsabilidades de uma classe esto relacionadas. desejvel que as classes possuam alta coeso, ou seja, possuam responsabilidades altamentes relacionadas, mas que no executem uma enorme diversidade de funes. O objetivo deste padro, tambm chamado de Alta Coeso, atribuir a responsabilidade de execuo de uma tarefa a um objeto mantendo esta alta coeso. Ao diversificarmos demais as responsabilidades de uma classe, sem que estas atividades estejam relacionadas, tornamos a classe suscetvel s mudanas, dificultando sua manuteno e sua reutilizao. O interessante que uma classe deva executar somente o que est ao seu alcance, aquilo que ela tem conhecimento para executar. Ao atribuirmos a responsabilidade de Livro criar novo Assunto, favorecemos a alta coeso desta classe(Livro), pois Livro possui os dados necessrios e iniciais para a nova instncia e est diretamente relacionada classe Assunto.
5.1.5 Controller O padro controller objetiva atribuir a responsabilidade de tratamento de eventos do sistema a uma classe representativa de todo o sistema. um controlador fachada, que tem a responsabilidade de tratar todos os eventos externos de um ator, provenientes de um caso de uso. A classe escolhida para ser o controller deve representar todo o sistema, Se existirem poucos eventos , pode representar o negcio ou simplesmente um tratador dos eventos de um caso de uso. A opo de implementar um controller para cada caso de uso ideal, pois se novas opes de casos de uso forem acrescentadas, no teremos uma nica classe controladora grande e com pouca coeso. A utilizao de um controller possibilidade de reutilizao para tratamento de eventos do sistema aumenta a das outras classes, pois ficam apenas com a
responsabilidade de executar tarefas dentro do seu domnio. O controller deve ser implementado de forma a delegar as tarefas a outros objetos do sistema e utilizando-se tambm dos conceitos de outros padres, como os descritos anteriormente. Para a implementao da biblioteca, poderamos implementar uma classe controller chamada Principal para tratar os eventos do funcionrio, que um ator externo ao sistema e que, por exemplo ao indicar para o sistema
finalizar um emprstimo
pressionando um boto, gera um evento que faz com que o emprstimo seja efetuado e
58
imprima os seus dados. Observe que o controller no ir executar as operaes, mas apenas tratar os eventos e envi-los s classes que so experts na realizao da tarefa. importante salientar que a interface, ou camada de apresentao tambm no deve tratar eventos do sistema, mas encaminhar a tarefa ao controller e este classe especializada na informao.
Principal ExecutarEmprstimo() EntrarItensdoEmprstimo() ImprimirEmprstimo()
Figura 30 Representao de uma classe para Controller.
Concluso A OO em conjunto com a que permite UML sero empregadas constantemente na anlise e nos seus conceitos, ela j empregada no
implementao de sistemas. Devido ao fato da UML ser uma tcnica bastante flexvel, o aperfeioamentos desenvolvimento de ferramentas de modelagem visual e em outros ambientes de desenvolvimento, o que faz com que esta tcnica seja utilizada como linguagem de modelagem padro nos mais diversos tipos de sistemas e ferramentas para desenvolvimento. A UML, os padres de desenvolvimento e os frameworks que se utilizam da OO so a grande soluo para diminuir o tempo de desenvolvimento de qualquer sistema, para qualquer rea do conhecimento humano. Os padres,a UML e a OO so indispensveis, mas somente a utilizao destas tcnicas no nos permite obter o menor tempo na criao de solues informatizadas. intessante melhorar o processo de desenvolvimento de software de forma a torn-lo completamente padronizado, podendo-se para isso utilizar as idias introduzidas pelo CMM, que possibilita agregar mais qualidade ao software. Atualmente grandes empresas se mobilizam para criar frameworks utilizando UML, OO e padres, como o Template Method, porque suas classes so altamente reutilizveis.
59
Referncias Bibliogrficas
[1] Larman, Craig.Utilizando UML e Padres : uma introduo anlise e ao projeto orientados a objetos. trad. Luiz A. Meirelles Salgado. Porto Alegre: Bookman, 2000. [2] Rumbaugh, James; Blaha, Michael; Premerlani, Willian; Eddy,Frederick; Willian Lorensen.Modelagem e Projetos Baseados em Objetos. - traduo de Dalton Conde de Alencar. Rio de Janeiro: Campus,1994. [3] Fowler, Martin.UML Destiled : A brief guide to the standard object modeling language. 2 ed. Addison Wesley, 2000. [4] Barros, Pablo Fernando do Rgo. Monografia : Uml Linguagem de Modelagem Unificada. [5] Gamma, Erich; Helm, Richard; Johnson,Ralph; Vlissides, John. Padres de Projeto: Solues Reutilizveis de Software Orientado a Objetos. Porto Alegre: Bookman, 2000. [6] Medeiros, lvaro. Viso Geral de UML.
Artigos e sites consultados na Internet
Orientao a Objetos http:// www.tool.pro.com.br Rational Rumbaugh http://www.sigs.com/publications/docs/9601/oc9601.c.chonoles.html#OMT Object FAQ http://iamwww.unibe.ch/~seg/OOinfo/FAQ/index.html Booch http://www.sigs.com/publications/docs/9601/oc9601.c.chonoles. http://www.rational.com
60

OO - Monografia

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

OO - Monografia

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidade Federal da Paraba Centro de Cincias Exatas e da Natureza Departamento de Informtica

Desenvolvimento de Sistemas Utilizando Orientao a Objetos

Soila Mara Pereira Rosado

JOO PESSOA PB julho de 2003

Universidade Federal da Paraba Centro de Cincias Exatas e da Natureza Departamento de Informtica

Desenvolvimento de Sistemas Utilizando Orientao a Objetos

Soila Mara Pereira Rosado

JOO PESSOA PB julho de 2003

2.5.1 Objetos So utilizados

Mtodos do Objeto Atributos do Objeto

Figura 1 -Representao para um objeto

Figura 2 Representao para a passagem de mensagens entre objetos.

Atributos : Ttulo, Autor, Assunto, Editora, Seo Operaes : Adiciona(), Remove(),ObtemAutor.

Figura 3 - Representao de uma classe

Podemos citar como exemplo

a criao de uma nova instncia da classe, que

Figura 4 Representao de Herana

teve incio em 1994 pelos

Grady Booch e James Rumbaugh, da Rational Software

Figura 5 Diferentes Vises do Sistema

Atributo Classe Classe Classe Classe Atributo

Figura 6 Representao de uma viso do sistema.

relacionam-se(associaes) da mesma maneira com outros objetos.

Figura 7 Representao de uma classe e seus mtodos.

Figura 8 - Representao de Ator.

Figura 9 - Representao do Caso de Uso Registrar Emprstimo

Figura 10 Representao de Componente.

Figura 11 Representao de Pacote.

<<Interface>> Inicializa InicializarExecuo()

Figura 12 - Representao de Interface

Figura 13 Representao de Associao

Figura 14 Representao de Agregao

Figura 15 Representao de Generalizao

Figura 16 Representao de Composio

Figura 17 Representao de Nota 4.5.6.2 Ornamentos

Figura 18 Representao de um ornamento

sublinhado) para diferenciar a instncia da classe Livro. 4.6 Diagramas

Registrar Emprstimo :Funcionrio :Sistema

EntrarDadosLivro(CdigoLivro) Repetir para cada Livro

Texto explicativo Sobre a lgica

Eventos do sistema(dis param uma d

Figura 19 - Diagrama de seqncia

Figura 20 - Diagrama de Colaborao

Figura 21 Representao para um Diagrama de Casos de Uso

Figura 22 Representao para Diagrama de Classes

Pedro:Funcionrio Nome : Pedro da Silva DataAdmisso : 20/09/1997

Maria:Usurio Nome : Maria dos Santos Idade : 12 anos DataNascimento : 11/07/1990

Figura 23 Representao para um Diagrama de Objetos

Figura 24 Representao para um Diagrama de Estados

Figura 25 Representao para um Diagrama de Atividades

Figura 26 Representao para um Diagrama de Componentes

Figura 27 Representao para um Diagrama de Execuo

Figura 28 Representao de Modelo Conceitual

Imprimir() --> :Emprstimo

Figura 29 Representao da Atribuio de responsabilidade

Principal ExecutarEmprstimo() EntrarItensdoEmprstimo() ImprimirEmprstimo()

Figura 30 Representao de uma classe para Controller.

Anda mungkin juga menyukai