Curso: UML - Aula 001 - Data da disponibilização: 01/11/2006

O termo orientação a objetos pressupõe uma organização de software em termos de coleção de objetos discretos
incorporando estrutura e comportamento próprios, o que difere muito do desenvolvimento tradicional de softwares,
pois nos mesmos os dados e rotinas são projetados e desenvolvidos de forma fragilmente acoplada.

Se olharmos apenas o mundo da informática (software e hardware) iremos observar que a industria o Hardware
incorporou uma espécie de orientação a objetos, pois na prática já se utiliza a algumas décadas a reutilização de
componentes.

Com todo o avanço que sofreu a informática nos últimos tempos, a orientação a objetos passou a ser uma solução e
um mundo a ser explorado e, este será um dos nossos objetivos, porém vamos relembrar um pouco sobre como
eram os sistemas de informática no passado. Se voltarmos um pouco no tempo, em torno de 25 anos vamos
relembrar do bom e velho Cobol ou ainda do Pascal. As equipes de desenvolvimento utilizavam como ferramenta
para traçar toda a lógica do sistema uma régua de fluxograma e muito papel e desta forma poucos critérios eram
seguidos na derivação de modelagem da fase de análise para a fase de projeto.

Tivemos nos anos 60 a famosa crise de Software, época na qual então surgiu o conceito de engenharia de software
ao final desta década. Entre os principais gênios da época tivemos:

 Dijkstra - um revolucionário da programação estruturada. Para se ter uma idéia do quanto este
profissional "enxergou longe", leia esta matéria (créditos para o site do Professor Grossi) acessando o site:
http://paginas.terra.com.br/informatica/fgrossi/
 Cood - profissional que descreveu o modelo relacional que revolucionou o mercado. Observe um pequeno
histórico deste profissional no site: http://www.teclogica.com.br/noticias/mercado.php?cod=23
 Niklaus Wirth - O pai do Pascal;

Desde então os profissionais de informática tiveram que se acostumar e adaptar a procedimentos e assuntos
relacionados a diagramas de fluxo de dados, diagramas de entidade e relacionamentos, etc.
O amadurecimento da programação orientada a objetos ocorreu nos anos 70 e evoluiu muito com o inicio do que foi
chamado de análise orientada a objetos que veio para deixar mais proximo o mundo computacional do mundo onde
o problema ocorre (mundo real). Com esta nova tecnologia os modelos usados para a análise, projeto e
implementação foram reunidos em um único contexto, alcançando com isso a unificação da perspectiva funcional e
dos dados. Um programa de computador é na verdade uma ação conjunta entre lógica e dados e, com esta visão
poderemos expressar como ocorre basicamente o método de programação tradicional e o método de programação
orientada a objeto:
 

MODELO TRADICIONAL
  
 

MODELO ORIENTADO A OBJETO

As principais vantagens da adoção ao método de orientação a objetos podem ser observadas na sequência abaixo:
 Aumento da produtividade;
 Redução do custo de desenvolvimento;
 Facilitação do processo de manutenção dos sistemas;
 Desta forma, podemos afirmar que em um futuro não tão distante a orientação a objetos será uma
determinante em todas as empresas que desenvolvem e utilizam sistemas informatizados.
Agora que você já teve um primeiro contato com a orientação a objetos, no próximo módulo de aula iremos estudar
um pouco do histórico da Orientação a Obetos.

Curso: UML - Aula 002 - Data da disponibilização: 01/11/2006

Os primeiros conceitos da orientação a objeto foram implementados em uma linguagem de programação que talvez
você nunca tenha ouvido falar, o Simula nos anos 60. Esta linguagem de programação e teve como base a
linguagem Algol. Seu desenvolvimento ocorreu no Centro Norueguês de Computação, com a participação dos
seguintes profissionais:

 Kristen Nygaard;
 Ole-Johan Dahl.

O nome "Simula" foi dado porque a mesma era empregada para o desenvolvimento de simulações e foi a pioneira
no emprego de classes (atributos e métodos) e subclasses, além de encapsulamento e herança. Tivemos duas
versões desta linguagem:
 SIMULA I (1962-65);
 SIMULA 67 (1967).

Você poderá observar um pouco mais sobre esta linguagem no link

http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html.
Uma classe em Simula, é um módulo englobando a definição da estrutura e do comportamento comuns a todas as
suas instâncias (objetos). Na SIMULA, a execução de um programa é realizado de maneira cooperativa, mas não
paralela, seguindo uma organização em corrotinas, de uma coleção de objetos. Os objetos compartilhando uma
estrutura comum são ditos instâncias de uma mesma classe.
A linguagem Simula inspirou a criação da primeira linguagem 100% orientada a objetos na década de 70 e recebeu
o nome de SmallTalk, desenvolvida pela equipe do Centro de Pesquisas da Xerox sob a responsabilidade de Alan
Kay. Tivemos aqui uma exata implementação de conceitos de classe, objeto, atributos, métodos, encapsulamento,
herança e mensagem. O sucesso desta plataforma é um fato, pois atualmente a SmallTalk continua em uso através
de diversos produtos e plataformas.
Ao surgir a SmallTalk, seu principal objetivo era criar um Sistema de Informação integrando interface, sistema
operacional e linguagem de programação. No que se diz respeito à Interface apresentada ao usuário final,
introduziu conceito de dispositivo de "apontar o ponteiro do mouse”, seleção de texto representando objetos, ações
a serem executadas por objetos, tela tipo “bit-map”, entre outros. A partir dai aplicações gráficas ganharam força
por utilizar a orientação a objetos, como o próprio sistema operacional Windows e a linguagem de programação
Java. Podemos então ter uma idéia de como a orientação a objetos evoluiu e continua evoluindo através de
sistemas operacionais, linguagens de programação e plataformas de desenvolvimento.
As linguagens orientadas a objeto são classificadas como híbridas (criada a partir da ampliação de uma linguagem
procedural, mantendo a programação estruturada e adicionando os recursos de orientação a objetos) e puras (só
permite a implementação baseada na programação orientada a objetos).
Como linguagem pura atualmente temos no mercado a SmallTalk (citada acima) e a Eiffel.
A Eiffel tem como base a expressão de propriedades formais das classes pela escrita de asserções. Asserções são
expressões que declaram o que um elemento deve fazer, e não como. Em outras palavras a asserção expressa o
propósito de uma entidade. A importância destas asserções é diminuir as discrepâncias entre a implementação e a
especificação do software. As asserções são usadas para construir pré e pós-condições dos métodos, expressando
requerimentos de corretude do programa.
Agora que já conhecemos um pouco do histórico das linguagens orientadas a objeto, iremos no próximo módulo de
aula estudar sobre os conceitos da orientação a objetos.

Curso: UML - Aula 003 - Data da disponibilização: 01/11/2006

Vamos nesta aula estudar sobre os conceitos da orientação a objetos. O termo orientação a objetos pressupõe uma
organização de software em termos de coleção de objetos discretos incorporando estrutura e comportamento
próprios. Esta abordagem de organização é essencialmente diferente do desenvolvimento tradicional de software,
onde estruturas de dados e rotinas são desenvolvidas de forma apenas fracamente acopladas. Para que fique mais
fácil a compreensão de alguns fatos imagine a rua onde você mora, na mesma existe uma série de casas correto?
Quais as características que estas casas possuem em comum? De imediato poderemos citar diversas, como por
exemplo o fato de todas as casas possuirem porta de entrada na sala, janelas em diversos comodos, banheiros com
vasos sanitários e chuveiros, entre outras características similares.

Após cada um dos moradores realizarem reformas nos imóveis e depois de alguns anos, qual a forma correta de se
calcular o valor de venda de cada um destes imóveis? Teriamos um valor único para todas as casas? A resposta é
não, pois depois de alguns anos e algumas reformas, um imóvel que no ato da entrega das chaves tinha as mesmas
características dos demais, agora pode possuir um acabamento diferenciado o que pode resultar em um valor de
venda maior ou menor e, desta forma cada casa terá um valor de venda diferenciado, ao contrário do que ocorreu
no lançamento do loteamento e venda para os primeiros proprietários.

O mesmo ocorria com a programação de computadores e em alguns casos ainda ocorre, ou seja, o foco da
modelagem do sistema focava apenas as funcionalidades, ou seja, porta abre e fecha, desta forma tudo é porta,
não importando se uma foi fabricada em madeira de lei e a outra em compensado. Se a pintura foi feita com uma
tinta de melhor ou menor qualidade, tudo é tinta e pintura. Desta forma os diferentes módulos que acessam a base
de dados, podem faze-lo de forma desordenada. Assim, ocorrendo uma alteração qualquer na base de dados, os
módulos de forma automática eram afetados e poderiam comprometer o sistema como um todo e o pior, os erros
ocasionados por estas alterações poderiam ser notados depois de diversos meses de operação, comprometendo
todo um processo.

Com o uso da orientação a objetos poderemos de uma maneira mais segura, abstrair situações reais do nosso dia a
dia e iso é fundamental para que o seu sistema tenha vida longa e seja realmente eficiente. A abstração a que nos
referimos é realizada com base em representações do mundo real e são chamadas de objetos.

Mas qual o real significado de abstração? Abstração consiste no fato de focalizar nos aspectos essenciais inerentes a
uma entidade e ignorar propriedades ``acidentais.'' No mundo da programação, isto é o mesmo que um objeto é e
faz antes de se decidir como ele será implementado. O uso de abstração visa preservar a liberdade para tomar
decisões de desenvolvimento ou de implementação apenas quando há um melhor entendimento do problema a ser
resolvido.

No próximo módulo de aula iremos estudar sobre o objeto. Gostariamos de saber a sua opinião sobre as primeiras
aulas deste curso, sua opinião é muito importante para nós. Utilize o formulário de suporte e digite seus
comentários a respeito. Clique aqui para acessar o formulário.

Curso: UML - Aula 004 - Data da disponibilização: 06/11/2006

Nosso próximo objetivo é definir o que é um objeto, que na modelagem de sistemas é considerado como qualquer
coisa existente no mundo real, podendo estar em formato concreto ou abstrato, desta forma ele poderá existir
fisicamente ou apenas conceitualmente.Observe na lista abaixo exemplos de objetos:

 Aluno do curso gratuito de UML;

 Equipe técnica que desenvolve o material didático do curso;
 O computador que você utiliza para acessar o curso;
 A nota que será atribuida ao aluno para o certificado do final do curso;
 A janela do navegador Web que é fundamental para que você tenha acesso as aulas;
 O gráfico presente no inicio desta página;
 O estoque de um determinado item presente em um sistema de controle de estoque, etc.

Observe na listagem acima que todos os objetos relacionados estão presente no nosso dia a dia, de forma direta ou
indireta e, ao moderlamos um sistema baseado no conceito da orientação a objetos, estamos na verdade
modelando estes conceitos que fazem parte do nosso cotidiano.
Observe a imagem ao lado, temos três alunos observando uma aula. Com relação a modelagem voltada a
orientação a objetos, podemos vincular cada aluno a um objeto correto? Mas cada aluno possui características que o
identificam, como por exemplo o nome, o número da carteira de identidade, altura, peso, cor dos olhos, cor do
cabelo, etc.
Podemos então afirmar que os objetos possuem características (também chamadas de propriedades) que são os
seus atributos, que tem o objetivo de identificar o estado de um objeto. Estes atributos visa definir o tipo de dado
ou estado que os objetos da classe possuem, conforme poderemos observar na sequência abaixo, para um dos três
alunos que estão na sala de aula, que possui o nome "Paulo".
Atributos do objeto "Paulo":
 Nome: Paulo Matuszewski;
 Número da carteira de identidade: 123456;
 Número do CPF: 12345678900;
 Endereço: Av. Vitória Régia número 19 - Jardim Motorama - São José dos Campos - SP;
 Sexo: Masculino;
 Data de Nascimento: 12/10/1970;
  Altura: 1.80m;
 Estado civil: casado;
 Profissão: Programador de computadores;
 Pratica esportes: sim;
 ...

Podemos então concluir que os objetos são identificados e diferenciados dentro de um conjunto por seus atributos.
Desde pequenos, quando ainda eramos bebês, nossos pais ofereciam objetos para brincarmos, com cores, texturas
e formatos diversos e, este processo continua por toda a vida (não só com brinquedos é claro), onde identificamos
um objeto por suas características e comportamentos. Por exemplo: aquele objeto de formato circular, que possui
ponteiros que se movem a cada instante ou em um determinado periodo e que utilizamos no pulso... sobre qual
objeto estou me referindo? Com certeza você associou estas características a um relógio e não a uma corrente de
ouro. Para chegarmos a esta conclusão final, passamos por um processo de aprendizagem e associação no decorrer
de nossa vida.
Vamos a outra descrição de um objeto para que você possa associa-lo: possui quatro rodas, três ou cinco portas,
pode ser movido a gasolina ou alcool... nem precisamos mais continuar com a descrição de atributos, pois você já
deve ter associado os mesmos a um automóvel.
Os objetos possuem o que chamamos de identidade e desta forma passam a ser difentes uns dos outros, ocupando
espaços distintos.Isso indica que os objetos se distinguem pela sua própria existência e não pelos valores de seus
atributos. Imagine uma fábrica na sua linha de montagem, onde são produzidas 100 placas de rede de
computadores com as mesmas características, porém cada um com uma identidade diferente, assim sendo
fisicamente são diferentes.
Neste módulo definimos o que é um objeto e o que são os seus atributos. No próximo módulo de aula iremos
estudar sobre os métodos.

Curso: UML - Aula 005 - Data da disponibilização: 06/11/2006

Voltando ao exemplo do relógio, este possui alguns comportamentos, como por exemplo: depois que o ponteiro de
segundos der a volta completa sobre a sua base, o ponteiro de minutos deverá avançar uma das sessenta posições
correto? Podemos então concluir que os objetos possuem comportamentos que modificam o seu estado e que
podem também prestar serviços ou provocar reações em outros objetos. No exemplo que citamos por exemplo, o
objeto "ponteiro de segundo" provaca uma reação no objeto "ponteiro de minutos" após um determinado ciclo.

No dia a dia de sua empresa por exemplo, você é um funcionário e possui uma remuneração mensal. Esta
remuneração é chamada de salário e, em determinados periodos este salário será reajustado, levando-se em
consideração uma série de fatores. O seu salário é um atributo e o reajuste do seu salário é realizado através de
uma determinada operação e neste ponto entra o conceito de método.

Se você já trabalha com programação de computadores, irá associar o método a uma função (neste caso poderia
ser a função de reajustar salário) ou uma rotina (como por exemplo a rotina de calculo de valor das horas extras
trabalhadas, que são fundamentais para a formação do salário).

Os métodos de uma classe podem de forma direta manipular apenas as estruturas de dados daquela classe, não
podendo então acessar de forma direta os dados de outra classe. Para que isso ocorra, será necessário o que
chamamos de solicitação de serviços (execução de operações) e, esta solicitação é chamada de mensagem.

Antes de darmos prosseguimento ao estudo dos métodos, talvez não tenha ficado claro para você o que é uma
classe, conforme citamos acima. A classe é uma descrição de um grupo de objetos com atributos, comportamentos,
relacionamentos com outros objetos e semântica comuns. Uma classe é uma abstração que enfatiza características
relevantes dos objetos, suprimindo outras características. Portanto um objeto é sempre uma instância de uma
classe. Iremos estudar mais sobre as classes em módulos futuros.

Vamos a um exemplo deste processo, onde iremos informar o salário do objeto "Paulo", chamando a operação
"calcular salário".

Vale lembrar que, na modelagem quando estamos trabalhando sobre um determinado objeto, deveremos ter
atenção no que diz respeito ao contexto deste objeto, ou seja, deveremos abstrair as informações deste de acordo
com o papel que este exercerá no sistema, desta forma podemos concluir que o ambiente determinará o limite da
modelagem de cada objeto, pois este possui limites claros com relação ao problema em estudo.

Imagine o exemplo da aula anterior onde citamos o objeto aluno. Em um processo de modelagem do sistema,
muitos atributos do aluno que, apesar de existirem, não necessitam fazer parte do nosso sistema, como por
exemplo o atributo "religião". Para o nosso curso de UML, o que importa a crença religiosa do aluno? Seguindo este
mesmo pensamento, do que importa sabermos a cor dos olhos do aluno? Já se estivermos modelando um sistema
para uma agência de namoros, estes atributos são fundamentais.

Observe a imagem gráfica abaixo:

Quais são os atributos que você consegue identificar na mesma? Poderemos relacionar: cor da linha, cor de
preenchimento, espessura da linha de contorno, entre outras.

E para chegarmos ao objeto gráfico acima, quais foram as operações realizadas? selecionar a ferramenta de
desenho, especificar a espessura da linha, desenhar o objeto, pintar o seu interior.

No próximo módulo de aula iremos estudar as classes.

Curso: UML - Aula 006 - Data da disponibilização: 10/11/2006

Observe a sua volta, com certeza você irá identificar objetos distintos porém que possuem características e
operações similares, vamos a alguns exemplos:

Na figura ao lado estamos observando a foto de uma corrida de carros. Cada carro representa a sua equipe (Ferrari,
Renault, Honda, etc), porém todos tem características e operações similares como por exemplo: ambos possuem 4
rodas, pedais de aceleração e freio, um piloto na direção. Claro que algumas caracteristicas os diferem, como por
exemplo a cor, detalhes de mecânica, entre outros.

Quando identificamos características e operações similares em objetos distintos (cada carro é um conjunto único),
estaremos realizando a sua classificação, ou seja, identificando classes. Uma classe é a representação de um
conjunto de objetos que compartilham a mesma estrutura de atributos, operações e relacionamentos, dentro de um
mesmo contexto (semântica).

Observe a tabela abaixo:

Objeto carro Honda Classe carro de fórmula 1

Equipe: Honda Equipe

Piloto: Rubens Barrichelo Piloto

Que tal um outro exemplo, imagine agora uma sala de aula do curso de informática do Projeto Aprenda em Casa:

Objeto
Paulo
Classe aluno

Nome: Paulo H Matuszewski Nome

Sexo: Masculino Sexo

Data de Nascimento: 01/01/70 Data de nascimento

 Vale a pena ler de novo: Quando identificamos características e operações similares em objetos distintos (cada
carro é um conjunto único), estaremos realizando a sua classificação, ou seja, identificando classes. Uma classe é a
representação de um conjunto de objetos que compartilham a mesma estrutura de atributos, operações e
relacionamentos, dentro de um mesmo contexto (semântica).

Em outras palavras poderemos dizer também que uma classe de objetos descreve um grupo de objetos com
propriedades (chame de atributos) e comportamentos (chame de operações) similares, relacionamentos comuns
com outros objetos e uma semântica comum. Mas o que seria a semântica comum? Por exemplo, Aluno e Escola
são classes de objetos. Cada aluno tem um nome, um sexo e uma idade (estes seriam os atributos comuns da
classe). Escolas também podem ter os mesmos atributos nome e idade definidos. Entretanto, devido à distinção
semântica elas provavelmente estariam agrupados em outra classe que não Alunos. Como se pode observar, desta
forma podemos concluir que o agrupamento em classes não pode considerar exclusivamente o compartilhamento de
propriedades.

Assim sendo, com esta aula sobre classes, acabamos reforçando alguns conceitos sobre objetos, conforme podemos
observar na listagem abaixo:

 Objetos são abstrações de entidades do mundo real (ou de algum sistema) que se auto-gerenciam.
 Objetos são independentes e encapsulam suas representações de estado e de informações.
 A funcionalidade de um sistema é expressa em termos de serviços que os objetos prestam.

Citamos acima o termo "sistema" e, nos mesmos trabalhamos com o que chamamos de "instâncias de classes", que
será o objeto de estudo de nosso próximo módulo de aula.

Curso: UML - Aula 007 - Data da disponibilização: 10/11/2006

Em um sistema as classes trabalham como matrizes e, os objetos (instâncias das classes) ganham vida própria.
Imagine a seguinte situação: O professor de uma determinada escola, de forma técnica desenha a prova que será
aplicada aos alunos, prova esta com textos e espaços para a resposta ou a sequência de opções para a escolha da
resposta correta. Este professor não irá "desenhar" esta prova 250 vezes (imaginando que este fosse o número de
alunos desta escola que realizariam a prova), ao contrário disso este irá tirar 250 cópias deste original. O mesmo
acontece com os objetos, ou seja, temos as instâncias de uma classe, que são os objetos criados a partir desta
classe. Esta classe seria a prova original e cada uma das instâncias as cópias que dela foram extraidas. Observe a
tabela abaixo para compreender melhor:

Classes e instâncias:

Classe Objetos

Aluno Paulo
Aluno Aluno João
Aluno Maria
Aluno José

Prova de Português
Prova Prova de matermática
Prova de conhecimentos gerais

Agora vamos responder a algumas perguntas que certamente você deverá estar fazendo:

Quantos atributos uma classe deve ter?

R: qualquer número ou até mesmo nenhum atributo.

Quantas operações uma classe deve ter?

R: qualquer número de operações ou até mesmo nenhuma.

Assim sendo, poderemos então relembrar o que vimos até aqui da seguinte forma:

Objeto = Atributos + Métodos + Encapsulamento**

O objeto tem atributos:

O objeto "computador" tem: cor do gabinete, fabricante, número de série, tipo do processador...
O objeto "compuatdor" tem métodos: ligar, desligar, reiniciar, instalar softwares...

Classe 

 Conjunto de objetos similares.

 Descreve a:
o Estrutura dos dados; e,
o Comportamento de objetos similares.
 Objeto = Instância de Classe.
 Objetos de uma mesma classe diferenciam-se pelos valores de seus atributos.

Citamos acima o termo **Encapsulamento, mas o que é encapsulamento? Este será objeto de estudo do nosso
próximo módulo de aula.

Curso: UML - Aula 008 - Data da disponibilização: 16/11/2006

O encapsulamento é uma das principais vantagens de se utilizar a orientação a objetos em seus programas, pois o
conceito de encapsulamento está diretamente ligado com o conceito de abstração. Num dado objeto somente
interessa ao cliente as funções que ele executa e não a implementação da mesma. Na parte de interface temos a
descrição das operações que o objeto executa, o que é acessível ao cliente, a implementação de tais operações fica
encapsulada e só é visível ao próprio objeto.

Outro fator fundamental do encapsulamento está no fato de que as classes quando abstraidas de um determinado
problea, deve-se proteger os atributos e operações da mesma, através de sua interface e, isto só se torna possivel
devido ao encapsulamento.

Mas onde entra a interface citada no primeiro parágrafo? Esta serve como intermediária entre a classe e o mundo
externo. Observe o gráfico abaixo, teremos uma boa noção de encapsulamento:

Agora observe o gráfico abaixo, temos a imagem de um HD (disco rígido do computador). De que forma você
observa o encapsulamento neste equipamento?
Resposta: A interface do disco rígido deixa acessível ao computador (cliente) suas funções de leitura e escrita. Por
outro lado os dispositivos mecânicos e eletromagnéticos que o HD utiliza para realizar tais operações não fica
acessível ao seu cliente estando assim encapsulados, porém são fundamentais para que as operações de leitura e
gravação possam acontecer.

Podemos então concluir com o exemplo acima atendemos ao conceito de encapsulamento quando preservamos
informações e operações de cunho privado do conhecimento externo. Já os objetos colaboradores interagem pela
solicitação de serviços (mensagens).

No próximo módulo de aula iremos estudar sobre herança.

Curso: UML - Aula 009 - Data da disponibilização: 16/11/2006

Vamos neste módulo de aula tratar do assunto "Herança" e primeiramente vamos pensar em um aluno de um
curso, o aluno Paulo. Que atributos você identificaria para este aluno? Nome, endereço, data de nascimento,
número da carteira de identidade e CPF, data de inicio do curso, curso, valor da mensalidade, horário do curso,
entre outros. Paulo é um cidadão correto? Podemos então afirmar que todo cidadão tem um nome, endereço, data
de nascimento, número da carteira de identidade e CPF, correto? (esta afirmação está realmente correta). Podemos
afirmar também que todo cidadão participa de um de nossos cursos e assim sendo tem uma data de inicio das
aulas, um valor mensal a ser pago, correto? Esta última afirmação está errada. Nem todo cidadão faz um curso no
aprendaemcasa.com.br. Nesta condição apenas um grupo especifico de cidadãos é que participa de nossos cursos e
que possui estes últimos atributos. Desta forma teremos aqui duas classes: cidadão e aluno.

Porém você observou que muitos atributos são comuns a ambas as classes e, desta forma pensando em um
programa de computador teriamos aqui o que chamamos de redundância ao especificar dezenas de atributos na
classe "cidadão" e repetissemos estes atributos para a classe "aluno". Para um sistema simples (uma simples mala
direta) talvez não fosse problema, porém em um sistema comercial de uma média empresa com certeza poderia
gerar alguns conflitos.

Mas como resolver esta situação? Nestes casos deveremos criar uma classe genérica, chamada de superclasse. Esta
superclasse irá conter atributos que são uteis para diversas classes. Para atender algumas situações poderemos a
partir desta superclasse, criar uma classe mais especifica e que passará a ser chamada de subclasse.

No exemplo acima aprendemos dois novos conceitos por tabela que são generalização e especialização.

Em POO todo objeto de uma classe construída pelo usuário da linguagem é também um objeto de outra classe.
Você conhece Java? Se positivo, analise o objeto "Object" de qual todas as classes são originadas. Por exemplo, na
hierarquia da área da educação, podemos dizer que pessoa é uma superclasse e que os professores formam uma
subclasse de pessoa. Na visão POO podemos afirmar que pessoas é uma classe hierarquicamente superior e que
dela são herdadas características para a formação de novas classes, como: empregados, alunos, professores, entre
outras.

A herança normalmente produz subclasses mais especializadas que as superclasses. Notem que, o termo subclasses
pode trazer a idéia totalmente equivocada de que uma subclasse possa ter menos recursos que a superclasse mas
ocorre exatamente o inverso.

Mas como os atributos de uma superclasse serão associados à subclasse? Aqui que entra o mecanismo de herança
que é parte fundamental das linguagens orientadas a objeto. A classe filha tem como origem outra classe e, assim
sendo pelo mecanismo de herança, codificamos apenas os atributos e operações específicos da classe descendente,
fazendo assim com que esta receba de forma automática, os atributos e operações de todas as classes ancestrais.

Existem dois tipos de herança:

  Herança simples;
 Herança multipla.

Estes tipos serão objeto de estudo do nosso próximo módulo de aula.

Curso: UML - Aula 010 - Data da disponibilização: 20/11/2006

 Herança simples - a subclasse pode herdar variáveis e métodos apenas de uma classe;
 Herança múltipla - a subclasse pode herdar variáveis e métodos de mais de uma classe..

A título de conhecimento, vamos lembrar que uma classe com mais de uma superclasse é denominada "classe de
junção".
Com relação a herança múltipla, uma característica proveniente da mesma classe ancestral encontrada em mais de
um caminho é herdada uma única vez. Imagine a seguinte situação: O atributo "aluno" pertence as superclasses
"A" e "B" de uma classe de junção "C". O atributo "aluno" será herdado em "C" apenas uma vez e, a escolha se este
atributo será herdade de "A" ou "B" é realizado de forma implicita pela linguagem de programação.
A maior vantagem da programação OO é o emprego de bibliotecas de classes. Estas
bibliotecas lembram as bibliotecas de código (procedimentos e funções), utilizadas na
programação modular (quem trabalhou com o Clipper sabe bem o que é isso). As
bibliotecas de classes permitem uma capacidade muito maior de compartilhamento e
reutilização de código, pois é possível criar-se subclasses para atender novas necessidades,
em função das classes já existentes. Muitas bilbiotecas são oferecidas juntamente com as
ferramentas de desenvolvimento para reduzir o tempo e a complexidade de projetos de
software, como a Microsoft Foundation Class (MFC) e a Visual Component Library (VCL)
do Delphi (lembrando que o site aprendaemcasa.com.br oferece o curso completo de
programação Delphi, mais detalhes no link
http://www.aprendaemcasa.com.br/apcasa2.htm). Hoje existe uma crescente indústria de
componentes, ou seja, empresas que dedicam a criar classes que servirão para que outros
literalmente montem suas aplicações finais.
CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.
No próximo módulo de aula iremos estudar sobre o Polimorfismo.

Curso: UML - Aula 011 - Data da disponibilização: 20/11/2006

Vamos neste módulo de aula estudar sobre "Polimorfismo". O sentido da palavra polimorfismo é o uso de um único
nome para definir várias formas distintas. Em linguagens de programação representa o mecanismo que permite que
dois ou mais objetos diferentes respondam a mesma mensagem.

Utilizando uma linguagem mais simples, polimorfismo é o mesmo que "várias formas". Levando este conceito ao
mundo da programação, estamos querendo dizer que podem existir várias formas de executar uma "determinada
tarefa". Aí vem o primeiro ponto de debate, qual seria esta "determinada tarefa"? Na verdade e dentro dos
fundamentos da OO estamos falando de chamadas de métodos. Em Java por exemplo, o polimorfismo se
manifesta apenas em chamadas de métodos.

Assim sendo poderemos complicar um pouco e dizer que o polimorfismo significa que uma chamada de método
pode ser executada de várias formas (entenda polimorficamente). Quem irá decidir esta forma é o objeto que
recebe a chamada e, desta forma estamos finalizando a definição de polimorfismo.
 Vamos a um exemplo "quase prático": Se um objeto "X" chama um método "grito()" de um objeto "b", então o
objeto "b" é que irá definir a forma de implementação do método. Observe que na verdade é o tipo do objeto "b"
que importa, desta forma se a chamada b.grita() vai ser um grito humano se "b" for um humano e será um grito de
macaco, se o objeto "b" for um macaco. O que importa portanto, é o tipo do objeto receptor "b".

Algumas linguagens de programação (como é o caso da C++), você poderá especificar quais métodos são
polimórficos e quais não são.

Observe no gráfico abaixo outro exemplo de polimorfismo:

CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.

Curso: UML - Aula 012 - Data da disponibilização: 24/11/2006

Observe o gráfico abaixo e, defina o que você observa:

 De forma rápida poderemos ter as seguintes respostas:

 É um edificio;
 É um prédio residencial;
 É um Shopping, etc.

Alguns alunos ainda poderão realizar uma descrição mais completa do gráfico acima, como por exemplo: é um
edificio de três andares, com arquitetura moderna, elevador panorâmico, janelas amplas, etc.
Qual o aprendizado que você tira deste exercicio?
( ) As imagens são mais simples de serem compreendidas do que as palavras?
( ) As palavras valem mais do que as imagens?
( ) As imagens confundem a identificação de um objeto?
Se você optou pela primeira opção está correto, porém a simplicidade de uma imagem não poderá em momento
algum deixar de expressar o seu principal objetivo, caso contrário poderiamos confundir um "semáforo" com um
"jogo de luzes para enfeitar a cidade". Jã imaginou o que poderia acontecer se alguém interpretar um samáforo
(sinal de trânsito) com um simples enfeito luminoso?
O mesmo ocorre com um diagrama UML, ou seja, um diagrama deverá expressar de forma clara e correta os seus
objetivos. Mas o que é UML? Você saberia dizer?
Acreditamos que com as aulas anteriores vocês tenham notado a importância da Orientação a Objeto atualmente
para o mundo da informática e começará a entender então o porque da importância da UML.
UML é a sigla de Unified Modeling Language (linguagem unificada de modelagem). É importante frisar que a palavra
linguagem neste caso não representa uma linguagem de programação, porém de comunicação. A UML foi criada,
basicamente, para que analistas e programadores falassem a mesma língua e desta forma poderiamos criar um
padrão de desenvolvimento de softwares.
Um pouco de história
As linguagens de modelagem orientadas a objetos passaram a fazer parte do dia a dia dos desenvolvedores a partir
da segunda metade da década de 1970, à medida que os profissionais envolvidos com metodologia, diante de um
novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais complexas, se viu
forçado a utilizar métodos alternativos de análise e projeto.
A quantidade de métodos orientados a objetos sofreu um grande salto em quantidade (mais de 50) entre os anos
de 1989 a 1994. Muitos desenvolvedores que se utilizaram destes métodos enfrentaram grandes dificuldades para
encontrar uma linguagem de modelagem capaz de atender inteiramente às suas necessidades. Dentre estes
métodos/linguagens:
 Booch (destacava-se durante as fases de projeto e construção de sistemas);
 OOSE - Object-Oriented Software Engineering (fornecia excelente suporte para captura de requisitos, a
análise e o projeto em alto nível);
 OMT - Object Modeling Technique (mais útil com a análise e sistemas de informações com uso de dados);
 Fusion;
 Shlaer-Mellor;
 Coad-Yourdon;

Em meados de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory) e James Rumbaugh
(General Electrics) criadores de métodos orientados a objetos, reuniram as melhores idéias no sentido de criarem
uma linguagem unificada de modelagem. O principal objetivo deste projeto era fornecer ao mercado uma linguagem
mais concreta e madura com os quais os desenvolvedores pudessem trabalhar. Usando técnicas orientadas a objeto
tinha como objetivo gerar uma linguagem que iria desde o conceito até o sistema executável, independete do porte
do sistema. Então em 1994 iniciou-se a criação da UML, oportunidade na qual Rumbaugh se uniu a Booch na
Rational. O foco inicial do projeto era a unificação dos métodos Booch e OMT. O esboço da versão 0.8 do Método
Unificado foi lançado em outubro de 1995. Neste mesmo período Jacobson se associou à Rational com a finalidade
de incorporar o OOSE no escopo inicial da versão 0.8, resultando o lançamento da versão 0.9 da UML em junho de
1996. Foi então aprovada pela comunidade de engenharia de software em geral. Muitas empresas ficaram
interessadas, foi então criada um consórcio com várias empresas interessadas em dedicar recursos com o propósito
de trabalhar uma definição mais forte e completa da UML. Dentre as empresas que mais contribuiram para o
lançamento da UML 1.0 foram:
 Digital Equipment Corporationm;
  Hewlett-Packard;
 I-Logix;
 Intel-licorp;
 IBM;
 ICON Computing;
 Microsoft;
 Oracle;
 Rational;
 Texas Instruments;
 Unisys.

e desde então a UML vem evoluindo e ganhando novas versões, após a apresentação da
UML no ano de 1997 à OMG, que é uma organização internacional que promove a teoria e
prática da tecnologia orientada a objeto em desenvolvimento de sistemas.
CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.
 

Curso: UML - Aula 013 - Data da disponibilização: 02/12/2006

Um método é composto por dois objetos distintos:

 Uma linguagem de modelagem;

 Um processo .

A linguagem de modelagem tem por principal objetivo oferecer uma notação gráfica do método, já um processo tem
como principal objetivo informar os passos para a elaboração de um projeto.
Em qual dos objetos citados acima poderemos enquadrar a UML?
Resposta correta: Linguagem de modelagem.
Mas então ela não implica na estrutura de um processo?
Resposta correta: Não diretamente, ou seja, a estrutura da UML direciona para a criação e leitura de seus modelos,
sem especificar quais e em qual momento estes modelos devem ser criados, tarefa esta vinculada ao processo de
desenvolvimento. Com esta afirmação podemos concluir também que a UML é independente do processo.
Então qual seria o principal objetivo da UML?
Resposta correta: gerar uma forma padronizada, tendo como objetivo principal a preparação de planos de
arquitetura de projetos de sistemas. Desta forma é um importante instrumento para direcionar as decisões relativas
ao desenvolvimento e implantação de sistemas.
Com a UML poderemos mapear os modelos para as linguagens de programação, fator este determinante para
criarmos softwares práticos e que atendam ao mercado.
Existe outra vantagem para o uso da UML?
Resposta correta: Sim, pois de forma indireta estamos documentando o sistema e seus artefatos (são considerados
artefatos em um sistema: projeto, código fonte, planos do projeto, versões, entre outros).
Teriamos como definir melhor a expressão "modelagem"?
Resposta: A modelagem é uma parte central de todas as atividades que levam à implantação de software confiável.
Construímos modelos com o objetivo principal de comunicar a estrutura e o comportamento desejados do sistema,
para visualizar e controlar a arquitetura do sistema, para compreender melhor o sistema que estamos projetando e
desta forma estaremos visualizando as possibilidades de simplificação e reaproveitamento.
Através da UML só posso modelar Softwares?
Resposta correta: Na maioria das vezes a UML é empregada na modelagem de Softwares usando o conceito de
orientação a objetos, porém seu uso não está limitado a este campo de utilização, podendo ser aplicada também
 em sistemas mecânicos, de engenharia em geral, entre outros. Nosso curso está focado no desenvolvimento de
software, porém poderá ser facilmente adaptado a outras necessidades.
 
CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.
 

Curso: UML - Aula 014 - Data da disponibilização: 02/12/2006

Quando construímos modelos estamos de forma direta estruturando nossa idéia, nosso pensamento sobre uma
determinada situação/solução, ou seja, um modelos estará diretamente vinculado a algo com um propósito. Se o
modelo não possuir um fim específico, teremos um modelo sem inicio, meio e fim e esta situação para um
programa de computador é desastrosa, pois será um software sem finalidade ou o pior, que consiga solucionar um
problema proposto. Uma linguagem de modelagem consiste de notação (os símbolos), e três regras básicas,
conforme poderemos observar abaixo:

 Sintaxe: informa como os símbolos devem parecer, e como combiná-los. A sintaxe é comparada às
palavras da nossa lingua, sendo fundamental saber como "soletrá-las" corretamente e como colocar as
palavras juntas de forma a construir uma sentença que faça sentido e expresse seu objetivo;
 Semântica: informa o que cada símbolo significa e como deve ser interpretado por ele mesmo e no
contexto do sistema. Seria como um dicionário da nossa lingua Portuguesa.
 Pragmática: informa a intenção dos símbolos a partir do momento em que o propósito do modelo é
ativado e entendido pelos outros. É correspondente às regas de construção de sentença na linguagem
natural, que são limpas e compreensíveis.

É fundamental a observação destas três regras básicas. Desta forma com o que observamos neste módulo de aula e
no anterior, poderemos enumerar as seguintes metas de um projeto UML:
 Fornecer a desenvolvedores e outros profissionais uma linguagem de modelagem visual, pronta para o
uso, que obedeça um padrão específico e que seja expressiva;
 Oferecer suporte a especificações, independente de processos de desenvolvimento e as linguagens de
programação empregadas no mesmo;
 Oferecer uma visão clara de ferramentas de objetos;
 Oferecer suporte a alto nível de conceitos de desenvolvimento.

No próximo módulo de aula iremos estudar sobre os elementos fundamentais para a modelagem com o UML.
 
CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.
 

Curso: UML - Aula 015 - Data da disponibilização: 06/12/2006

Na UML existem elementos fundamentais que visam possibilitar a modelagem do sistema. Entre estes elementos,
destacamos:

 Blocos de construção;
 Regras de formatação.

Vamos iniciar nossos estudos sobre os blocos de construção, que são divididos em:
 Elementos do modelo;
 Relacionamentos;
 Diagramas.

Os elementos do modelo reúnem os elementos fundamentais para o emprego na modelagem

e se dividem em:
Elementos de
incluem
modelo

 Classes;
 Interfaces;
 Colaborações;
 Casos de uso;
Estruturais
 Classes ativas;
 componentes;

 Nós.

 Interação;
Comportamentais
 Estado.

Agrupamento  Pacotes.

Anotacionais  Notas.
Mas quais as características destes elementos? Vamos estudar a dos principais a seguir:
Elemento de modelo estrutural - Classes: também chamado de "Class", tem o objetivo de representar e
descrever um conjunto de objetos que compartilham atributos, operações, relacionamentos e semântica.
Elemento de modelo estrutural - Interfaces: também chamado de "interface", representam as operações
externamente visíveis de uma determinada classe.
Elemento de modelo estrutural - Colaborações: também chamado de "collaboration", visam apresentar as
instâncias e respetivas colaborações entre elementos comuns a uma determinada tarefa.
Elemento de modelo estrutural - Casos de Uso: também chamado de "use case", tem a função de descrever de
forma clara e objetiva as ações, organizadas sequencialmente que poderão serem executadas pelo sistema, desta
forma estaremos obsevando a funcionalidade deste. Aqui a troca de informações são realizadas pelo que chamamos
de atores (definição esta que ficará clara no decorrer do curso).
Elemento de modelo estrutural - Classes Ativas: também chamado de "Active Class", representa qualquer
atividade de controle exercida pelo sistema.
Elemento de modelo estrutural - Componente: também chamado de "component", corresponde a um elemento
do sistema, representado por um módulo.
Elemento de modelo estrutural - Nó: também chamado de "node", representa um recurso computacional e que
poderá ser observado em tempo de execução.
No próximo módulo de aula iremos estudar sobre os elementos de modelo comportamentais.
 
CONVITE ESPECIAL PARA OS ALUNOS DO CURSO DE UML

Estaremos lançando a partir do mês de dezembro o curso "Java (incluindo acesso a

banco de dados)". Neste curso o aluno terá direito além do acesso ao material
didático, suporte e certificado (nos mesmos moldes do curso de UML). Os alunos que
já participam do curso de UML terão direito a um desconto especial e pagarão apenas
R$ 20,00 (vinte reais) pelo curso completo. Caso tenha interesse em participar do
curso e garantir sua vaga com valores especiais, mande um e-mail para
java@aprendaemcasa.com.br através do seu e-mail cadastrado no curso UML, citando
 ainda seu nome completo, username e password e em seguida estaremos enviando
sem compromisso detalhes do curso em questão.

Curso: UML - Aula 016 - Data da disponibilização: 07/12/2006

Elemento de modelo Comportamental - Interção: também chamado de "interaction", representa uma forma
definida de comunicação, que tem como principal finalidade a realização de uma determinada tarefa.

Elemento de modelo comportamental - Estado: também chamado de "state", representa uma condição de uso
de um determinado objeto, podendo ainda representar a interação proveniente da execução de uma determinada
condição, bem como quando o mesmo aguarda um evento.

Elemento de modelo de agrupamento - Pacotes: também chamado de "package" representa o grupo de

elementos de um determinado modelo.

Elemento de modelo anotacional - Nota: também chamado de "note", contém informação sobre a forma de
texto visando representar informações que vão de comentários a descrição de métodos.

No próximo módulo de aula iremos estudar sobre os relacionamentos.

Curso: UML - Aula 017 - Data da disponibilização: 18/12/2006

O relacionamento tem por principio realizar a ligação, entre si, dos elementos que compõe o modelo. Os
relacionamentos são divididos em quatro grupos principais, conforme podemos observar em destaque abaixo:

 Relacionamento de dependência;
 Relacionamento de associação;
 Relacionamento de generalização;
 Relacionamento de realização.

Relacionamentos de dependência
É um relacionamento semântico entre dois itens nos quais a alteração de um dois itens nos quais a alteração de um
(o item independente) pode afetar a (o item independente) pode afetar a semântica do outro item (o item
semântica do outro item (o item dependente). Este tipo de relacionamento é chamado também de "dependency".
A relação de dependência pode auxiliar por exemplo no escalonamento dos objetos em um sistema que irá operar
em rede local, pois através de uma análise do modelo poderemos apontar os objetos com grande dependência e
fazer com que os mesmos sejam organizados em uma mesma máquina e objetos com pouca dependência estejam
em máquinas distintas, melhorando consideravelmente o tráfego de informações na rede.
Quando uma classe recebe um objeto de outra classe como parâmetro, uma classe acessa o objeto global da outra.
Nesse caso existe uma dependência entre estas duas classes, apesar de não ser explícita. Se você já estudou ou
programa em linguagem C, deve conhecer o que chamamos de classes amigas, o que é um exemplo claro de
relacionamento de dependência.
Se você está acostumado a administrar e programar Sistemas Gerenciadores de Banco de Dados, em um modelo
cliente-servidor temos outro exemplo de relacionamento de dependência, pois expressa claramente que um agente
de uma organização requer o serviço de um agente em uma outra organização.
Existe um relacionamento de dependência entre duas classes quando:
o um objeto da classe servidora é passado como parâmetro de um método da classe cliente;
o um objeto da classe servidora é declarado localmente em um método da classe cliente;
o um objeto global da classe servidora é acessado pela classe.

 
No próximo módulo de aula iremos estudar sobre o relacionamento de associação.