Bom, uma vez que você terminou a Análise,
se tudo que você tinha que fazer do âmbito de Análise tá pronto,
ou seja, você entende o mundo que você vai animar computacionalmente.
Você entende isso através do modelo de diagrama de classes analisado. Análise.
Agora, você tem que começar a pensar como é que você vai começar a projetar a coisa.
Aqui eu tô olhando uma outra situação
eu tenho que a situação do Aluno
até pode ser, ainda, do ponto de vista de Análise
daí tá entrando no Projeto.
Então, a gente já vai falar de...
de modelagem não só de Análise, mas migrar da Análise pro Projeto.
É que se olhar o mundo real, eu tenho alunos e os alunos se relacionam com departamento,
a gente pode dizer que o Aluno conhece um Departamento, tá.
Inclusive, dá pra parar pra pensar se de fato é isso, tá.
Se é só um Departamento, ou pode ser um ou mais.
Usualmente, quando eu fazia graduação
o Aluno tava associado a um Departamento.
Hoje com a interdisciplinaridade de saberes, tá,
talvez essa modelagem aqui já vai precisar melhorar.
Por exemplo, eu posso colocar aqui na cardinalidade 2.
Aqui, também, eu tô com uma associação direcional.
Tá vendo.
Isso significa que só o Aluno conhece o Departamento e o Departamento não tem ciência disso,
mas a gente sabe que o Departamento ele tem lá a listagem dos alunos matriculados
ou associados com ele, né.
Então, talvez não seja direcional.
E a Análise, né,
é o momento pra você tomar essas decisões
ver se as cardinalidades estão corretas
ver se a direcionalidade tá correta,
se não vai ter seta pros dois lados
ou não ter seta nenhuma, o que é equivalente
a ter seta pros dois lados
nesse momento, aí, de Análise.
Aqui seria um diagrama de classes no escopo de análise,
pois contém apenas as informações das classes e de seus relacionamentos.
Sem se preocupar
ainda com questões técnicas já voltadas a código futuro.
Bom, então, naquele espírito de melhorar
e aprimorar/refinar o que está modelando,
aqui, a gente pode ter chegado a conclusão
que o Aluno conhece 1 Departamento
Por enquanto, a gente vai dizer que o Aluno tá filiado a 1 Departamento mesmo.
Mesmo que curso dele seja animado por 2 Departamentos.
Pelo menos nessa análise foi assim.
Passivo de debate, bem entendido.
E o Departamento, por sua vez,
é conhecido por 1 ou mais Alunos
e, ainda, a relação aqui é bidirecional.
Quando não tem seta pra lugar nenhum
é como se tivesse seta pros dois lados.
O Aluno conhece o Departamento e o Departamento conhece os Alunos.
E aqui como ficou? Eu criei um relacionamento n pra 1, 1 pra n.
E a gente já sabe que cardinalidade, né.
Isso aqui são as cardinalidades, tá.
Cardinalidade ele impacta, né, inevitavelmente
em soluções computacionais.
Bom, se é uma associação aqui
a gente pode colocar papeis.
Seja associação de análise, seja de projeto, você pode colocar papeis, tá.
Ali, como é que a gente colocou os papeis?
Cada Departamento gerencia
"gerencia o estudo" de
de 1 ou mais Alunos
e cada Aluno estuda em 1 ou mais Departamentos.
Aliás, perdão. Cada Aluno estuda em 1 Departamento, bem entendido.
Essa cardinalidade aqui é 1.
O relacionamento é n pra 1, 1 pra n e não n pra n.
Novamente.
O Departamento "gerencia o estudo" de 1 ou mais alunos
e cada Aluno estuda
ou o conjunto de Alunos estuda,
se a gente quiser colocar assim,
em 1 Departamento.
Isso posto,
agora a gente pode começar a pensar
como é que a gente sai
de um diagrama de análise pra um diagrama de projeto
que é o que eu vou explicar no slide subsequente.
Antes de avançar pro conexão
conexão do diagrama de classes com o diagrama de projeto,
vamos só fazer um ajuste, aqui, tá, de papeis.
A mim me parece
que essa definição de papeis ficaria mais justa se a gente fizesse assim.
Papeis é uma coisa que confunde,
então, as vezes você tem que refletir um pouquinho sobre o que tá fazendo
mas modelagem é justamente isso.
O Aluno estuda em 1 Departamento
e o Departamento "gerencia o estudo" de 1 ou mais Alunos.
Sim, de fato, ficou melhor assim.
Com isso aqui corrigido, tá.
Modelo é isso, tá.
Modelo você tá sempre refletindo até que ele fique maduro
na discussão com a coletividade
que tá, ali, trabalhando nessa modelagem.
Aqui, sumiu minha linha, né,
Minha traquinagem, ali.
Depois tenho que colocar essa linha que ficou faltando aqui.
Mas tudo bem.
Essa linha já aparece no próximo slide, inclusive.
Tá aqui a linha, voltou a aparecer.
E aqui, naturalmente, vai ser necessário,
ajustar, aqui, esses papeis
em todos os demais slides, tá.
Ou, simplesmente, a gente pode tirar os papeis, né.
Eu, particularmente, vamos dizer, não trabalho muito com papeis, tá.
Só uso papeis em casos muito pontuais,
que é realmente preciso pra explicitar algo melhor,
do contrário, eu trabalho sem a utilização deles
que me parece mais fácil só colocar o verbo no infinitivo aqui.
E assim você faz ficar intuitivo, né, o relacionamento entre eles.
Sem essa necessidade de especificar os papeis aqui.
Mas isso é uma opinião minha, bem entendido.
Tem parte da literatura que vai
defender com mais veemência
a utilização dos papeis.
Aqui, então, eu proponho
essa retirada dos papeis.
Bom, pessoal, retomando aqui, então.
Nós estamos nesse momento que a gente saiu
do diagrama de análise.
Inclusive, aqui, com papeis, insisto,
pro diagrama de projeto.
No diagrama de projeto eu tô ignorando esses papeis,
porque eu tô me concentrando só no nome, aqui,
do relacionamento, que é o que importa pra mim no final das contas,
pelo menos, nesse momento dado.
Aqui, eu tenho, então,
já saindo da análise, indo pro projeto
que é o seguinte.
Tenho a associação dada,
que o Aluno conhece 1 Departamento
e o Departamento é conhecido por 1 ou mais Alunos.
Legal.
Como é que eu vou implementar isso aí?
Bom, como a gente implementou
os nossos protótipos?
Foi por meio de uma lista de Alunos.
A gente criou a classe ListaAlunos.
Inclusive, num primeiro momento a gente não tinha feito assim
mas a gente acabou evoluindo pra uma solução
que usava explicitamente uma classe ListaAlunos pra criar desacoplamento
em relação às funcionalidades de lista
no tocante a Departamento.
O Departamento é uma coisa.
O Departamento tem dentro de si
um objtLAlunos que é do tipo ListaAluno.
Por isso que eu preciso de uma classe ListaAluno
que justamente resolve
essa associação ou, pelo menos, parte dessa associação posta.
Quando uma classe resolve uma associação,
eu posso chamá-la de classe de associação
ou classe de relacionamento.
Faço isso através desse pontilhado.
Eu posso... isso aqui denota a origem, aqui, da classe.
Por que que ela existe?
Ela existe por causa disso aí.
Por causa da associação conhecer aqui.
Como é que o Departamento vai conhecer um conjunto de Alunos?
Através de uma lista de Alunos.
Bom, já que é o Departamento que vai ter a lista
parece razoável que eu faça isso aqui.
Uma agregação. Forte, inclusive.
Composição, portanto.
Aqui sempre é um, né.
Departamento vai ter uma lista
e essa lista é tida por um Departamento, obviamente.
Aí, eu posso criar uma relação aqui,
um pouco mais abstrata,
aonde eu posso dizer que na lista de Alunos
vai estar um ou mais alunos, ou seja,
na lista estarão, ou vão estar,
um ou mais Alunos
e os Alunos estão, ou estarão,
em uma lista de Alunos, tá.
Então, é um relacionamento de localização
ou de pertencimento em alguma medida
no sentido de estar participado daquela lista
Tá preferencial naquela lista.
Muito bem.
Mas se eu olhar com um pouquinho mais de cuidado
esse nosso projeto aqui.
Se você olhar, aqui, o que tá em vermelho, aqui,
ele é a parte de projeto, né.
Enquanto que essa parte em azul, aqui.
É o relacionamento lá da análise.
Analisado tal qual seria um sistema visto aí, acadêmico
com departamentos e alunos no mundo real.
No mundo real existe, analisando no mundo real,
o Aluno se relacionando com o Departamento e vice versa
Agora, como que eu animo isso em termos de projeto?
Tá aqui a classe ListaDepartamento.
Só que ela não é suficiente pra resolver,
pra animar esse relacionamento aqui.
Porque você tá permitindo que o Departamento
conheça um conjunto de Alunos,
mas e como é que o Aluno vai conhecer o Departamento?
Hmm, então não basta essa classe.
Preciso ter algo mais.
E tá aqui esse algo mais.
Aqui já é uma associação.
Vejam só, é uma associação de projeto.
O fato do Aluno ter esse ponteiro aqui
que vai apontar pro Departamento
é uma associação de projeto.
E aquela classe de associação
mais essa associação de projeto
isso conjuntamente realizam.
Aqui, sim, uma realização usada de maneira mais propriamente dita.
Então, isso aqui, essa classe
mais essa associação em vermelho
permitem realizar...
esses dois permitem realizar conjuntamente
essa associação teórica.
Dito outramente,
essa relação abstrata
ela se dá concretamente
por essa classe
e por essa associação de projeto aqui.
Muito bem.
Agora, se eu olhar um pouquinho,
isso aqui ainda tá muito abstrato.
Eu preciso especializar isso.
Tá tão abstrato que eu até pintei isso aqui de azul.
O que é azul é abstrato, o que é vermelho é mais concreto, tá.
O que a gente... como é que a gente vai deixar isso mais concreto?
Então.
Bom, a gente sabe que a lista de Alunos,
ela vai ser... a hora que cada Aluno vai ser jogado dentro da lista,
eu vou criar um ElementoAluno
pra gerenciar o Aluno na lista, não vou?
Ora, se isso acontece,
então eu vou modelar aqui.
Tá ali, ó.
O ElementoAluno vai permitir realizar
esse relacionamento de estar, né,
entre ListaAluno e Aluno.
Cada ElementoAluno vai conhecer um Aluno
e o Aluno pode ser conhecido por vários ElementosAlunos.
É verdade, né.
Se eu tiver um Aluno que tá em várias listas de Alunos
para cada vez que um Aluno é inserido em uma lista de Alunos
é criado um ElementoAluno específico pra ele naquela lista.
Assim sendo, se eu inserir, por exemplo, um Aluno
em 3 listas de Alunos,
em cada lista que ele for inserido vai ter
um ElementoAluno pra gerenciar ele naquela lista.
Por que mesmo, professor?
Pra evitar confusões, lá, de encadeamentos.
Se eu tiver um ElementoAluno pra gerenciar cada Aluno
em cada lista
eu não tenho problemas de encadeamento com próximo nem anterior.
Sendo que o próximo e o anterior é específico
pro contexto de cada lista
pra um Aluno dado.
Essa relação aqui também.
Interessante, mas abstrata.
A ListaAluno vai conter um conjunto, né,
de 1 ou mais ElementosAlunos
e o ElementoAluno é contido nesse cara, aqui,
ListaAluno, via agregação forte.
Vejam que de fato é uma agregação forte.
Cada ElementoAluno
ele só vai estar, de fato, em uma ListaAluno
ele é proibido de estar em mais de uma ListaAlunos.
Por quê? Porque é a natureza da coisa.
Inclusive, ele é criado dinamicamente dentro de cada lista
e é apagado dinamicamente dentro de cada lista.
Aliás, dentro da lista que ele participa.
Bem entendido.
Então, cada ElementoAluno ele existe dentro de uma lista apenas.
Criada dinamicamente lá,
e deletada dinamicamente lá também.
Muito embora seja uma agregação forte,
nada obsta dela ser animada por ponteiros.
Inclusive, a gente sabe
que na implementação que a gente fez
a gente animou por ponteiro
porque a gente fez essa lista com encadeamento duplo.
Pra ter encadeamento duplo
a gente precisou dessas relações aqui.
A ListaAluno tem o Conhecer Primeiro
tem o Conhecer Atual,
no tocante a ElementoAluno
e cada ElementoAluno tem o Conhecer Próximo e o Conhecer Anterior.
Engraçado que essas 4 associações
essas duas reflexivas aqui.
Conhecer Próximo e Conhecer Anterior.
E essas duas aqui
entre ListaAluno e ElementoAluno
Conhecer Atual e Conhecer Primeiro.
Essas quatro relações, conjuntamente,
realizam essa agregação forte aqui.
Estava de maneira bastante abstrata
e agora tá de maneira bastante técnica
e se tá técnica é projeto
e o projeto já tá vislumbrando o quê?
Geração de código.
Inclusive, eu posso gerar o código na ferramenta CASE,
que ele já vai tá aí
voltado pra implementação que eu quero.
Projeto ele tá se aproximando da codificação,
ainda que em modelagem, bem entendido.
Se vocês quiserem eu posso, só pra fins de conhecimento e animação
eliminar aqui os relacionamentos teóricos.
Ficar só com os relacionamentos de projeto,
na prática, vão refletir a existência do código subsequente
Então, vou eliminar ali, o primeiro relacionamento em azul.
Vou eliminando,
deixando só o que realmente vai acontecer em termos de código.
Claro que eu preciso conhecer as etapas
pra saber o porque que eu cheguei nisso.
Então, eu tenho que manter
eu apaguei aqui nessa imagem,
mas na prática eu tenho que manter
essa evolução pra eu saber o que tá acontecendo.
Eu tô voltando slide aqui, bem entendido, tá.
Agora eu tô lá no 18.
Agora vou avançar 18, 19, 20.
Tô indo, ó, mostrando como é que foi essa evolução dessa modelagem
fazendo uma brincadeira aqui, é quase uma prova de conceito, graficamente falando.
Uma equação que você vai desdobrando ela e chega num resultado, tá.
Bom, aqui eu fiz passo a passo, tá,
mas você pode ser um pouco mais pragmático,
depois que vocês ficam um pouco experimentados,
pega uma situação dada como essa aqui que eu vou mostrar agora
em termos de Análise.
Eu tô analisando olhando o sistema como ele é
e eu sei que o Departamento tem um conjunto de Disciplinas
e cada Disciplina, ela está associada a um Departamento.
A gente viu várias universidades e entendeu que é assim.
Vamos supor que é assim em todo caso.
Tá, isso aqui então em termos de Análise.
Como é que isso aqui vai ser em projeto?
Pode debater com a equipe
e falar "Olha, a gente vai fazer isso aí via lista duplamente encadeada"
Ah, tá.
Então, a gente vai animar essa relação, aqui, de Análise,
por assim dizer, teórica
tecnicamente por meio de uma lista encadeada?
Sim.
Ah, então, vamos modelar essa lista.
Vamos.
Tá aqui, ó.
Inclusive, essa agregação
do ponto de vista do Departamento agregar as Disciplinas
de fato é modelado por uma lista de Disciplinas.
Podia ter um S aqui, tá.
Seria legal um S aqui, no plural: Disciplinas.
Muito bem.
Então, tenho essa animação aqui.
Aí, bom.
Aí eu já fiz a coisa mais direta
eu já sei que essa ListaDisciplina vai ser,
pelo menos parcialmente responsável por realizar essa agregação dada
Aí o Departamento vai agregar a ListaDisciplina.
A lista ListaDisciplina vai Conhecer Primeiro e Conhecer Atual
no tocante a ElementoDisciplina.
Cada ElementoDisciplina, tem aqui, um Conhecer Próximo e um Conhecer Anterior
e cada ElementoDisciplina conhece uma Disciplina.
Por fim, ainda,
cada Disciplina conhece um Departamento
e os Departamentos são conhecidos por uma ou mais Disciplinas,
aliás, são conhecidos por n Disciplinas,
melhor dizendo.
Pelo menos à luz da modelagem dada.
Professor, mas se aqui é um asterisco
ali não podia ser um asterisco?
Poderia, tá.
E a gente pode corrigir isso, pra manter a coerência, inclusive.
O fato aqui é que
você viu o relacionamento teórico
e desdobrou rapidamente pra solução técnica.
Por quê? Porque aqui eu já tô supondo que você é um analista,
um projetista mais experiente.
Analista e projetista mais experiente.
Às vezes, as equipes têm pessoas que só analisam
e pessoas que só projetam.
Não raro você vai fazer os dois,
analisar e projetar a coisa.
Aqui eu vou fazer aquele pequeno ajuste.
Como eu sempre insisto em todos os meus discursos sobre modelagem
Modelagem a gente tá sempre melhorando.
Claro que aqui eu tô fazendo
esse ajuste no desenho, né.
Normalmente a gente faz isso aqui numa ferramenta CASE, bem entendido.
Mas aqui não impede que também seja modelagem
Modelagem mais pobre com relação a uma ferramenta CASE
mas, ainda sim, uma modelagem, bem entendido.
ListaDisciplinas, parece que fica melhor o nome da classe.
Aqui, Departamento.
Ainda não criei aqui o objeto ListaDisciplinas, tá.
Mas eu posso, naturalmente criar
o objeto se eu quiser.
Daí, claro, que se eu criar o objeto ali,
eu vou ter que criá-lo colocando
um nome que respeite a classe tá.
Inclusive, eu posso colocar aqui embaixo, tá.
Nada impede, nada na UML impede.
C++ que me impede.
Vamos lá.
Se aqui eu tô chamando o objtLAlunos
aqui eu posso chamar então de objtLDisciplinas.
E aqui tem o nome da classe
que vai ser ListaDisciplinas.
Bom, lá em cima, pro nome da classe ficou ListaAluno
mas também eu posso ir lá e posso modificar
pra ListaAlunos, naturalmente.
Não é isso?
Mnemônico também o nome de classes
também é uma coisa importante.
De fato tá como ListaAluno.
e poderia ser ListaAlunos, tá.
Inclusive, eu acho que ficaria melhor no plural.
E modelagem então é isso, tá, gente.
Você vai modelando criando as coisas
e é no modelo que você refina as coisas.
É no modelo que você faz todo esse exercício que eu tô fazendo aqui,
inclusive, em tempo de execução com vocês,
de refletir sobre os relacionamentos, se eles estão certos.
As cardinalidades se elas estão certas.
De fato, a agregação aqui é agregação não-direcional.
Ah, é?
Ah, então se não é... então se ela não é direcional
eu tenho aqui a recíproca.
Olha aqui, ó.
Tá ali a recíproca.
Em termos, depois, técnicos.
Como é que eu vou animar esse relacionamento
do Departamento ter as Disciplinas?
Ah, através de uma ListaDisciplinas.
Ah, o nome é no plural. É Lista de Disciplinas
Então, arruma aqui o nome e assim eu vou, naturalmente.
Posso revisar as cardinalidades ver se as cardinalidades estão certas.
Se aqui eu tô dizendo que cada ElementoDisciplina
ele conhece, como Anterior, 0 ou 1.
É 0 ou 1? Parece que faz sentido.
Tem uma situação que ele não tem Anterior, nas demais ele têm.
Conhecer Próximo, 0 ou 1.
0 ou 1 faz sentido? Faz sentido.
Porque quando só tem um cara na lista,
não tem próximo
e tem uma situação, em todo caso, que
subsequente, que ele não vai ter próximo.
Então a gente pode refletir sobre as cardinalidades, sabe.
O modelo permite que você
elabore as suas abstrações
e as suas concepções
e, em alguma medida, simule
o que vai acontecer.
com as instâncias dos objetos depois no código
Porque é menos trabalhoso
você acertar os elementos,
acertar esses detalhes, inclusive, nomenclatura de classe
em termos de Projeto, de modelagem, enfim,
do que depois no código.
Na verdade, isso vai... já é até uma máxima da engenharia de software,
que quanto antes você acerta as coisas no ciclo da engenharia de software
menos custoso é.
Se você errar no requisito
isso impacta em toda cadeia aqui
de produção, né, subsequente.
Se você algo na Análise,
impacta drasticamente o que você vai fazer em código
Então, por isso que é importante você fazer essa boa parada, esse bom respiro
em cada momento, em cada fase da engenharia de software.
Aqui, a gente tá falando de modelagem Análise e Projeto,
então nessas fases você tem que fazer esse respiro
no sentido de fazer a reflexão
pra ver se o que você tá fazendo, tá certo.
Tanto em termos de relacionamento que você compôs,
as classes, até os nomes das classes, as cardinalidades, enfim.
Bom, esses modelinhos que eu andei brincando aqui
eles estão disponíveis pra vocês lá no meu site.
Lá pra fazer o modelo eu usei o StarUML.
Já usei em outras aulas com vocês aqui, tá.
A versão que eu uso é a 5.0.2.1570.
Tem versões mais modernas, mas essa versãozinha aqui é bem estável.
Limitado da geração de código e da engenharia reversa,
mas não tem problema, porque, justamente, nessa disciplina
eu gostaria que vocês não fizessem geração de código,
e não fizessem engenharia reversa.
É o momento de aprender a programar, de aprender as sintaxes
tanto em UML quanto na linguagem de
orientada a objetos visada.
No meu caso aqui é C++.
Deixa eu salvar aqui.
Pra acabar essa aula aqui,
deixa eu só ir no nosso site, meio que quase de costume já.
Fazer ali uma pequena observação.
Aqui é o site.
DAINF Jean Simão, cai no site.
Tá ali, Técnicas de Programação.
Andei fazendo umas reformulações que
já falei pra vocês nas exposições passadas.
Aqui, pessoal, eu entro em...
Introdução à Engenharia de Software e a UML, diagrama de classes,
conexões entre o projeto e a implementação.
Na verdade, eu vou talvez mudar um pouco esse nome
Conceitos Avançados em Linguagem C++...
Não, aqui, Introdução à Engenharia de Software e a UML diagrama de classes.
É...
Aqui a conexão entre projeto e a implementação no sentido que
o projeto que a gente desenvolveu tá praticamente o que vai ter no código.
Isso é verdade, tá.
Então, se você olhar ali as soluções de projeto
você já tá enxergando o que vai acontecer no código
e é até por isso que a ferramenta CASE consegue gerar
código estrutural a partir disso.
Aqui nós temos os slides em .ppt e .pdf
conforme o gosto do cliente.
Aqui tem os modelos que eu trabalhei, tá.
Vocês viram que eu fiz alguns ajustes ali
em tempo de execução, de cardinalidade e tal,
vocês podem baixar esses modelos e fazer os ajustes vocês mesmos, tá.
Professor, tá proibido gerar o código?
Veja, você pode do ponto de vista de experimentação,
só pra ver que gera e etc,
mas você descarta aquele código gerado e faz o seu certinho.
Aqui tem uma apostila de UML
desenvolvida pelo professor Stadzisz
que estão nesses links, mas acho que esses links andaram corrompendo.
Então, ela tá disponível aqui embaixo, certinho.
Aqui é legal essa apostila, gente,
porque ela traz um pouco mais de luz
sobre essa questão da UML.
Insisto, nessa disciplina,
o que a gente trabalha de diagrama de classe é a conexão do diagrama de classes
com os códigos gerados, né.
Mas as vezes o aluno se encanta pela área de modelagem,
não é raro isso acontecer,
e quer se aprofundar,
e, ao mesmo tempo, as vezes ele não quer entrar num livro
de duzentas, trezentas páginas, tá,
que são aqueles belos livros que eu indiquei.
Ora se você quer fazer uma coisa mais pragmática
ter uma noção melhor do que é a UML
sem ler trezentas, quatrocentas páginas de um livro clássico,
você pode, com alternativa, tá.
Isso é leitura alternativa,
uma visão mais concisa
e muito pedagógica, muito didática, muito elegante
ver a apostila aqui do professor Stadzisz.
Inclusive, foi meu orientador de mestrado e doutorado,
by the way.
Ele faz um belo apanhado, aqui,
de como, através de diagramas de casos de uso,
que seriam, vamos dizer assim, os usos do sistema
à luz dos requisitos existentes
como é que é naqueles usos do sistema
eu começo a enxergar os objetos
que vão animar aqueles usos.
Como é que eu crio as classes,
uma vez que eu enxerguei os objetos, eu enxerguei as classes,
como é que eu faço os relacionamentos
entre esses objetos, essas classes
Então, ele tem um caminho ali,
que ele mostra pra vocês
de enxergar os objetos, enxergar as classes,
de criar os relacionamentos entre classes,
se utilizando para tal
do apoio de outros diagramas UML.
Diagrama de sequência, diagrama de colaboração,
traz exemplos desses diagramas,
e assim vai,
que daí acaba culminando
num diagrama de classes mais complexo.
Então, tem vários caminhos de diagramas de classe,
um caminho é você já ir direto pro diagrama de classes,
ou você pode usar outras maneiras.
Você pode primeiro imaginar os objetos que existem.
Você pode fazer o levantamento das classes.
Ir se apoiando em outros diagramas da UML
que permitem analisar os objetos
como esses objetos vão interagir entre eles.
Intuir, ou melhor, inferir daí, a partir daí,
os relacionamentos das classes, tá.
Por meio, enfim, desses diagramas de suporte que eu tô destacando aqui.
Aqui, o que eu tô querendo dizer é o seguinte
enquanto na nossa disciplina
a gente tem uma abordagem mais ad hoc, ou seja, mais direta,
a gente vai imaginar o nosso sistema a partir dos requisitos e define as classes diretamente
aqui tem uma outra abordagem mais sutil
de, inclusive, talvez até, mais parcimônica
de através de outros meios da UML
alcançar o diagrama de classes.
Bom, espero que eu tenha instigado a curiosidade de vocês,
pra fazer uma leitura aí de férias, tá,
no tocante a essa apostila.
Eu li essa apostila aqui, a muito tempo atrás, eu gostei muito dela
e de vez em quando eu revisito ela, inclusive.
Bom, voltando pro meu site aqui.
Tem um material que eu vi algum tempo atrás,
lembro de ter gostado desse material.
Deixo vocês darem uma visitadinha se quiserem
e julgarem se vocês gostaram tanto quanto eu, imagino que gostarão.
Pessoal, espero que tenham gostado dessa aula,
ela foi, na verdade, uma revisão do que a gente já sabia de UML,
mas com a revisão,
particularmente diagrama de classes, mas com a revisão
sempre a gente aprende, ou reforça,
algum conteúdo que ficou
às vezes, ali, necessitando uma segunda explicação.
Bons estudos, nos vemos brevemente na próxima exposição
de Grupo de Slides que eu vier a fazer.
Até logo, bons estudos.