Pessoal, boa noite.
Estamos no dia 19 de julho de 2020, um domingo.
Eu tô aqui pra falar do Grupo de Slides número 9.
Eu tô aproveitando o período da noite, porque tá mais silencioso, aí eu
espero que o som fique um pouco melhor no microfone.
Isso posto,
o Grupo de Slides número 9 fala sobre modelagem orientada a objetos
em Unified Modeling Language, Linguagem de Modelagem Unificada,
especificamente em diagrama de classes.
Na verdade a gente vai fazer uma revisão, sabe,
sobre diagrama de classes UML,
lembrando um pouco a diferença de Análise e Projeto
lembrando que a gente faz a modelagem, ou seja,
a Análise e o Projeto em UML
sempre visando a programação orientada a objetos.
Passar pro slide 2.
O que tem que ser lembrado, né,
é que a implementação codificação ela é, entre aspas,
"apenas uma fase da engenharia de software".
A engenharia de software começa lá com o levantamento das necessidades.
Bom, análise de mercado, levantamento de necessidades
chegando ao Levantamento de Requisitos.
Depois você vai pra Análise e Projeto,
ou seja, você passa pela fase de modelagem aqui, né.
Depois que você analisou, ou seja, você modelou
o sistema como ele é no mundo observado,
você passa dessa fase de análise da modelagem
pra fase de projeto da modelagem
aonde você começa a pensa como é que você vai fazer
aquele modelo analisado do ponto de vista mais técnico
você já começa em termos de modelo
a pensar um pouco mais tecnicamente
já vislumbrando lá,
em termos de codificação como a coisa vai ficar
e ainda que não seja codificação.
Aí, depois do Projeto você transita
pra Implementação ou Codificação
e depois passa pra fase de Testes.
Se você for usar o rito mais clássico, né.
O ciclo mais clássico da engenharia de software,
você faz assim, nesse sentido, né.
Levantamento de requisitos, passa pra modelagem,
aí, implementação e testes.
Só que hoje já com os modelos em espiral, né,
ou com a maneira de projetar em espiral
você pode voltar, aqui, etapas, tá.
Nesse ciclo de engenharia de software.
Tudo depende, na verdade, o quão crítico,
o quão flexível é o contexto que você tá trabalhando.
O que eu quero dizer, longa história curta,
é que tem uma larga diferença entre projetar software que vai rodar em avião
e software pra uma homepage
com informações não críticas, por exemplo.
Tem uma larga diferença entre você projetar um simulador de avião
e projetar um jogo simplório
em modo 2D,
aonde não tem nenhum impacto maior um erro no software.
Então, o quão mais rígido, ou menos rígido são essas voltas, aqui, tá.
No ciclo da engenharia que você tá utilizando
ou no método que você tá utilizando
ela vai depender do contexto, conforme eu dizia.
Bom, a gente já discutiu também em slide passado, tá,
que você tem essa situação aqui.
Levantamento de requisitos,
que eles podem ser feitos através de textos estruturados, tabelados.
Também você pode fazer através de diagramas
como os diagramas de Requisitos da SysML.
A SysML é querendo ou não uma derivada da UML
e ao mesmo tempo uma generalização da UML.
Enquanto a UML foi feita pra software
A SysML foi feita pra sistemas em geral.
Muito embora, hoje em dia,
o pessoal já use de maneira casada
SysML e UML tanto pra sistemas quanto pra software, tá.
Sistemas em geral quanto pra software em específico.
Você pode, de certa forma, agrupar um conjunto
de requisitos definidos e até modelados
em Diagramas de Casos de Uso da UML
que são diagramas que fazem uma transição
entre os requisitos de uso e o sistema e
já migrando pela fase de modelagem.
A fase de modelagem você pode ter uma série de diagramas, tá.
Sendo que, conforme já discutido em aulas passadas,
essas exposições passadas aqui nossas,
nós estamos focando em Diagramas de Classe
quando você faz uma modelagem completa
você culmina num Diagrama de Classes
e você vai saber
sair de um Diagrama de Classes
e ir pra implementação de código em C++, inclusive, por causa dessa disciplina nossa aqui.
Por causa desse estudo nosso aqui.
Porque a gente modela em Diagrama de Classes e já implementa
o respectivo modelo de classes UML
em C++ ou na linguagem orientada a objetos que você esteja focando, tá.
Então, a gente faz nessa disciplina, nesse curso
a gente faz essa conexão aqui entre
entre o Diagrama de Classes e a implementação em OO.
E aí, tem toda a parte de testes, tá.
A gente já discutiu que o teste tem uma disciplina a parte, ele é uma...
tem toda uma complexidade.
O fato aqui pra nós é que
a gente vai ver testes, no âmbito dessa disciplina,
os teste feitos pelo programador.
Não confundir com os testes feitos por equipes de testes independentes.
Depois vocês vão estudar aí nas demais disciplinas
durante o curso de vocês,
espero, com mais afinco,
disciplinas de engenharia de testes.
Não é isso?
Vão estudar essas temáticas dentro de outras disciplinas.
Pra essa fase, aqui, de implementação,
testes do ponto de vista de quem tá implementando a gente
vai usar então as linguagens em ambientes de programação
orientado a objetos, né.
Eventualmente, até algum ambiente de testes integrado, tá,
mas isso é mais raro de acontecer no âmbito da nossa disciplina.
Óbvio que ocorre
já daí em desenvolvimentos mais críticos de sistemas, tá.
Mais completos, digamos assim,
do desenvolvimento de sistemas, de software orientado a objetos.
Aqui no âmago da disciplina
o levantamento de requisitos é uma coisa que vai acontecer, basicamente,
por textos estruturados, tá. Texto tabelado.
Ainda que até pudesse utilizar diagramas.
A Análise e Projeto, ela vai ocorrer
principalmente, tá,
com classes, diagrama de classes
e diagrama um pouco de objetos, mas mais diagramas de classes,
que a gente utilizou lá naquelas listas encadeadas
aqueles diagramas de cubos, tá.
Na verdade, foi uma licença poética dos diagramas de objetos da UML,
que não são cubos, são quadrados,
mas não deixam de ser diagramas de instância.
Lá a gente via cada instância
e a gente viu que modelar cada instância
não necessariamente é tão produtivo e tão compreensivo
como modelar as classes que, na prática,
vão englobar todas as possíveis instâncias existentes, tá,
num modelo mais genérico do que o de instância.
Isso considerado,
aqui tem a parte também de desenvolvimento e até de testes,
no tocante ao uso de debugger e depuração, né.
Então, a gente vai utilizar ambientes de programação.
Isso aqui já foi discutido também, tá.
Até esse slide foi discutido em aula passada, tá.
Sendo pragmático,
a gente tá usando o Microsoft Visual C++,
atualmente chamado na Microsoft de Visual Studio.
e muitos de vocês também estão usando o CodeBlocks, tá.
O importante é que a pessoa esteja usando um ambiente que ela se sinta bem,
que seja estável pro C++
e que ela domine o contexto em que ela tá trabalhando, enfim, né.
Muito legal.
Aqui tem algumas bibliografias
pra quem quiser se aprofundar em engenharia de software, UML.
As vezes a pessoa tá fazendo uma Disciplina
que tem um vislumbre sobre um domínio.
A gente tem um vislumbre aqui sobre engenharia de software, né,
particularmente nesse interfaceamento de diagramas de classe
com a implementação em código orientado a objetos.
Mas nesse vislumbre, não raro,
alguns estudantes se encantam pelo domínio,
E aí querem se aprofundar um pouco
em processos de engenharia de software, em métodos de engenharia de software
querem pegar um processo cascata,
mais rígido, aonde tem que bem definir os requisitos,
depois bem definir a modelagem,
bem definir a codificação,
bem definir os teste com raríssimos retornos, aqui,
nessas etapas.
Eu posso ter outros processos que são chamados de processos ágeis
aonde eu posso e devo voltar várias vezes aqui e
refinar o processo
num ambiente, talvez mais relaxado,
tudo no bom sentido.
Enfim, quem quer estudar, as vezes, os processos de engenharia de software
pode estudar, aqui, por exemplo, o livro do Pressman.
As vezes a pessoa também quer se aprofundar em Linguagem de Modelagem Unificada,
então pode ver o livro do Rumbaugh, Jacobson e do Booch
Esses aqui estão em inglês, mas também já deve ter na biblioteca versões em português.
Tem o livro do Bezerra que também.. que tá em português, inclusive,
ele traz bastante essa visão
de Análise e Projeto, né, diferenciando Análise e Projeto.
Aonde a Análise é mais do ponto de vista de como o sistema é no mundo vislumbrado
que o Projeto é como ele vai ser implementado computacionalmente, né.
Ainda do ponto de vista de modelagem,
sem chegar no Projeto, mas já
criando as interfaces para.
Enfim, isso aqui é só uma reflexão
se o camarada quiser um referencial de livros, tá.
Muito embora, muito que felizmente,
hoje você tem uma diversidade grande de autores
e de saberes na literatura, tá,
que você pode utilizar
conforme a tua predileção por algum autor.
Aqui tem outros livros que eu deixei, por enquanto, rabiscados
porque eles vão ser importante pra frente.
Eles tem bastante correlação com todo esse conhecimento que tá aqui, tá,
mas eles são, ainda assim, um assunto específico
que é o Padrão de Projeto
que vai ser discutido no âmbito desse curso, dessa disciplina na sequência.
Aqui ficou mais como um lembrete que esse livro, aí, pode ser bastante útil.
As vezes você se depara com o livro,
então, já deixa o flag ligado que isso livro pode ser importante.
Muito bem.
Vamos dar uma revisada, então, naquilo que a gente tava falando,
já em conjuntos de slides anteriores,
sobre Linguagem de Modelagem Unificada
focando em diagrama de classes.
Aqui nós temos
uma classe Pessoa, classe já conhecida do nosso Sistema Acadêmico, lá.
Definida tanto em UML quanto em C++.
Isso já é conhecido de vocês, tá.
Eu insisto, isso é uma revisão.
Tá aqui o nome da classe.
Tá aqui o conjunto de atributos,
inclusive, são protegidos,
olha aqui o sustenido, aqui, o hashtag de protegido.
A ferramenta case que eu tô utilizando,
já cito, é a StarUML
já apresentada em slide anterior, em aula anterior
Tá aqui o conjunto de métodos.
Construtoras, destrutoras,
os métodos todos públicos, vocês viram que estão todos com mais, né.
Aqui tá a reciproca do código em C++.
Essa seta não tá atoa aqui, inclusive, tá.
Isso aqui é pra lembrar que algumas ferramentas CASE,
elas permitem gerar código.
Eu já fiz demonstração em aula passada,
que a gente pegava a partir de um conjunto de classes
e gerava código.
É possível também fazer engenharia reversa, do código
gerar a classe.
Claro que se teu modelo
for só modelo estrutural
como é o caso de um diagrama de classes
ele não vai gerar os algoritmos que vão dentro dos métodos.
Pra gerar os algoritmos dentro dos métodos
a primeira coisa que tem que ter
é modelagem de cada algoritmo que tá lá dentro,
através de espécies de fluxogramas ou diagramas de atividades
e a ferramenta tem que ser potente o suficiente pra gerar código.
Muito bem.
Aqui a gente tá falando mais da visão estruturada, nesse momento, bem entendido.
Isso considerado, agora que a gente já relembrou aqui
como é que a gente faz uma classe em UML
vamos lembrar como que a gente faz herança em UML,
inclusive, do ponto de vista de Análise,
mas também de Projeto, tá.
A herança do ponto de vista de Análise e Projeto, não muda.
Ela é basicamente a mesma coisa.
Então, você vai ter aqui o Aluno derivado,
isso é derivação, tá,
de Pessoa.
Então, dá pra dizer que o Aluno herda tudo que tem em Pessoa
e Professor também herda de Pessoa.
Então, tanto o Aluno quanto o Professor são também Pessoas.
Eles também vão ter diaP, mesP, anoP, idadeP
esses atributos todos que estão aí expostos.
E também vai ter esse conjunto de
métodos que estão aqui postos, tá. Tal qual.
Isso, então, é herança, tá.
Herança eu usei essa simbologia aqui.
Essa seta, aqui, contínua,
com esse triângulo fechado, aqui.
Agora, no próximo grupo de slides a gente vai ver agregação.
Antes de ir lá pra agregação no slide 9,
aqui no 8, ainda, você tem aqui
como fazer um comentário,
uma nota, em UML,
com essa conexão pontilhada aqui
pra dizer que isso é pertinente a essa classe.
Eu posso ter nota conectada a classe,
conectada até a relacionamentos se eu quiser.
Agora sim, grupo de slides 9, aliás...
slide 9 do Grupo de Slides em questão,
e aqui a gente tá falando de agregação fraca.
Eu já falei da diferença de agregação forte e fraca, né.
Agregação-forte é aquela por composição
aonde o elemento compõe outro sistema
e normalmente se participa dele.
Por exemplo, o coração é agregado em cada pessoa,
cada pessoa tem o seu coração
e fisiologicamente falando não divide o seu coração com ninguém.
A pessoa tem seus pulmões, tá.
Então, pra aquele sistema pessoa existir,
aqueles caras tem que estar agregado nela, e só nela.
Agregação-fraca já é aquilo que você pertence a algo
mas de maneira um pouco mais fluida.
Você pode pertencer a vários algos.
Um exemplo bem peculiar que eu utilizo é a família, tá.
Você pode participar de várias famílias.
Você faz parte legalmente das famílias.
Não é isso?
Pode participar biologicamente de uma família,
você pode participar legalmente de outra família
e você pode constituir outra família ainda,
sem deixar de participar da família de origem, bem entendido.
Então, agregação-fraca é isso, tá, aonde
que você tá agregado, mas de maneira mais fluida.
Então, tá aqui, ó.
Aqui a gente pode fazer uma interpretação.
Isso é uma interpretação, não quer dizer que ela é verdadeira.
O momento de Análise,
é justamente esse momento que você tá refletindo as coisas,
você tá entendendo o mundo, modelando o mundo
que você tá enxergando pra transformar ele numa animação computacional em alguma medida.
Em um segundo momento, através, daí, do projeto
culminando lá, na implementação, na codificação.
Aqui, gente, a gente tem então
a classe Disciplina
que supostamente agrega fracamente,
um ou mais Alunos,
e cada Aluno é agregado em uma ou mais Disciplinas.
É uma maneira de interpretar.
Muito embora, eu não concorde com essa modelagem que tá aí expostas...
exposta.
Ela até é razoável.
Inclusive, essa agregação, aqui, diz o seguinte:
a Disciplina agrega um conjunto de Alunos,
o Aluno é agregado em um conjunto de Disciplinas, né,
uma ou mais Disciplinas,
e o Aluno sabe disso, veja que a agregação não é direcional.
É uma agregação sem direção.
Se fosse direcional, aqui,
isso denotaria que a Disciplina
agrega o Aluno e o Aluno não tem ciência disso.
Bom, isso que eu tô dizendo é um pouco polêmico e
conforme a pessoa que você esteja discutindo
sapiente da UML, tá,
mas essa interpretação é uma interpretação aceita.
Se você coloca aqui a direcional.
Colocasse uma seta aqui.
Vira uma agregação direcional.
Agregação-fraca direcional.
No qual, o Aluno ou a Disciplina agregaria Alunos fracamente
o Aluno estaria fracamente agregado a uma Disciplina ,
mas o aluno não teria conhecimento das Disciplinas.
Aqui ele tem conhecimento. Por quê? Porque não tem seta nenhuma.
Bom, aí, você pode entrar num debate e falar:
Professor, mas, tudo bem. Aqui é uma agregação-fraca direcional,
aliás, sem direcionamento, n pra n,
mesmo porque se ele fosse 1 pra n seria agregação-forte,
tudo bem, mas será que é agregação, será que não é outra coisa?
E é esse o momento de discutir, tá.
A Análise é o momento que você tá aí pra fazer a reflexão justamente.
Outra possibilidade de tratar esse relacionamento, aí,
entre Disciplina e Aluno, é assim, ó.
Através de uma associação.
Eu posso dizer... e eu gosto mais dessa versão aqui.
Eu posso dizer que a Disciplina cursa...
perdão. A disciplina é cursada por 1 ou mais Alunos
e cada Aluno cursa uma ou mais Disciplinas.
Também eu posso falar no plural, né,
que os Alunos cursam as Disciplinas
e as Disciplinas são cursadas por Alunos.
Inclusive, é interessante, porque na associação
você pode, além de colocar o nome da associação,
que sempre é um verbo no infinitivo, tá,
e é assim que eu uso,
você pode colocar papéis.
Eu não costumo usar papéis, tá.
quando eu faço as minhas modelagens,
mas tem muita gente que usa.
Eu já usei em algumas situações, mas foi raro, pra falar a verdade.
Há quem diga que ela melhora o peso semântico,
ou seja, melhora o significado
a significância das coisas.
Aqui, ó.
A Disciplina...
as Disciplinas são Cursadas por Alunos,
e os Alunos Cursam a Disciplina.
Então, eu posso colocar papéis
aqui nas extremidades pra denotar o que tá acontecendo na associação.
Insisto, tá.
Os Alunos, conjunto de Alunos,
Cursam as Disciplinas
e as Disciplinas são Cursadas por Alunos.
E aí, também tem as cardinalidades que acompanham os papéis.
Bom, aí você pode fazer a questão, tá.
Professor e se a gente ficar num embate?
A gente não sabe se é agregação-fraca ou se é associação.
Bom, na hora, vai ter que ser decidido, tá.
Mas se você não quer resolver isso nesse momento
você pode fazer um uso extraordinário da realização.
Como aqui eu tô no mesmo âmbito,
não tô com coisas que estão saindo da Análise e indo pro Projeto,
eu tô apenas dentro da Análise,
eu posso fazer aqui, em termos de Análise,
isso é equivalente àquilo.
Usar a realização, aqui, um uso extraordinário da realização
pra dizer que eles são equivalentes, mas em algum momento, tá, você vai ter que decidir
se é assim ou é assado.
Não é isso?
Então, inevitavelmente, tá.
num momento dado você vai se obrigar a tomar a decisão.
Depois de debater com seus colegas analistas,
claro que sem conflito...
o que eu tô fazendo aqui?
Você vai ter que tomar a decisão e dizer
não, tudo bem. A gente ficou nesse embate aqui,
mas vamos ter que tomar a decisão
de escolher uma das situações, tá,
e tomar essa situação como apropriada.
No caso, aqui,
me parece bastante razoável, tá,
considerar que o relacionamento mais pertinente,
mais razoável entre Disciplina e Aluno
é o de associação.
Porque a Disciplina não tem os Alunos, né.
A Disciplina ela se relaciona com os Alunos e vice versa
durante um período de tempo, tá,
que é o período ali de formação
e depois a coisa evolui cada um no seu caminho.
Bom, aqui eu fiz esse slide adicional aqui, em tempo de execução,
só pra trazer à luz
essa questão que uma hora você vai ter que tomar a decisão, tá.
Sobre qual caminho que você vai tomar na modelagem
depois da devida reflexão.
Modelagem é o que exige reflexão.
Não pode sair modelando assim orientado a desespero.
Você tem que ir orientado a calma, orientado a saberes
e construir o teu conhecimento.
Aqui a gente optou então por Cursar.
A Disciplina vai ser cursada por um conjunto de Alunos
e os Alunos vão cursar um conjunto de Disciplinas.