1

Programao Orientada ao Objeto

1. IntroduoFormalmente, para ser considerada uma linguagem OO, a linguagem em questo precisa implementar quatro conceitos bsicos: abstrao, encapsulamento, herana e polimorfismo.

Abstrao

considerada como a habilidade de modelar caractersticas do mundo real do problema que o programador esteja tentando resolver. Por exemplo, se o programador estiver interessado em controlar dados dos clientes de uma empresa, muito mais fcil lidar com uma linguagem que oferea recursos em que ele possa criar algo chamado "Cliente" ao invs de recorrer a estruturas de dados tipo array ou record. Nesse contexto a abstrao refere-se capacidade de modelar o mundo real, e por outro lado, podemos consider-la como um mecanismo pelo qual restringimos o nosso universo de anlise e as variveis e constantes que compem esse universo, desprezando os dados que no nos interessa na anlise. Podemos demonstrar o uso de abstrao facilmente, quando fechamos os olhos e pensamos em uma mesa; esta mesa imaginria provavelmente no vai ser igual a uma outra imaginada por outras pessoas, mas o que importa que todas as pessoas que imaginaram uma mesa colocaram nessa abstrao as informaes que para elas so necessrias para a sua funo (de ser uma mesa). No importa se a mesa de trs ps ou quatro, ou se o tampo de vidro, madeira ou mrmore; o que importa que a imagem que idealizamos em nossa cabea de uma mesa e tem as informaes necessrias para cumprir sua funo.

Encapsulamento

a base de toda a abordagem da Programao Orientada ao Objeto e dizemos que um dado est encapsulado quando envolvido por cdigo de forma que s visvel na rotina onde foi criado; o mesmo acontece com uma rotina, que sendo encapsulada, suas operaes internas so invisveis s outras rotinas. Podemos visualizar a sua utilidade do encapsulamento pensando em um vdeo cassete, onde temos os botes de liga-desliga, para frente, para traz, etc. Estes botes executam uma srie de operaes existentes no aparelho, onde so executadas pelos componentes existentes dentro do aparelho (transistores, cabos, motores, etc.) No interessa ao operador saber como o funcionamento interno do equipamento; esta informao s relevante para os projetistas do aparelho. As informaes pertinentes ao usurio do equipamento so as existentes no meio externo (botes, controle remoto) que ativam as operaes internas do equipamento.

Herana

um mecanismo que permite altos nveis de reaproveitamento de atributos e mtodos. Do ponto de vista prtico, pode ser entendido como sendo um conjunto de instncias criadas a partir de outro conjunto de instncias com caractersticas semelhantes, e os elementos desse subconjunto herdam todas as caractersticas do conjunto original. A idia fornecer um mecanismo simples (mas muito poderoso) para que se definam novas classes a partir de uma j existente. Assim sendo, dizemos que essas novas classes herdam todos os membros (propriedades+mtodos) da classe-me; isto torna o mecanismo de herana uma tcnica muito eficiente para construir, organizar e reutilizar cdigo. Por isso, nas linguagens que no suportam esse mecanismo, as classes so criadas como unidades independentes: cada uma com seus membros concebidos do zero (sem vnculo direto com outras classes), o que torna o processo mais demorado e com cdigos, s vezes, redundantes. A herana possibilita a criao de uma nova classe de modo que essa classe (denominada subclasse, classe-filha ou classe derivada) herde TODAS as caractersticas da classe-me (denominada superclasse, classe base ou classe primitiva); podendo ainda, a classe-filha, possuir propriedades e mtodos prprios.

Polimorfismo

O conceito de polimorfismo est diretamente associado Herana. O Polimorfismo trabalha com a re-declarao de mtodos previamente herdados por uma classe. Esses mtodos, embora semelhantes (apresentam a mesma assinatura), diferem de alguma forma da implementao utilizada na super-classe, sendo necessrio, portanto, reimplement-los na sub-classe.Porm, para evitar ter que modificar o cdigo-fonte, inserindo uma chamada a um mtodo com nome diferente, redeclara-se o mtodo com o mesmo nome declarado na super-classe, Dessa maneira, podem existir dois ou mais mtodos com a mesma nomenclatura, diferenciando-se na maneira como foram implementados, sendo o sistema responsvel por verificar se a classe da instncia em questo possui o mtodo declarado nela prpria ou se o herda de uma super-classe.2. Definies

Vamos agora definir mais formalmente as principais noes do modelo a objetos.

Objeto

No conceito de sistemas orientados a objetos, um objeto representa uma entidade que pode ser fsica, conceitual ou de software. uma abstrao de algo que possui fronteira definida e significado para a aplicao.

Dentro da terminologia das linguagens de programao, um objeto passa a existir a partir de um 'molde'. Este 'molde', definido como classe do objeto, define os limites, seus atributos e suas funes. Podem ser criados vrios objetos ou instncias de uma classe.

Em termos de implementao, objeto um bloco de dados privados envolvidos por cdigo, de maneira que o acesso a ele s pode ser feito sob condies especiais. Todo o comportamento desse "ente" encapsulado descrito atravs de rotinas que manipulam seus dados, sendo que o seu estado corrente est em seus prprios dados; em outras palavras, cada objeto tem suas prprias caractersticas, moldadas a partir de uma matriz.

Classe

Uma classe abstrai um conjunto de objetos com caractersticas similares. Uma classe define o comportamento de seus objetos atravs de mtodos e os estados possveis destes objetos atravs de atributos. Em outros termos, uma classe descreve os servios providos por seus objetos e quais informaes eles podem armazenar.

Uma classe define estado e comportamento de um Objeto geralmente implementando mtodos e atributos. Os atributos, tambm chamados de campos, indicam as possveis informaes armazenadas por um objeto de uma classe, representando o estado de cada objeto. Os mtodos so procedimentos que formam os comportamentos e servios oferecidos por objetos de uma classe.

Instncia:

Um objeto. A noo de instncia quase igual de objeto. Instncia se refere implicitamente a uma classe, e sempre uma instncia de uma classe especifica. Objetos podem ser considerados independentemente das suas classes.

A noo de instncia tambm mais geral. Qualquer conceito abstrato pode ter instncias (aplicaes concretas do conceito). Por exemplo, um mtodo pode ser considerado uma instncia de uma operao; um atributo particular de uma classe pode ser considerado uma instncia do conceito geral de atributos, etc.

Propriedade:

Um conceito definido por um conjunto de propriedades. Por exemplo, uma pedra tem as seguintes propriedades: dura, inanimada, slida, e muitas outras.

Uma classe modela um conceito listando algumas das suas propriedades interessantes, considerando o problema a resolver. Por exemplo, a data de nascimento de um aluno vai ser uma propriedade interessante. A cor dos cabelos tambm uma propriedade do conceito aluno, mas provavelmente, no importante no modelo e no ser modelada.

Atributo:

Uma propriedade importante de uma classe que pode ser representada com uma varivel. Por exemplo, a data de nascimento de um aluno.

Mtodo:

Uma propriedade importante de uma classe que pode ser representada com uma funo. Por exemplo, a idade de um aluno pode ser calculada a partir da data de nascimento e da data do dia corrente.

Operao:

Um mtodo mais abstrato. O mtodo se refere implicitamente a uma funo. A operao mais abstrata, ela se refere idia do que a funo faz, mas no se preocupa com os detalhes de implementao. Um mtodo implementa uma operao.

Mensagem: Manda-se uma mensagem a um objeto para pedir a ele que execute uma operao particular. Novamente, isso uma noo muito parecida ao mtodo, mas aqui, se presta mais ateno ao aspecto dinmico: pedimos a um objeto que execute uma operao mandando uma mensagem a ele.

Interface:

o conjunto de propriedades da classe que pertencem ao conceito implementado pela classe.

Algumas operaes so complicadas demais para serem implementadas com uma funo s. preciso criar pequenas funes utilitrias que vo simplificar a implementao das operaes. Mas essas pequenas funes utilitrias no pertencem ao conceito que a classe implementa. Elas so apenas detalhes de implementao.

A interface especifica quais funes podem ser chamadas por outros objetos e quais no podem. As funes que no pertencem a interface so funes utilitrias que s podem ser chamadas pelo prprio objeto.

Suponhamos que as propriedades do conceito (propriedades da interface) no vo mudar enquanto os detalhes de implementao podem mudar. A interface permite proteger o exterior das mudanas dentro da classe. Enquanto a interface no muda, para o exterior, a classe no muda.

Interface tem tambm outro sentido um pouco diferente deste, que estudaremos mais tarde.3. Vantagens do modelo a objetos

O modelo a objetos tem vrias vantagens para a concepo e a programao de software. J vimos informalmente a maioria delas.

Abstrao:

As noes de operao e interface permitem conceber classes de maneira abstrata sem se preocupar em como sero implementadas. Elas diminuem a quantidade de coisas em que temos que pensar (uma operao para vrios mtodos), o que simplifica a concepo.

Tambm, graas ao alto nvel de abstrao que pode conseguir, o modelo a objetos pode ser utilizado desde o incio da concepo (anlise) at a programao. Assim, se torna mais fcil relacionar qualquer parte do programa com os conceitos mais abstratos que ele implementa (rastreamento). Pode-se relacionar a implementao com as decises de projeto. Isso muito importante para a boa manuteno do programa, tanto durante, quanto aps o seu desenvolvimento.

Encapsulamento:

Graas interface, o exterior da classe protegido das modificaes que podem acontecer na implementao da classe (interior). Enquanto a interface de uma classe no mudar, a classe no muda para o exterior. Ao mesmo tempo, a implementao pode mudar muito (mtodos se tornarem atributos, implementao dos mtodos mudando).

Isso j era possvel com modelos no objetos. Mas como as funes e a estrutura so agrupadas, se torna mais fcil respeitar a mesma interface enquanto se muda a implementao. (Existem tambm receitas para aproveitar mais essa qualidade como, por exemplo, nunca acessar diretamente os atributos de uma classe, mas sempre usar mtodos get e set).

Agrupamento dados/funes: Essa caracterstica facilita o polimorfismo. Como uma classe contm ambos dados e funes, uma operao pode ter vrias implementaes em vrias classes. Cada implementao diferente das outras, mas todas pertencem mesma operao.

Reutilizao:

O modelo a objetos permite duas formas de reutilizao:

A herana permite definir uma nova classe, reutilizando outras classes j definidas. Esta reutilizao facilita a definio da nova classe, basta se concentrar no que a nova classe acrescenta.

Cada classe um pequeno mdulo que contem dados e funes. Desta maneira, este pequeno mdulo pode ser reutilizado em outros sistemas.

Estrutura e funo: O modelo a objeto permite dar mais importncia estrutura de um sistema do que s funes. Isso importante porque as funes que um sistema deve realizar sempre mudam com o tempo enquanto so muito raras as mudanas da estrutura.4. A UML 2.0A UML 2.0 composta por 13 diagramas que se dividem em aspectos estticos (diagramas estruturais) e aspectos dinmicos (diagramas comportamentais)Diagramas Estruturais (Aspectos Estticos) 4.1 Diagrama de Classes 4.2 Diagrama de Objetos 4.3 Diagrama de Componentes

4.4 Diagrama de Implantao 4.5 Diagrama de Pacotes 4.6 Diagrama de Estrutura CompostaDiagramas Comportamentais (Aspectos Dinmicos) 4.7 Diagrama de Casos de Uso 4.8 Diagramas de Interao 4.8.1 Diagrama de Seqncia 4.8.2 Diagrama de Comunicao 4.8.3 Diagrama Geral de Interao 4.8.4 Diagrama de Tempo 4.9 Diagrama de Mquinas de Estados 4.10 Diagrama de Atividades 4.1 Diagrama de ClassesO diagrama de classes demonstra a estrutura esttica das classes de um sistema onde estas representam as "coisas" que so gerenciadas pela aplicao modelada. Classes podem se relacionar com outras atravs de diversas maneiras: associao (conectadas entre si), dependncia (uma classe depende ou usa outra classe), especializao (uma classe uma especializao de outra classe), ou em pacotes (classes agrupadas por caractersticas similares). Todos estes relacionamentos so mostrados no diagrama de classes juntamente com as suas estruturas internas, que so os atributos e operaes. O diagrama de classes considerado esttico j que a estrutura descrita sempre vlida em qualquer ponto do ciclo de vida do sistema. Um sistema normalmente possui alguns diagramas de classes, j que no so todas as classes que esto inseridas em um nico diagrama e eterminada classe pode participar de vrios diagramas de classes.

As classes tm responsabilidades, que na implementao do sistema transformam-se em operaes e atributos, e so interligadas atravs de relacionamentos.

Responsabilidades

No modelo a objetos, classes tm propriedades (atributos e operaes). Mas no incio da concepo, as propriedades ainda no so claras, e as classes tm apenas Responsabilidades.

Uma Responsabilidade um contrato entre a classe e o resto do sistema. Ela especifica o que as instncias da classe faro. Essa idia muito parecida com a idia de operao, mas Responsabilidades so mais abstratas. Responsabilidades so representadas por um texto curto (uma frase). Por exemplo, as responsabilidades de um aluno na universidade seriam de se registrar na universidade para um curso e fazer as disciplinas necessrias para este curso.

Uma classe pode ter qualquer nmero de Responsabilidades, mas na realidade, ela deveria ter pelo menos uma Responsabilidade e no mximo algumas. Todas as responsabilidades deveriam ser repartidas com eqidade entre as classes.

Responsabilidades so representadas dentro de um quarto compartimento, depois das operaes.

Atributos

Depois de identificar os objetos (ou conceitos) interessantes, temos que definir as propriedades desses objetos que queremos representar. Essas propriedades podem ser dados (atributos) ou operaes.

Um atributo representa uma propriedade que todos os objetos da classe tm (por exemplo, todas as mesas tm uma altura, nmero de pernas, posio na sala, etc.). Mas cada objeto ter valores particulares para seus atributos (algumas mesas so muito baixas, outras so altas, etc.). O valor de um atributo pode mudar com o tempo (ex.: posio da mesa na sala), a lista de atributos geralmente no muda.

Operaes

O segundo tipo de propriedade so as operaes ou mtodos. A palavra mtodo se refere mais a implementao, operao mais abstrata e designa um servio que os objetos devem cumprir. Operaes podem mudar os valores dos atributos do objeto que a efetua, ou no. Por exemplo, podemos abrir, fechar, ou deslocar uma janela, ou podemos contratar um empregado, etc.

Uma classe pode ter qualquer nmero de operaes.

Como os atributos, duas operaes em duas classes podem ter o mesmo nome. Isso se chama polimorfismo, a mesma operao (o que significa realmente, o mesmo servio abstrato a ser efetuado) est implementada com dois mtodos diferentes (verses concretas do servio abstrato) nas duas classes.

No incio, a operao vai ser definida de maneira muito abstrata. Quando afinar o modelo, precisaremos definir a assinatura da operao, o que significa: seu nome (j definimos isso), nmero de parmetros, tipos e ordem deles e eventualmente, seu tipo de retorno.RelacionamentosOs objetos tm relacionamentos entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Esses relacionamentos so representados tambm no diagrama de classes.

A UML reconhece trs tipos mais importantes de relacionamentos: associao, generalizao (ou herana) e dependncia.

Representao das relaes na UML

a. Associao

A associao pode existir entre classes ou entre objetos. Uma associao entre a classe Professor e a classe Disciplina (um professor ministra uma disciplina) significa que uma instncia de Professor (um professor especfico) vai ter uma associao com uma instncia de Disciplina. Esta relao significa que as instncias das classes so conectadas, seja fisicamente ou conceitualmente.

Vimos que um atributo de uma classe normalmente deveria ser de um tipo simples. A razo que se uma classe precisar de um atributo de tipo de uma outra classe (uma disciplina precisa de um atributo ministradoPor de tipo Professor), isso no se modela normalmente com um atributo, mas com uma associao (h uma associao entre Disciplina e Professor).

Uma associao tem dois sentidos: (1) um professor ministra uma disciplina e (2) a disciplina ministrado por um professor. comum interessar-se por apenas um dos dois sentidos, por exemplo, num editor de textos, somos interessados em saber se um documento contm uma tal figura, mas talvez no em saber qual documento contem uma figura particular.

O problema de representar uma associao por atributos numa classe que perdemos essa noo dos dois sentidos. Se a classe Professor contm um atributo de tipo Disciplina, no podemos adivinhar, olhando a classe Disciplina que ela tem uma associao com Professor. Mesmo quando estivermos interessados por apenas um dos dois sentidos de uma associao, melhor represent-la no modelo com uma associao mesmo.

O diagrama de classes tenta modelar a realidade (a associao tem dois sentidos). Isso no impede que no momento da implementao possamos decidir por aproveitar somente um dos dois sentidos.

a.1 - Agregao

uma forma especializada de associao na qual um todo relacionado com suas partes e onde se tenta representar que as informaes de um objeto (o objeto-todo) precisam se relacionar com as informaes contidas em um ou mais objetos de outra classe (o objeto-parte). Os objetos-parte no podem ser destrudos seno pelo objeto-todo. Tambm conhecida como relao de contedo.

Uma forma prtica de identificar um relacionamento Agregao normalizar um relacionamento N N. A classe de relacionamento ser o objeto-parte de um objeto-todo. Exemplo:

Pedido N N Produto ( Pedido 1 N Item-de-Pedido N 1 Produto

A classe Item-de-Pedido, que um atributo multi-valorado de Pedido, o objeto-parte e o Pedido o objeto-todo. A existncia do objeto-parte depende da existncia do objeto-todo.

Como representamos uma Agregao?A agregao representada como uma linha de associao com um diamante junto Classe agregadora. A multiplicidade representada da mesma maneira que nas associaes. Veja a figura:

A Agregao um caso particular da associao, indica que uma das classes do relacionamento uma parte, ou est contida na outra parte.

Agregao Compartilhada: dita compartilhada quando uma das classes uma parte, ou est contida na outra, mas esta parte pode estar contida na outra vrias vezes em um mesmo momento. Veja figura:

Agregao Simples: Uma variao desse tipo de Relacionamento, quando o Objeto de uma Classe composto de Objetos da prpria Classe. Veja figura:

Um objeto da Classe FormulrioDeRegistro contm um nico objeto FormulrioDeMatrcula. Um objeto FormulrioDeMatrcula est contido num nico objeto FormulrioDeRegistro.

a.2 - Composio

uma agregao onde uma classe que est contida na outra "vive" e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente, j que as mesmas fazem parte da outra.

Uma forma prtica de identificar um relacionamento Composio identificar um relacionamento 1 N onde a existncia do objeto-parte depende da existncia do objeto-todo. Entretanto, o objeto-parte no atributo multi-valorado do objeto-todo. Exemplo:

Revista 1 N Edio

No existe a Edio sem que haja a Revista. Entretanto, a Edio no pode ser considerada um atributo multi-valorado de Revista.

Como representamos uma Agregao do tipo Composio? representada como uma linha de associao com um diamante preenchido junto Classe agregadora. A multiplicidade representada da mesma maneira que nas associaes. Veja as figuras:

Veja um exemplo mais completo:

b. Generalizao

a capacidade de se criar superclasses que encapsulam estrutura e/ou comportamento comuns a vrias subclasses.

ProcedimentosOs procedimentos para se obter a generalizao so:

Identificar similaridades de estrutura/comportamento entre vrias Classes.

Criar a superclasse para encapsular a estrutura/comportamento comum.

As classes originais passam a ser subclasses da nova superclasse criada.

Uma maneira relativamente fcil de se entender isso comparando com a nossa herana gentica: Voc possui algumas caractersticas de seus Pais. Mas seus Pais no possuem suas caractersticas. Pois bem, voc seria uma subclasse.

Outra maneira de se compreender entendo o conceito de Herana.

Herana uma hierarquia de abstraes na qual uma subclasse herda a estrutura e/ou comportamento de uma ou mais superclasses. Exemplo:

A classe VeculoTerrestre pode possuir as subclasses Carro e Caminho, onde as subclasses herdam os atributos Peso e Comprimento.

A Classe Caminho pode ter o Atributo Tonelagem prprio da Classe, herdando Peso e Comprimento.

A Classe Carro pode no ter nenhum Atributo prprio, herdando Peso e Comprimento da classe VeculoTerrestre.

Caminho uma espcie de VeculoTerrestre.

Carro uma outra espcie de VeculoTerrestre.

Tipos de Herana: Herana simples quando uma subclasse herda estrutura e/ou comportamento de uma nica superclasse.

Herana mltipla quando uma subclasse herda estrutura e/ou comportamento de mais de uma superclasse.

IMPORTANTE: Herana uma relao entre Classes de Objetos, e no uma relao entre instncia das Classes.

Uma subclasse herda:

Atributos

Operaes

Relacionamentos

Uma subclasse pode:

Adicionar novos atributos, operaes e relacionamentos.

Redefinir operaes herdadas.

c. Dependncia

Uma dependncia indica a ocorrncia de um relacionamento semntico entre dois ou mais elementos do modelo, onde uma classe cliente dependente de alguns servios da classe fornecedora, mas no tem uma dependncia estrutural interna com esse fornecedor [Furlan, 1998]

Como funciona?Por exemplo: Uma mudana no elemento independente ir afetar o modelo dependente. Como no caso anterior com generalizaes, os modelos de elementos podem ser uma classe, um pacote, um use-case e assim por diante.

Na PrticaQuando uma classe recebe um objeto de outra classe como parmetro, uma classe acessa o objeto global da outra. Nesse caso existe uma dependncia entre estas duas classes, apesar de no ser explcita.

GraficamenteUma relao de dependncia simbolizada por uma linha tracejada com uma seta no final de um dos lados do relacionamento. E sobre essa linha o tipo de dependncia que existe entre as duas classes. Veja a figura:

4.2 Diagrama de ObjetosO diagrama de objetos uma variao do diagrama de classes e utiliza quase a mesma notao. A diferena que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos como se fosse o perfil do sistema em certo momento de sua execuo. A mesma notao do diagrama de classes utilizada com 2 excees: os objetos so escritos com seus nomes sublinhados e todas as instncias num relacionamento so mostradas. Os diagramas de objetos no so to importantes como os diagramas de classes, mas eles so muito teis para exemplificar diagramas complexos de classes ajudando muito em sua compreenso. Diagramas de objetos tambm so usados como parte dos diagramas de colaborao, onde a colaborao dinmica entre os objetos do sistema so mostrados.

4.3 Diagrama de Componentes

O diagrama de componentes e o de implantao so diagramas que mostram o sistema por um lado funcional, expondo as relaes entre seus componentes e a organizao de seus mdulos durante sua execuo.

O diagrama de componentes, que est muito relacionado linguagem de programao utilizada, descreve os componentes de software e suas dependncias entre si, representando a estrutura do cdigo gerado. Os componentes so a implementao da arquitetura fsica dos conceitos e da funcionalidade definidos na arquitetura lgica (classes, objetos e seus relacionamentos). Eles so tipicamente os arquivos implementados no ambiente de desenvolvimento.

Componentes so tipos, mas apenas componentes executveis podem ter instncias. Um diagrama de componentes mostra apenas componentes como tipos. Para mostrar instncias de componentes, deve ser usado o diagrama de implantao, onde as instncias executveis so alocadas em ns.

A dependncia entre componentes pode ser mostrada como uma linha tracejada com uma seta, simbolizando que certo componente precisa de outro para possuir uma definio completa. Com o diagrama de componentes fcil detectar quais arquivos .dll so necessrios para executar a aplicao.

A UML reconhece cinco esteretipos de componentes:

Executvel: Um componente que pode ser executado (um programa).

Biblioteca: Uma biblioteca de classes ou funes, dinmica ou esttica.

Tabela: Uma tabela de um banco de dados.

Documento: Uma parte da documentao (texto livre, diagramas, documentos de ajuda, etc.)

Arquivo: Trata-se, geralmente, de um arquivo de cdigo fonte, mas pode ser tambm um arquivo de dados, um script ou outros arquivos.

Os cinco tipos de componentes com os respectivos cones na UML

Alguns usos mais comuns do diagrama de componentes so:

Organizar o cdigo fonte. Por exemplo, mostrar todas as dependncias entre os arquivos de cdigo fonte. Isso pode ajudar a definir as dependncias de compilao (se modificarmos um arquivo, quais outros arquivos precisam ser compilados novamente).

Organizar os produtos executveis. A partir de um conjunto de arquivos (cdigo fonte), possvel criar vrios produtos diferentes, com configuraes diferentes. Alm disso, um sistema no se compe s de um executvel, mas tambm de tabelas, script (por exemplo, de inicializao ou de manuteno), etc. O diagrama de componentes pode apresentar todas as informaes necessrias para configurar um sistema especifico (quais bibliotecas so necessrias, com quais tabelas, etc.).

Modelar um banco de dados. Um banco de dados se compe de vrias tabelas. E tambm, com a chegada dos data warehouses pode ser necessrio a reorganizao de tabelas de vrios banco de dados dentro de um nico data warehouse. Um diagrama de componentes pode apresentar a agregao de vrias tabelas dentro de um banco de dados.

Exemplo de Diagrama de Componentes

4.4 Diagrama de ImplantaoO diagrama de implantao mostra a arquitetura fsica do hardware e do software no sistema. Pode mostrar os atuais computadores e perifricos, juntamente com as conexes que eles estabelecem entre si e pode mostrar tambm os tipos de conexes entre esses computadores e perifricos. Especifica, tambm, os componentes executveis e objetos que so alocados para mostrar quais unidades de software so executadas em quais destes computadores.

O diagrama de implantao demonstra a arquitetura run-time de processadores, componentes fsicos (devices), e de softwares que rodam no ambiente onde o sistema desenvolvido ser utilizado. a ltima descrio fsica da topologia do sistema, descrevendo a estrutura de hardware e software que executam em cada unidade.

O diagrama de implantao formado de componentes que possuem as mesmas simbologias dos componentes do diagrama de componentes, ns, que significam objetos fsicos que fazem parte do sistema, podendo ser uma mquina cliente numa LAN, uma mquina servidora, uma impressora, um roteador, etc., e conexes entre estes ns e componentes que juntos compem toda a arquitetura fsica do sistema.

Exemplo de Diagrama de Implantao

4.5 Diagrama de PacotesO Diagrama de Pacotes tem por objetivo representar os sub-sistemas englobados por um sistema de forma a determinar as partes que o compem. Pode ser utilizado de maneira independente ou associado com outros diagramas.Notao:

Pacote

Dependncia

Exemplo:

4.6 Diagrama de Estrutura CompostaO Diagrama de Estrutura Composta descreve a estrutura interna de um classificador, como uma classe ou componente, detalhando as partes internas que o compem, como estas se comunicam e colaboram entre si. Tambm utilizado para descrever uma Colaborao onde um conjunto de instncias cooperam entre si para realizar uma tarefa.

4.7 Diagrama de Casos de Uso

Mostra como o sistema vai interagir com os usurios (pessoas ou outros sistemas). O diagrama de classes especifica a estrutura do domnio e do sistema, os casos de usos sero a entrada para formalizar as funcionalidades que o sistema deve cumprir.

Um caso de uso descreve as operaes que o sistema deve cumprir para cada usurio. Ele vai ajudar a formalizar as funes que o sistema precisa fazer. Vamos definir um caso de uso para cada tarefa que o sistema deve cumprir para um usurio.

Por exemplo, para o sistema de reservas, vamos ter um caso de uso para fazer uma reserva, consultar as reservas, suprimir uma reserva, imprimir relatrios, etc.

Um caso de uso se apresenta como uma lista completa das interaes entre um usurio e o sistema para cumprir uma tarefa. Lista completa significa que o caso de uso descreve as interaes desde o inicio da tarefa, ate o fim.

Um exemplo de caso de uso proposto na figura abaixo.

Casos de uso descrevem interaes entre o sistema e os atores. Um ator alguma coisa (usurio, outro sistema,...) que no faz parte do sistema e interage com ele. Por exemplo, para um sistema de regulagem da temperatura, o termostato vai ser um ator, ele interage com o sistema e no faz parte dele.

Um usurio real pode cumprir vrios papis para o sistema (i.e. ser representado por vrios atores), por exemplo, num banco, o gerente pode ser um ator quando ele coloca dinheiro no caixa (ator: operador) e um outro ator quando ele tira dinheiro de sua prpria conta (ator: cliente). Um ator pode tambm representar vrias pessoas, quando falamos de um cliente tirando dinheiro do caixa eletrnico, claro que esse ator representa qualquer pessoa.

Um exemplo de caso de uso

Casos de Uso tm vrios objetivos importantes:

Ser compreensveis para os usurios que provavelmente no entendem de informtica.

Incentivar a anlise do sistema especificando as funcionalidades necessrias.

Delimitar o sistema.

Servir de base para os casos de teste.

O diagrama

O nome de um Caso de Uso pode ser qualquer sentena, mas a UML recomenda usar uma frase ativa curta (verbo + substantivo), por exemplo: entrar reserva, tirar dinheiro, etc.

Representao do diagrama de caso de uso na UMLAssociaesAs associaes representam as interaes ou relacionamentos entre os atores que fazem parte do diagrama, entre os atores e os casos de uso ou entre os casos de uso. Os relacionamentos entre casos de uso recebem nomes especficos (Incluso, Extenso e Generalizao).

Uma associao entre um ator e um caso de uso pode conter uma seta, indicativa do sentido da informao que est trafegando, ou pode no conter setas o que indica que a informao flui nos dois sentidos do relacionamento.

O relacionamento do tipo Especializao/Generalizao uma forma de associao entre casos de uso na qual existem dois ou mais casos de uso com caractersticas semelhantes, apresentando pequenas diferenas entre si. Embora no muito comum, o relacionamento do tipo Especializao/Generalizao, tambm, pode ser aplicado sobre atores.A associao do tipo Incluso costuma ser utilizada quando existe um servio, situao ou rotina comum a mais de um caso de uso. Quando isto ocorre, a documentao desse servio colocada em um caso de uso especfico para que outros casos de uso utilizem-se desse servio. Os relacionamentos de Incluso indicam uma obrigatoriedade, ou seja, quando um caso de uso possui um relacionamento de Incluso com outro, a execuo do primeiro obriga a execuo do segundo.

A associao de Extenso utilizada para descrever cenrios opcionais de um caso de uso. Os casos de uso estendido descrevem cenrios que somente ocorrero em situaes especficas, se uma determinada condio for satisfeita.4.8 Diagramas de Interao Os Diagramas de Seqncia e de Colaborao mostram interaes entre vrios componentes do sistema. Os dois representem a mesma coisa, mas com um foco um pouco diferente, fcil passar de um ao outro. Os dois especificam como os objetos do sistema vo interagir para cumprir alguma funo.

Vamos primeiro estudar os elementos bsicos desses dois diagramas: conexes, mensagens e fluxo de controle.

Diagramas de interao mostram as comunicaes entre os objetos (do sistema ou do lado de fora) para cumprir uma tarefa complexa demais para ser implementada com uma s operao dentro de uma s classe.

Esses dois diagramas podem modelar comunicaes entre ator (fora do sistema) e objeto dentro do sistema quando forem usados para formalizar um caso de uso. Eles podem tambm formalizar a realizao de uma operao complexa por vrios objetos dentro do sistema. Finalmente, podem formalizar os dois ao mesmo tempo: eles especificam uma interao entre objetos dentro do sistema e atores, ao mesmo tempo em que mostram as comunicaes dentro do sistema para cumprir as operaes complexas desejadas pelos usurios.

Conexes

Esses diagramas mostram objetos (instncias de classes e atores) trocando mensagens. Objetos so ligados por conexes (links). As mensagens vo caminhar sobre essas conexes.

Mensagens

Na apresentao do modelo a objetos, dissemos que enviar uma mensagem a um objeto era chamar uma operao desse objeto. Nesses diagramas, as mensagens tm uma significao mais ampla. Uma mensagem pode corresponder a cinco tipos de ao possveis: chamada, retorno, envio, criao e destruio.

O primeiro tipo de ao (chamada) aquela que vimos na apresentao do modelo a objetos.

Uma mensagem de criao (ou destruio) enviada a um objeto significa que este objeto criado (ou destrudo).

Uma mensagem do tipo retorno, usada para mostrar o valor retomado por uma operao (retorno de uma mensagem de chamada).

A mensagem do tipo envio (return code) usada para sinais (o que quer dizer coisas como excees em Java). Sinais no so operaes e no pertencem ao fluxo de execuo normal. Eles so marcas de que um evento determinado aconteceu. Por exemplo, a exceo EndOfFileException produzida quando tenta-se ler depois do fim de um arquivo. A operao que estava lendo pode decidir tratar a exceo (e mudar o fluxo de execuo) ou no. Um sinal no tem retorno, ele enviado e o controle de fluxo e a execuo passam para o objeto que recebe o sinal.Fluxo de controle

A troca de mensagens entre os objetos vai definir um fluxo de controle: um objeto que executa uma operao tem o controle. Um objeto que tem o controle pode:

Continuar a executar sua operao e guardar o controle,

Delegar parte da operao a um outro objeto e passar o controle a esse,

Terminar a operao e retornar o controle ao objeto que lhe passou o controle (chamando sua operao).

Assim, o controle passa de objeto a objeto quando eles trocam mensagens. A passagem de controle entre os objetos chama-se fluxo de controle.

Um fluxo de controle tem inicio quando o sistema (ou processo ou thread) iniciado e continua enquanto o sistema (ou processo ou thread) estiver rodando.

Em um determinado momento, o fluxo de controle pertence unicamente a um objeto. O fluxo de controle s muda de objeto com mensagens. Mensagens so trocadas uma depois da outra, em uma seqncia.

Um sistema pode ter vrios fluxos de controle quando contiver processos e/ou threads. Nesse caso preciso indicar em cada mensagem a qual fluxo ela pertence. No vamos estudar isso.4.8.1 Diagrama de SeqnciaEste diagrama procura mostrar a seqncia de eventos que ocorrem em um determinado processo, ou seja, quais condies devem ser satisfeitas e quais mtodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo especfico. Assim, determinar a ordem em que os eventos acontecem, as mensagens que so enviadas, os mtodos que so chamados e como os objetos interagem entre si dentro de um determinado processo o objetivo principal do diagrama de seqncia.

Um diagrama de seqncia mostra a colaborao dinmica entre os vrios objetos de um sistema.O aspecto mais importante deste diagrama que a partir dele percebe-se a seqncia de mensagens enviadas entre os objetos. Ele mostra a interao entre os objetos, alguma coisa que acontecer em um ponto especfico da execuo do sistema. O diagrama de seqncia consiste em um nmero de objetos mostrados em linhas verticais. O decorrer do tempo visualizado observando-se o diagrama no sentido vertical de cima para baixo. As mensagens enviadas por cada objeto so simbolizadas por setas entre os objetos que se relacionam.

Diagramas de seqncia possuem dois eixos: o eixo vertical, que mostra o tempo e o eixo horizontal, que mostra os atores e os objetos envolvidos na seqncia de determinado processo. Eles tambm mostram as interaes para um cenrio especfico de certa atividade do sistema.

No eixo horizontal esto os atores e os objetos envolvidos na seqncia. Cada um representado por um retngulo de objeto (similar ao diagrama de objetos) e uma linha vertical pontilhada chamada de linha de vida do objeto, indicando a execuo do objeto durante a seqncia, como exemplo citamos: mensagens recebidas ou enviadas e a ativao de objetos. A comunicao entre os objetos representada como linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos. A seta especifica se a mensagem sncrona, assncrona ou simples. As mensagens podem possuir tambm nmeros seqenciais, eles so utilizados para tornar mais explcito a seqncia no diagrama.

Em alguns sistemas, objetos rodam concorrentemente, cada um com sua linha de execuo (thread). Se o sistema usa linhas concorrentes de controle, isto mostrado como ativao, mensagens assncronas, ou objetos assncronos.

Exemplo de diagrama de seqncia na UML

4.8.2 Diagrama de ComunicaoUm diagrama de comunicao mostra, de maneira semelhante ao diagrama de seqncia, a colaborao dinmica entre os objetos. Normalmente, pode-se escolher entre utilizar o diagrama de comunicao ou o diagrama de seqncia.

No diagrama de comunicao, alm de mostrar a troca de mensagens entre os objetos, percebemos, tambm, os objetos com os seus relacionamentos. A interao de mensagens mostrada em ambos os diagramas. Se a nfase do diagrama for o decorrer do tempo, melhor escolher o diagrama de seqncia, mas se a nfase for o contexto do sistema, melhor dar prioridade ao diagrama de comunicao.

O diagrama de comunicao desenhado como um diagrama de objeto, onde os diversos objetos so mostrados juntamente com seus relacionamentos. As setas de mensagens so desenhadas entre os objetos para mostrar o fluxo de mensagens entre eles. As mensagens so nomeadas, que entre outras coisas mostram a ordem em que as mensagens so enviadas. Tambm podem mostrar condies, interaes, valores de resposta, e etc. O diagrama de comunicao tambm pode conter objetos ativos, que executam paralelamente com outros.

Exemplo de diagrama de comunicao.

4.8.3 Diagrama de Interao Geral Este diagrama uma variao do Diagrama de Atividades que fornece uma viso geral do controle de fluxo. Nesse diagrama so utilizados quadros no lugar dos Estados de Ao usados no Diagrama de Atividades, embora smbolos como Ponto de Deciso e o Estado Inicial sejam tambm utilizados nesse diagrama. Existem basicamente dois tipos de quadros:- Quadros de Interao que contm qualquer tipo de diagrama de interao da UML

- Quadros de Ocorrncia de Interao, que normalmente fazem referncia a um Diagrama de Interao, mas sem apresentar seu detalhamento.

4.8.4 Diagrama de TempoO Diagrama de Tempo descreve a mudana no estado ou condio de uma instncia de uma classe ou seu papel durante algum tempo. Tipicamente utilizado para demonstrar a mudana no estado de um objeto no tempo, em resposta a eventos externos.

4.9 Diagrama de Mquina de Estados

O diagrama de mquina de estados tipicamente um complemento para a descrio das classes. Este diagrama mostra todos os estados possveis em que os objetos de certa classe podem se encontrar e mostra, tambm, quais eventos do sistema provocam tais mudanas. Os diagramas de mquina de estado no so escritos para todas as classes de um sistema, mas apenas para aquelas que possuem um nmero definido de estados conhecidos e onde o comportamento das classes afetado e modificado pelos diferentes estados.

Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e sistemas. Eles mostram os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condies sendo satisfeitas) afetam estes estados ao passar do tempo.

Diagramas de estado possuem um ponto de incio e vrios pontos de finalizao. Um ponto de incio (estado inicial) mostrado como um crculo todo preenchido, e um ponto de finalizao (estado final) mostrado como um crculo em volta de outro crculo menor preenchido. Um estado mostrado como um retngulo com cantos arredondados. Entre os estados esto as transies, mostradas como uma linha com uma seta no final de um dos estados. A transio pode ser nomeada com o seu evento causador. Quando o evento acontece, a transio de um estado para outro executada ou disparada.

Uma transio de estado normalmente possui um evento ligado a ela. Se um evento anexado a uma transio, esta ser executada quando o evento ocorrer. Se uma transio no possuir um evento ligado a ela, a mesma ocorrer quando a ao interna do cdigo do estado for executada (se existir aes internas como entrar, sair, fazer ou outras aes definidas pelo desenvolvedor). Ento quando todas as aes forem executadas pelo estado, a transio ser disparada e sero iniciadas as atividades do prximo estado no diagrama de estados.

Um diagrama de estado mostra os possveis estados de um objeto e as transaes responsveis pelas suas mudanas de estado.

Exemplo:

Descrio do exemplo: Modelagem do sistema de login. Para que o usurio seja autenticado, ele deve fornecer dois valores: SSN (Social Security Number) e o PIN (Personal ID Number). Aps a submisso feita uma validao.

Diagrama de estado para o objeto Conta Comum.

Um diagrama de mquina de estados pode estar aninhado. Estados relacionados podem estar agrupados em um nico estado.

Exemplo:

Descrio do exemplo: um sistema de leilo. Para que um lance seja efetuado com sucesso, a oferta tem que ser vlida e o cliente tem que ter crdito suficiente.

4.10 Diagrama de Atividades

Diagramas de atividades capturam aes e seus resultados. Eles focam o trabalho executado na implementao de uma operao (mtodo), e suas atividades numa instncia de um objeto. O diagrama de atividades uma variao do diagrama de estados e possui um propsito um pouco diferente do diagrama de estados, que o de capturar aes (trabalho e atividades que sero executados) e seus resultados em termos das mudanas de estados dos objetos.

Os estados no diagrama de atividades mudam para um prximo estgio quando uma ao executada (sem ser necessrio especificar nenhum evento como no diagrama de estado). Outra diferena entre o diagrama de atividades e o de estados que atividades podem ser colocadas como "swimlanes". Uma swimlane agrupa atividades, com respeito a quem responsvel e onde estas atividades residem na organizao, e representada por retngulos que englobam todos os objetos que esto ligados a ela (swimlane).

Um diagrama de atividades uma maneira alternativa de se mostrar interaes, com a possibilidade de expressar como as aes so executadas, o que elas fazem (mudanas dos estados dos objetos), quando elas so executadas (seqncia das aes), e onde elas acontecem (swimlanes).

Um diagrama de atividades pode ser usado com diferentes propsitos inclusive:

Para capturar os trabalhos que sero executados quando uma operao disparada (aes). Este o uso mais comum para o diagrama de atividade.

Para capturar o trabalho interno em um objeto.

Para mostrar como um grupo de aes relacionadas podem ser executadas, e como elas vo afetar os objetos em torno delas.

Para mostrar como uma instncia pode ser executada em termos de aes e objetos.

Para mostrar como um negcio funciona em termos de trabalhadores (atores), fluxos de trabalho, organizao, e objetos (fatores fsicos e intelectuais usados no negcio).

O diagrama de atividades mostra o fluxo seqencial das atividades, normalmente utilizado para demonstrar as atividades executadas por uma operao especfica do sistema. Consistem em estados de ao, que contm a especificao de uma atividade a ser desempenhada por uma operao do sistema. Decises e condies, como execuo paralela, tambm podem ser mostradas no diagrama de atividade. O diagrama tambm pode conter especificaes de mensagens enviadas e recebidas como partes de aes executadas.

Diagrama de Atividades na UML

Componentes Bsicos

Vamos definir agora os componentes bsicos dos dois diagramas:

Estado: A descrio de uma situao na vida do sistema ou de um objeto em um momento definido. O estado pode ser descrito como o conjunto de valores dos atributos do objeto, com um evento que ele est esperando, ou para uma operao que ele est executando. Nesse ltimo caso, existem dois tipos de estados: estado de ao - enquanto o sistema ou o objeto est executando uma ao - e estado de atividade - enquanto o sistema ou o objeto est executando uma atividade. Um objeto permanece num estado por um tempo finito.

Estado inicial: Um estado virtual que marca o ponto de entrada do diagrama.

Estado final: Um estado virtual que marca o(s) ponto(s) de sada do diagrama.

Ao: Uma execuo atmica. Ela no pode ser interrompida e considera-se que ela dura um tempo no significativo.

Os tipos de aes so: chamada de uma operao, envio de um sinal, retorno de um valor (avaliao de uma expresso, execuo de um clculo), criao de um objeto, destruio de um objeto, ou modificao do valor de um atributo. J vimos que os cinco primeiros correspondem ao envio de uma mensagem. Uma outra classificao seria de dizer que uma ao pode modificar o estado do sistema ou de um objeto ou retomar um valor. Atividade: Uma execuo no atmica composta de aes ou de outras atividades. Por exemplo, a execuo de uma operao para um objeto uma atividade.

Atividades podem ser interrompidas e se considera que suas execues duram algum tempo.

Evento: Alguma coisa que acontece. Existem quatro tipos de eventos: envio de um sinal, chamada de uma operao, passo do tempo e mudana de estado. J vimos dois desses no capitulo precedente, como tipos possveis de mensagens: chamada de uma operao e envio de um sinal.

Uma chamada de operao um evento sncrono, o emissor pra sua execuo e espera a resposta (retorno da operao) do outro objeto.

Sinal: Um objeto nomeado enviado (thrown) de maneira assncrona por um objeto e recebido (caught) por outro.

Sinais so eventos assncronos - ao contrrio das chamadas de operaes que so eventos sncronos - o emissor envia o sinal, mas continua sua execuo sem esperar resposta, nem saber se o outro objeto est pronto para receber o sinal.

Transio: A passagem de um estado para outro. As transies mostram o fluxo de controle de uma atividade (ou ao) para outra.

A passagem de uma atividade para outra pode ser automtica (trigerless), quando a atividade termina e o fluxo de controle passa para a atividade seguinte, ou provocada por um evento, por exemplo, a chamada de uma operao (um dos vrios eventos possveis) vai provocar uma mudana do fluxo de controle e vai iniciar uma nova atividade (execuo da operao chamada).Cliente

Advogado

Parte Contraria

Montar Processo

Notificar Parte

: Concurso

Elaborar Edital

Divulgar Edital

Abrir Inscries

Realizar Provas

Publicar Resultados

Avaliar Provas

{05-01 a 30-01} {31-01 a 15-02} {15-02 a 28-02} {15-03 a 16-03}

{16-03 a 30-04} {01-05}