Aqui a gente vai passar pra um exercício dois.
Crie uma classe Departamento em UML
e depois em C++
que permita agregar a um objeto
de Departamento na classe Universidade.
A classe Pessoa deve possuir uma referência ao Departamento
que trabalha, ou seja:
Ela deve possuir uma associação para com a classe Departamento,
permitindo que cada objeto Pessoa tenha a referência de um objeto Departamento.
Então, aqui é interessante, tá, porque vejam só
a gente já tinha proposto esse exercício aqui pra vocês
no final da última exposição
lá no grupo de slides número dois.
Só que lá, ele pedia apenas em C++,
e agora eu tô pedindo tudo isso aqui, também em UML.
Então, você pode fazer agora nesse momento se quiser,
uma pausa no vídeo
de maneira tal que você vá cumprir esse exercício.
Antes de você retomar aqui a apresentação
procure baixar lá o StarUML,
ou a ferramenta CASE da sua preferência
se você já tem alguma, já fez algum trabalho assim,
e faz essa modelagem aqui.
Daí depois, venha aqui reacompanhar o vídeo, tá,
que eu vou continuar explicando
como isso se resolve, tá.
Comparar a sua solução com a solução que eu vou propor
aí, já já pra vocês.
Bom, pessoal, eu vou passar então aqui pra
solução justamente do exercício, tá.
Começando pelo que tá sublinhado aí
Criar uma classe Departamento, em UML e depois em C++,
que permita agregar um objeto de Departamento na classe Universidade.
Obviamente, eu vou começar pela modelagem.
Vou começar a modelagem do ponto de vista de análise.
Aí está.
Percebam que que eu fiz aqui.
Fiz uma agregação-forte.
Universidade agregando uma classe Departamento.
Muito bem, isso dito,
aqui tá a classe ela mesmo modelada.
Aparentemente, eu coloquei um inteiro id ali,
um nome char 100,
construtora e destrutora, getId(),
setNome() e getNome().
Professor, mas o exercício não pedia esse id.
Então tu tira.
A modelagem permite a gente propor o que a gente tá pensando,
e ir refinando, tá.
Modelagem é algo que a gente trabalha um pouco em espiral,
pra alcançar o modelo que a gente tá buscando.
Aqui é uma... ainda algo de análise,
Você veja que eu tô só olhando os relacionamentos que existiriam
no mundo que eu tô modelando
ou, pelo menos, à luz de um mundo que eu tô idealizando
segundo os requisitos.
Tá ali o relacionamento de conhecer entre Pessoa e Universidade, já discutido.
E agora eu tô dizendo que Universidade agrega
um Departamento.
É uma agregação-forte, composição,
nesta análise, porque assim é... assim o é
no sistema real analisado.
É, se a gente olhar a nossa Universidade
a gente vai, ou as Universidades em geral,
a gente sabe que na prática
o Departamento ele faz parte da Universidade, tá.
A Universidade se compõe de Departamentos.
ou coisa que o valha.
No caso da UTFPR, você vai ter o DAINF, o DAELN, o DAMEC, né.
O DAMAT, o DAFIS e assim vai.
Então, parece razoável colocar uma agregação-forte ali.
O resto a gente já conhece
lá eu tenho a associação de Pessoa com Departamento.
Agora eu vou sair da Análise e vou pro Projeto.
Aqui, ó, tô contando que
Pessoa tem um pUnivFiliado.
Agora tô mostrando que o objeto Departamento...
Aqui, dpto.
É dpto da classe Departamento,
dpto da classe Departamento, está de fato dentro de Universidade
Este relacionamento de Conhecer aqui,
que também faz parte, na prática, do exercício proposto, tá,
bem entendido,
da Pessoa Conhecer Departamento.
Aqui, antes, ali no slide anterior tava só em termos de Análise,
agora a gente começa a entrar em termos de Projeto.
Porque eu tenho ali, ó, pDptoFiliado.
Ponteiro Departamento.
Professor, ele tá público aqui.
Privem, deixem privado.
Modifiquem lá. Façam os ajustes.
A professor aqui tá escapando um pouquinho ali, ó.
Arrumem ali, não tem problema.
O fato é que agora eu tô modelando a coisa
antes de chegar no código.
Aqui eu vou fazer uma pequena observação
com relação a essa agregação aqui, tá.
Universidade agregar Departamento.
Se olhar, tanto em termos de Análise
quanto em termos de Projeto,
é, indubitavelmente, uma agregação-forte.
No mundo real,
o Departamento está dentro de Universidade.
Universidade se compõe de Departamentos.
E o Departamento ele vai estar só em uma Universidade, né,
Então, o nosso DAINF ele tá só na UTFPR.
Lá a Federal tem o equivalente ao DAINF deles.
Mas cada qual tem o seu.
Cada um tem o seu coração.
Coração tá em cada Pessoa.
Cada qual tem o seu objeto coração de si.
Muito bem.
Aqui ademais se você olhar também em termos de Projeto,
Aqui, ó, seja no projeto, eu tô vendo ali, ó,
o objeto dentro da classe Universidade.
dpto do tipo Departamento.
Então, eu posso ter, no mundo real
uma coisa dentro da outra
e a hora que eu trago isso pro mundo da orientação a objetos
aqui em termos de análise e programação
eu posso ver se eles se mantenham assim.
De fato o departamento vai estar dentro de Universidade
É o caso, ó,
aqui eu mantive a lista de departamento.
Professor, mas Universidade tem vários departamentos, não tem um só.
É verdade.
A gente vai trabalhar isso daqui a pouco.
A gente vai expandir a capacidade de Departamentos em Universidade.
A gente tá indo devagarinho, né, passo a passo pra entender melhor o conceito, tá.
Em termos de projeto,
ó o comentário aqui,
é uma composição, ou agregação-forte, porque será implementado assim.
Legal.
Solução pra agregação-forte ou composição.
A composição é caracterizada pelo fato
do agregado só poder pertencer efetivamente a um agregador.
Conforme já dito.
E ali o losango preenchido.
Muito bem, agora que a gente já fez essa análise, já fez as considerações,
Análise e Projeto, já fez as considerações,
passamos à implementação.
Tá aqui a classe Departamento que não tinha.
Agora tem.
Professor, tá faltando o atributo id, aqui.
Ora, se tá lá no modelo, se você manteve o modelo
coloca aqui, se você tirou do modelo,
então ok não ter aqui.
Aqui tá aquele código de pré-compilação, né
pra evitar inclusões repetitivas,
que a gente já discutiu.
Ou pode substituir todo esse código em verde por
#pragma once
Mas enfim, aqui eu fiz de maneira tradicional
.h respectivo .cpp.
Aqui é um comentário, tá,
eu posso ter mais includes lá, mas por enquanto
é só um comentário, então essa linha é ignorada em termos de compilação.
"//" é comentário em C++.
Ainda que o comentário "/* */" continue funcionando
tal qual em C,
mas aí eu tenho esse incremento de "//" comentário de linha.
Legal.
Aqui tá a construtora sem parâmetros,
destrutora vazia,
set e getNome(), nada demais.
Vamos pra classe Universidade.
Isso é uma versão zero que a gente tá chamando, tá.
A gente vai modificar um pouco essa solução.
Aqui, no caso, da classe Universidade
de fato, tal qual o modelo
tanto o da análise quanto o do projeto trouxeram
o Departamento que eu tô chamando internamente de pdpto
Professor, por que não tá chamando de DAINF?
Porque aqui eu não sei qual Departamento que vai ser
se vai ser DAINF, DAMAT,
então eu dei um nome mais genérico internamente.
Dpto que é do tipo Departamento.
Aqui nessa evolução que eu tô mostrando da classe Universidade, né,
agora ela passa a ter, além do que a gente já tinha discutido anteriormente
ela passa a ter também uma nova função.
Chamada setNomeDepartamento().
É aqui que eu vou passar um vetorzinho de caractere.
Tá ali, ó.
Que vai alimentar o nome do Dpto.
Então setNomeDepartamento()
quando eu passo isso pra Universidade
eu pego esse parâmetro
e repasso pro objeto agregado,
que é o Dpto por meio de setNome().
Bem entendido.
Muito bem, se eu for na Principal agora, em termos de objetos,
o que eu vou ter é isso aqui, tá.
Eu vou ter a UTFPR
eu vou ter o Princeton e eu vou ter o Cambridge,
e cada qual tem, dentro de si,
como vocês tão vendo aí, um Dpto.
Um Dpto.
Aí fica bem em termos de objetos, né,
Fica de fato bem entendível,
que o Departamento está dentro da UTFPR.
Por exemplo o Diagrama de Objetos que vocês tão vendo aí exposto em tela.
Agora, eu posso propor uma outra solução,
em termos de projeto, que é a seguinte.
Bom, fazendo um parênteses aqui, antes de ir pro seguinte slide.
Qual é a parte boa disso?
Porque de fato o Departamento está dentro de cada Universidade.
Tá vendo, ó, cada qual tem o seu Dpto.
A parte ruim é que eu tenho uma dificuldade pra colocar um nome interno pro objeto, né.
Um nomezinho mais mnemônico, né, mais representativo.
Eu tenho que colocar um nome genérico.
Tem alguma outra maneira de eu não ter que usar um nome genérico? Tem.
Só que você vai ter que mudar um pouco a solução.
E é isso que daí
tá no próximo slide
fechando o parêntese aqui.
Eu posso modificar, tá
a minha Análise, perdão o meu Projeto,
Muito embora na análise eu tinha colocado
que o Dpto está dentro da Universidade
aqui eu posso mudar, através de um ponteiro
não é mais um Dpto, é um pDpto,
porque é um ponteiro Departamento.
Solução por agregação-simples ou fraca
agora em termos de Projeto.
Se você olhar em termos de Análise que é outra coisa
lá é em termos mais genéricos.
No mundo real o Departamento está dentro da Universidade.
Aqui, em termos de Projeto,
eu tô modificando, eu não tô criando de fato
o Departamento dentro da Universidade
eu tô colocando um apontamento.
A agregação-simples é caracterizada pelo fato do agregado
poder eventualmente pertencer (fracamente) a mais de um agregador.
Se é um ponteiro, um ponteiro permite isso.
Um cara pode ser apontado por diversos outros caras.
Em termos de projeto é uma agregação-simples,
porque será implementado por meio de ponteiros, ou seja,
não tá ali dentro, ele tá só referenciado.
Professor, então
o ponteiro ele não serve só pra associação?
Não.
Ponteiro serve pra uma série de coisas.
Serve inclusive, pra representar associação,
pra tratar associação.
Muito utilizada pra tratar associação,
mas ele também ser pra representar agregação-fraca.
Aqui, em termos de Projeto
eu optei por representar por agregação-fraca
que é isso aqui, ó,
simplesmente, porque em termos de Projeto
se eu olhar aqui, não tem de fato ali dentro
o objeto, tem só um ponteiro.
Essa foi uma opção, isso aqui é polêmico.
É polêmico porque tu tem...
Projetistas que vão dizer o seguinte:
Opa, alto lá,
tudo bem que você tá usando um ponteiro aqui pra representar
em termos de Projeto,
mas se você olhar na Análise
é uma agregação-forte
e mesmo que você esteja usando um ponteiro aqui
na prática a Universidade
vai apontar pra só
pra este Departamento e o Departamento vai estar apontado
apenas por essa Universidade em questão.
Então, mesmo que em termos de Projeto,
aqui eu tô já usando um ponteiro,
eu devo manter esse relacionamento aqui
Departamento estar agregado apenas,
estar relacionado apenas com uma Universidade
eu deveria fazer outramente manter aqui o losango forte,
manter a agregação-forte,
mesmo que eu esteja usando um ponteiro.
Então você tem essas duas vertentes em termos de Projeto, tá.
Olhar só o código e falar: Ah, mas é que é ponteiro aqui
eu não tô vendo o objeto ali dentro efetivamente
então eu vou... mas eu sei que isso é oriundo de uma agregação
então vou usar uma agregação-fraca, em termos de Projeto.
A outra vertente é esse raciocínio que eu acabei de fazer, aí,
dizendo o seguinte, não interessa
se lá no agregação... lá no Projeto...
lá, perdão, lá na Análise,
lá no mundo real, o Departamento está agregado
dentro da Universidade fortemente,
a Universidade se compõe dele
por mais que se use o artifício de ponteiro
pra representar essa agregação
continua, você vai continuar usando forte aqui.
São duas vertentes.
O importante é você
usar uma das duas e se manter coerente com ela
isso que é o importante.
E até por isso que eu trago esse slide aqui, tá,
pra fazer essa reflexão, aí, com vocês.
Se você optar por opção de olhar
não, eu vou sempre respeitar o que tá na Análise
se na Análise tá dizendo que é forte
por mais que eu implemente aqui
através de um artifício de ponteiro,
ali onde tem um objeto dentro, efetivamente, dentro do código,
então eu vou continuar usando a representação de agregação-forte.
Ok.
O importante aqui é você manter a coerência
e você esteja de acordo com o teu time e o teu time também manter a coerência.
Vai tá ok.
Muito bem.
De qualquer forma, se você utilizar o artifício de ponteiro aqui,
pra representar uma agregação
seja essa agregação representando uma agregação-forte na origem
ou até uma fraca na origem, ou até na análise,
quando você usar um ponteiro você vai implementar via ponteiro.
Então, aqui, ó, eu passo a usar um pDpto.
Aqui é um ponteiro de Departamento.
A solução aqui
é uma solução boa,
porque ela é um pouco mais flexível
em termos dos nomes dos objetos que eu vou criar depois
e que vou apontar aqui
e através desse apontamento eu vou representar minha agregação.
A parte ruim é que
não fica tão explícito quando eu uso um ponteiro que é uma agregação
eu tenho que olhar o modelo de Projeto e/ou Análise
pra entender que é uma agregação.
Se você olhar aqui o set,
esse set aqui que antes era setNomeDepartamento()
naturalmente agora ele virou um setDepartamento, né.
Não recebe mais um nome
ele recebia aquele nome pra colocar no objeto,
agora eu não tenho objeto eu tenho ponteiro,
então o que eu recebo aqui é só o ponteiro
que é armazenado em pDpto internamente.
Se você... tudo fica mais entendível agora no próximo slide, 34.
que você vê que nessa solução V1 aqui,
que não é mais a solução Versão 0 é a Versão 1.
Você agora tem, dentro do Principal, os Departamentos...
Perdão, as Universidade, perdão,
e também os Departamentos.
porque agora eu posso dar nome pros departamentos explicitamente.
DAELN, FisicaPrinceton, MatematicaCambridge.
E daí aqui que eu faço a UTFPR
agregar o DAELN conhecendo o seu endereço.
Faço Princeton agregar FisicaPrinceton,
conhecendo o endereço de FisicaPrinceton.
Faço Cambridge agregar MatematicaCambridge,
conhecendo o endereço de MatematicaCambridge.
E bem entendido que isso aqui é uma agregação
animada por meio de ponteiros
e não pela criação explícita do objeto dentro de outro objeto.
Então, em termos de memória, fica assim.
A gente sabe olhando o modelo na origem,
particularmente, na análise nesse caso
que isso aqui tá querendo representar uma agregação.
O que é peculiar, mas a gente vai se acostumar com isso no...
no porvir do... das explicações
e dos próximos exercícios, inclusive.
Muito bem.
Aí, no tocante ao exercício 2
eu sublinho essa parte aqui.
A classe Pessoa deve possuir uma referência
ao Departamento que trabalha,
ou seja, ela deve possuir uma associação com a classe Departamento,
permitindo que cada objeto Pessoa tenha
a referência de um objeto Departamento.
Outramente dito,
agora eu faço a classe Pessoa
ter o ponteiro pDptoFiliado
que já tinha sido modelado, lá, anteriormente.
Estou indo direto pro código nesse instante preciso.
Aqui eu vou ter o setDepartamento
se eu tenho setUnivFiliado(), eu tenho um setDepartamento().
Professor, por que você não chamou de setDepartamentoFiliado()?
Foi um instinto no momento, tá.
Poderia chamar aqui de setDepartamentoFiliado()
Vocês podem fazer isso, inclusive,
na versão de código de vocês, né.
Cada um de vocês tem a sua versão de código
do seu Sistema Acadêmico.
Vocês vão se inspirando no meu,
mas vão fazendo as melhorias, os ajustes,
as experimentações de vocês.
Eu quero que cada um tenha a sua base experimental,
para poder evoluir nessa criação
e aprimoramento de conhecimento de programação orientada a objetos,
modelagem e programação orientada a objetos.
A nossa versão você pode mudar, então, pra setDepartamentoFiliado()
Legal.
Se aqui em OndeTrabalho(), conforme já dito
no final da exposição anterior,
eu consigo que a pessoa informe o seu nome
por colaboração com a Universidade
a Universidade informando o dela,
o que leva ao resultado colaborativo de
da Pessoa informar o seu nome e em que Universidade trabalha.
Aqui eu consigo no QualDepartamentoTrabalho(),
outra funçãozinha que eu criei nesse momento,
O cara informa o seu nome
pede pra Universidade filiada informar o seu nome
e aí ao Departamento filiado informar seu nome.
Aqui, na verdade, no âmbito dessa função,
na prática, três objetos colaborando.
Objeto Pessoa que é o objeto origem, nesse caso,
e mais os dois objetos apontados,
pUnivFiliado e pDptoFiliado e cada qual
informa seu nome a pedido, aqui, à demanda
imperativa da pessoa em questão.
Aqui eu tenho então, por exemplo, o Simao, UTFPR e DAELN.
Se eu olhar lá
o Simao conhece a UTFPR
e conhece o DAELN
Simao conhece aqui, ó, setUnivFiliado o endereço da UTFPR
e o Simao conhece o endereço do DAELN.
São essas duas linhas de código aqui,
que eu tô mostrando aqui, apontando com o mouse,
que permite o Simao se relacionar
se associar com os dois objetos pertinentes
UTFPR e DAELN, né,
através dos apontamentos, tá.
Eu vou voltar um slide aqui, tá,
que permite que essa colaboração aqui ocorra.
Muito bem.
Atenção com as próximas versões, tá.
Essas duas versões aqui, versão V...
V2 e V3 a gente tinha feito lá um...
um V0 e um V1, tá.
Fazendo aquela reflexão sobre
enxergar algo do ponto de vista de agregação-forte e agregação-fraca.
Outramente dito se você tem de fato, em termos de Projeto,
se você tem um objeto dentro do cara
você tá representando a agregação por meio de um apontamento.
Legal, a gente já debateu aqui, então esse assunto tá resolvido supostamente.
Agora, além da versão 0 e a versão 1
eu tenho a versão 2 e 3 que são ruins.
Primeiro eu tenho uma demanda ali, queiram entender o porquê.
Supostamente você pode parar o vídeo agora,
pegar os slides ir um pouquinho lá pra frente
e entender o porque disso estar errado, tá.
Eu em ato contínuo vou trazer a solução aqui pra vocês, tá.
Imaginem que eu resolva aqui, por equívoco,
por experimentação, sei lá eu.
No setDepartamento() ao invés de ter aqui
um ponteiro, ou retificando o que eu tô falando, tá.
Se olhar a classe Universidade como um todo,
se eu olhar aqui o Dpto
a Universidade, nessa versão aqui,
não tem mais ponteiro, ela para de ter ponteiro,
ela volta a ter um objeto dentro de si,
que é uma das soluções que a gente já debateu.
Só que interessantemente aqui
ela mantém a função setDepartamento().
Ela tá recebendo um ponteiro aqui,
mas daí como é que eu conecto as duas coisas?
Tá lá, ó.
Eu recebi um ponteiro, daí eu faço
que o Dpto, ou seja, que o Departamento que eu tenho
dentro da Universidade
copiar o valor de todos os atributos
do cara apontado por dep.
Ali, ó, tem o asterisco na frente aqui, ó.
Asterisco eu pego o conteúdo da coisa apontada.
Então, esse dep que tá apontado em algum lugar,
na verdade, Dpto vai ser uma cópia dele.
Isso é complicado, tá.
Isso é complicado, porque, neste caso,
o objeto Dpto será uma cópia,
um clone do dep, aqui em maiúsculo, tá,
passado por parâmetro.
Neste caso, o objeto Dpto
será uma cópia, um clone, do dep passado por parâmetro.
Parâmetro por valor, bem entendido.
Isso pode ser feito quando o objeto dep
não precisa ser sincronizado com o Dpto
ou não mudará de valor.
Mas muito cuidado com esse tipo de construção.
Por quê? Porque é uma cópia.
Aqui o Dpto não é a mesma coisa que o...
que dep que tá vindo por parâmetro,
ele é só uma cópia,
que é diferente do que a gente tinha feito até então.
Outra solução, também equivocada,
é essa aqui, ó.
Essa aqui revém o mesmo.
Aqui em vez de eu passar um ponteiro,
apontar pra um cara externo,
eu tenho um parâmetro que eu deixei uma variável temporária
que já é uma cópia de alguém que vem de fora
que por sua vez é copiada aqui pra dentro.
Então, tem que tomar muito cuidado com isso aqui também.
Não é isso?
Aqui tem algum ajuste pra ser feito também
Neste caso o objeto Dpto será uma cópia/clone
do dep, passado por parâmetro, por valor.
Isto pode ser feito quando o objeto dep
não precisa ser sincronizado
com o Dpto
ou não mudará de valor.
Muito bem.
Aqui eu re-saliento pra vocês, tá,
que tem que tomar cuidado com esse tipo de construção.
Então, essa versão V3 e a versão V2,
o que acontece em ambas é que elas,
dentro da Universidade,
tão criando clones do que foi passado por parâmetro
e não pelo apontamento
quando você cria a cópia dentro, você tem dois objetos
tem um qualquer dentro e o outro lá fora, externo
que num primeiro momento são iguais,
mas que podem evoluir em valores diferentes no tempo.
Gerando clones e gerando
supostas inconsistências, tá,
porque você não prestou atenção que você fez uma cópia e não uma referência, tá,
e não um apontamento.
Então, muita atenção com isso.