Pessoal, boa tarde.
Nós estamos no dia 8 de julho de 2020.
Estamos aqui no nosso grupo de slides número 3,
vamos continuar falando de relações
entre objetos e também classes, obviamente, em C++,
e ademais agora em UML,
Unified Modeling Language,
ou seja, Linguagem de Modelagem Unificada.
Vamos para o Modo Exibição.
Aí está o Modo Exibição.
Vamos pro slides 2.
Bom, o que tem que ser entendido
aqui, de prima,
é que codificação
seja em C, seja em C++ que é a nossa...
objeto de estudo aqui.
Ele é apenas uma fase da construção do software.
Conforme eu já discuti com vocês em...
apresentação precedente, exposição precedente,
o software é um artefato de engenharia.
Você não pode sair implementando software
sem respeitar o ciclo
de Engenharia de Software.
Assim como você não pode sair construindo uma casa
ou um prédio, ou um conjunto de prédios
sem respeitar o ciclo de Engenharia Civil.
Obviamente que
no caso da Engenharia Civil, fazer uma casinha,
vai, em termos de software fazer um pequeno programa,
a pessoa até consegue fazer de maneira artesanal.
Agora quando a coisa pega proporção, e entra daí
já no espectro da necessidade das técnicas de engenharia
se não respeitar essas técnicas, não respeitar esse ciclo
a coisa simplesmente não vai funcionar.
Isso posto,
então, a Implementação ou Codificação é uma fase
que é precedida da Modelagem
conhecida também como Análise e Projeto,
que é precedida ainda pelo Levantamento de Requisitos.
Basicamente, primeira coisa que a pessoa tem que entender,
antes de fazer um software,
é o que tem que ser feito
que é a fase de Levantamento de Requisitos.
Não adianta você entregar pro cliente
uma belíssima gangorra
se o que ele queria era uma balança.
Isso é fundamental.
Uma vez que você entendeu o que tem que ser feito,
aí você vai passar pela fase de Análise.
Em termos de orientação a objetos é entender
como são os objetos na
do mundo real ou
do mundo vislumbrado
como as coisas se relacionam
de uma maneira mais alto nível,
sem se preocupar, num primeiro momento,
em como implementar as relações que você tá vislumbrando
pra esse objeto entre esses módulos.
E aí, a hora que você passa pela fase de Projeto
você já começa pensar mais tecnicamente
como vão ser as relações
entre os objetos
entre as classes, se vai ter agregação, se vai ter associação
e por aí vai.
Só depois que você fez o Projeto,
ou seja, você fez a maquete toda do seu software,
que você vai passar pra fase de realmente construir
o software em termos de Implementação ou Codificação.
Se você pegar um software grande, como um jogo,
não raro, você vai ter lá, 40 classes
todas relacionadas em alguma medida,
gerando n objetos cada uma,
então realmente se precisa passar por esse rito todo aqui.
Uma vez que você implementou, ou codificou,
aí tem a fase de Testes.
Não há produto sem teste.
Você tem fazer... passar por essa fase, tá.
Na verdade, cada caixinha dessa aí, tá,
ela é pelo menos uma disciplina
digo disciplina em termos de formação,
mas também disciplina em termos de execução de projeto.
Em projetos sérios, grandes,
você vai ter uma equipe pra levantar requisitos,
você vai ter uma equipe pra analisar,
quiçá outra equipe pra projetar,
outras equipes pra implementar
e, ainda, uma ou mais equipes de teste.
Claro que tudo depende da envergadura
do que você tá elaborando, tá.
Muito bem, isso considerado, avancemos um slide aqui.
Se a gente olhar um pouco o nosso universo de discurso, tá,
você pode considerar que o...
na Engenharia de Software,
o Levantamento de Requisitos
ele se dá através de textos e tabelas,
sendo que é possível relacionar
os requisitos expostos nesses textos tabelados
com os chamados Diagramas de Casos de Uso.
Hoje os Diagramas de Casos de Uso fazem parte da chamada UML,
Unified Modeling Language,
ou Linguagem Unificada de Modelagem.
Então, tal qual, existe uma linguagem
pra você programar,
como C++, como Java, como C#,
existe linguagem pra você modelar.
Aqueles requisitos que você fez
lá de maneira estruturada
com o texto bem elaborado, bem pensado, bem engenhado
bem colocado em termos de tabela, tá,
bem tabelados, portanto,
você pode relacionar com os chamados, Casos de Uso,
que são os usos
do software no qual aqueles requisitos se aplicam
e a partir daí você vai gerar uma Modelagem toda
usando uma série de diagramas
que trazem diversas visões do software
no caso da Linguagem Unificada de Modelagem
ela traz, por exemplo, o Diagrama de Classes
de Objetos, de Sequência, Colaboração,
de Estado, Atividades, de Componentes e outros.
Nessa disciplina, nós vamos nos concentrar, ou nesse curso
nós vamos nos concentrar mais no Diagrama de Classes.
Nada obsta vocês estudarem os demais diagramas, tá.
Mas o que acontece é o seguinte,
como a disciplina é um curso, no caso, de programação
a gente tá interessado aqui, em como conectar as fases
de modelagem, particularmente, o projeto
com a implementação.
E quando você faz toda a modelagem, partindo do...
dos requisitos tabelados,
se relacionando com os Diagramas de Casos de Uso
aonde você começa a imaginar os objetos
e fazer toda uma modelagem que permite depois chegar na programação
um dos elementos que permite a gente, justamente,
chegar no código é o Diagrama de Classes.
E esses outros diagramas aí expostos, tá,
aí citados, perdão.
Eles corroboram no chegar
em um Diagrama de Classes pro seu projeto, pro seu software,
chegar nele,
ou corroboram pra melhor explicá-lo, em alguma medida.
Isso explica porque que nessa disciplina
de conexão entre modelagem e a implementação
focando na implementação, bem entendido,
a gente salienta o diagrama de classes.
Bom, depois da Implementação vem os Testes.
Testes, é toda uma disciplina complexa, tá.
No âmbito dessa disciplina
a gente vai obviamente focar nos testes
feito pelo próprio desenvolvedor.
E aí, pra isso, ele pode se utilizar de registros em arquivos
debugger, que é lá a depuração que eu já mostrei
dei uma pincelada em aula passada,
mas insisto, tá, a área de Testes,
em projeto industrial,
você vai ter, além dos testes feito pela,
naturalmente, feito pela equipe que desenvolveu, implementou a coisa,
você vai ter outra equipe responsável por justamente testar
de maneira independente, em relação,
ao que os desenvolvedores fizeram.
Isso, obviamente, se estiver usando um ciclo mais sério,
ou mais clássico, da Engenharia de Software
ou da Engenharia de Sistemas em geral
que é essa que eu tô mostrando pra vocês aí
no slide 3.
Ainda em termos de modelagem,
hoje em dia, além da linguagem de modelagem unificada
você também tem a Linguagem de Modelagem de Sistemas
que é uma derivada da UML
traz novos diagramas
diagramas complementares, inclusive, à UML,
que servem, sim, pra modelar software,
mas também foram pensados pra modelar sistemas em geral.
A questão é a seguinte, tá,
a Linguagem de Modelagem Unificada, conforme já discutido em...
ou pincelado, pelo menos, em aula anterior,
Ela é uma linguagem que permite modelar graficamente
orientado a objetos.
Montar tuas "maquetes", né, orientado a objetos.
O fato é que existem outras engenharias que também trabalham orientado a objetos,
como a Engenharia Mecânica,
a Engenharia Mecatrônica mesmo e afins.
Aí o pessoal se deu conta que a UML, criada pra software,
que modela objetos
mas como objetos também existem no mundo real
o pessoal entendeu que a linguagem de modelagem em questão aí, a UML
poderia ser útil, com alguma adaptação, pra sistemas em geral.
Aí criou-se a Linguagem de Modelagem de Sistemas.
Inclusive, ela permitiu cobrir algumas coisas que não estavam cobertas da UML,
que são úteis pra sistemas em geral e também pra software
Dou um exemplo,
a SysML tem, por exemplo, Diagramas de Requisitos.
Então, em vez de, ou complementar a,
os requisitos feitos, de maneira textual, tabelado,
a pessoa também pode diagramar
esses requisitos e relacioná-los, tá.
Mas isso aqui é só pra vocês terem uma visão geral
desse ciclo geral de
Engenharia de Software.
Lembrando que a gente vai tá
focado aqui
muito mais em implementação e
em modelagem, em projeto, particularmente, tá,
conectando com a implementação.
Slide 4.
Bom, pra Análise e Projeto
a gente vai usar ferramentas CASE
que são... bom, CASE é uma sigla
que ela ela significa ali, Computer-Aided Software Engineering,
Engenharia de Software Auxiliada por Computador,
ou já mais recentemente
Ferramenta de Sistema Auxiliar pro Computador.
Computer-Aided System Engineering.
Já evoluiu de Software pra Sistema, né.
Você vai ter várias ferramentas aí, tá,
que daí vão suportar UML
ou SysML e algumas mais completas
vão suportar os dois, UML e SysML.
Nós, nessa disciplina, vamos trabalhar com UML
e particularmente com Diagrama de Classes conforme já informado.
Bom, aqui eu posso citar alguns exemplos de ferramenta CASE, tá.
Destaquei ali a StarUML,
inclusive, destaquei a versão que eu uso
com vocês nessa disciplina
tem ainda o Astah, o Jude,
elas tão destacadas porque são gratuitas.
A StarUML tá com a versão,
insisto, porque é essa que eu vou usar com vocês na disciplina
e tem outras aí, tá.
Tem ferramentas extremamente profissionais e caríssimas, inclusive.
Rational Rose System Architect, Together e Rhapsody.
elas são caras porque realmente foi
investido muito tempo e
montar uma ferramenta altamente profissional,
Pro nosso âmbito aqui, as ferramentas gratuitas elas são suficientes,
não é isso?
Então, tá sublinhado aqui a que a gente vai utilizar
e aqui a parte de implementação e até o que a gente vai fazer de testes
a gente vai usar o ambiente de programação,
Isso já foi discutido, tá.
A gente tá utilizando o Microsoft Visual Studio C++,
mas tem outros
ambientes, como o CodeBlocks,
aqui pra C++
pra quem tá num ambiente que não seja Windows, provavelmente Linux.
O ambiente de programação vocês o que utilizar, tá.
depende de
utilizar o Microsoft Visual Studio, ou o CodeBlocks.
mas isso fica a gosto do cliente desde que ele
se articule no ambiente que ele escolheu pra uso
Muito bem.
Isso posto,
aqui eu cito algumas bibliografias, tá, que são uteis.
São livros que eu já li no passado,
são muito bons.
e as vezes o aluno quer uma indicação
pra se aprofundar no assunto, gostou da temática, tá.
tem o livro do Pressman, que é um clássico
de Engenharia de Software
inclusive, eu li uma versão anterior, lá em
1997, 96,
mas ele continua sendo um livro clássico, tem o Sommerville também que não tá aqui
mas poderia estar.
Tem já daí os livros
do Rumbaugh, do Jacobson e do Booch
sobre UML.
Tanto esse segundo quanto esse quarto aqui, ó
é interessante porque o Rumbaugh
tinha o método dele OMT,
o Jacobson tinha o método dele,
e o Booch tinha o método dele de modelagem.
Cada qual tinha o seu método.
E aí pra evitar o que aconteceu com as linguagens de programação
cada linguagem de programação seguiu um caminho
eles resolveram
criar uma linguagem de modelagem unificada
pra evitar ali
uma torre de Babel de linguagens de modelagem, tá,
tal qual ocorre com as linguagens de programação
ainda que pras linguagens de programação
a gente pode encontrar justificativas se a gente quiser.
Muito bem, eles criaram, então, a partir dos seus métodos
a linguagem de modelagem unificada.
aqui também tem um livro em português, tá, sobre UML
que é o do Bezerra, um bom livro até onde eu me recordo, tá.
Eu li ele já tem alguns bons anos.
Muito bem.
Aqui tem umas bibliografias suplementares, tá.
que eu deixei, por enquanto, riscadinhas,
porque elas são de
temas subsequentes que a gente vai estudar.
pra quem já quiser ir verificando, fica a vontade, tá,
mas são livros da sequência
lá pro final da disciplina que trata de padrões de projeto.
Assunto pra outrora.
Muito bem, tudo isso considerado,
todo esse prefácio dessa exposição considerada,
o que que a gente tá fazendo até aqui?
Até a aula passada?
Se você perceber, a aula passada,
a gente tinha lá
objetos da classe Pessoa,
objetos da classe Universidade
e objetos da classe Departamento.
O último exercício ele instigava
vocês a fazerem um exercício lá, que era
criar uma classe Departamento com objetos Departamento
que se relacionavam, de alguma forma, com as outras classes.
Departamento devia ser agregado
em Universidade.
e ainda ia haver um relacionamento de cada Pessoa
para com o Departamento de uma Universidade.
Bom,
esse exemplo que a gente tá utilizando
pra introduzir uma série de conceitos, no final das contas
começa a se caracterizar como um sistema acadêmico.
Por que foi escolhido um sistema acadêmico?
Porque é um sistema que vocês estão vivendo,
então vocês tem mais sensibilidade, vocês entendem melhor os requisitos,
vocês entendem melhor a modelagem, tá, que tá acontecendo,
enfim, foi por isso que eu escolhi um sistema acadêmico
porque é o que vocês são sensíveis
sobre os conceitos utilizados, como
universidade, departamento, disciplina e por aí vai.
Bom, à luz do que eu disse antes, tá,
é importante que
antes de a gente desenvolver um sistema,
em termos de código,
particularmente, o meu sistema vai ficar um pouco grande
que a gente aplique
de maneira bastante correta
o ciclo de Engenharia de Software.
Até então nosso sistema, nosso sistema é pequeninho
servindo de exemplo, ficava servindo pra introduzir conceitos,
mas agora ele começa a tomar uma certa envergadura,
é por isso que a gente dá um passo pra trás
e volta aqui
definir os requisitos.
Então, tá aí: Definindo Requisitos Funcionais e Gerais do Sistema Acadêmico.
O que a gente tá propondo agora, então,
como sistema exemplo
pra explicar modelagem
em UML com diagrama de classes e, particularmente, implementação em C++
orientado a objetos
é esse Sistema Acadêmico que aqui
respeita esses requisitos gerais que estão expostos aí.
Claro, aqui eu tô sendo bem
pedagógico, eu acho que é a palavra
e trazendo os requisitos de maneira bastante compreensíveis,
num primeiro momento, sem se preocupar com detalhes
daí o termo Gerais.
Bom, o primeiro requisito tá aí, ó:
Registrar no sistema um conjunto de Universidades;
Registrar no sistema um conjunto de Departamentos
relacionados à Universidades.
Faltou um 's' ali.
Registrar no sistema
um conjunto de Disciplinas
relacionados a Departamento.
Registrar um conjunto de Professores
relacionados a entidades pertinentes
como Departamentos e Disciplinas
Registrar um conjunto de Alunos relacionados a entidades
pertinentes como Departamentos e Disciplinas.
Então, esses são os requisitos
gerais que a gente está tendo
Tem uma observação ali:
Estes são requisitos funcionais e gerais
que são expandidos e refinados, inclusive em termos técnicos
nos enunciados de exercícios.
Justamente. Se você olhar os exercícios que foram
passados nas aulas anteriores
você até pode caracterizar eles
como derivados desses requisitos gerais, né.
Bom, isto porque estamos no âmbito de uma disciplina
aprendendo conceitos progressivamente.
Em um sistema real,
os requisitos deveriam ser definidos
e estabelecidos o quanto antes,
dentro do ciclo de Engenharia de Software.
Isso é tão verdade
quanto mais complexo for o sistema
e quão mais crítico for o sistema.
Se for um sistema de software, por exemplo, pra rodar em avião
rodar num drone, rodar num carro,
que são sistemas críticos que não podem falhar,
o ciclo tem que ser muito respeitado.
Então, o ciclo clássico de Engenharia que a gente mostrou ali,
ele tem que ser respeitado com afinco.
Hoje tem outras abordagens, tá,
menos clássicas, como a abordagem ágil
que o pessoal utiliza
em certas classes de software
claro que se você tá fazendo uma homepage lá,
e não tem nada de crítico
só pra trazer alguns conteúdos
não, necessariamente, você vai aplicar todo o ciclo
de Engenharia de Software, muito embora, devesse,
mas, enfim, só pra trazer essa
consideração, essa ponderação sobre o que tá escrito ali.
Qual que é a diferença entre requisitos funcionais e técnicos?
Simplificadamente,
requisitos podem ser classificados em Requisitos Funcionais
e Requisitos Técnicos.
Os Requisitos Funcionais
são os que definem quais funcionalidades
terão o sistema sem definir como estas...
estas se darão tecnicamente falando.
Se você parar pra pensar
os requisitos que eu apresentei aqui são funcionais, ó.
Registrar no sistema um conjunto de Departamentos relacionados a Universidades.
Eu tô dizendo o que tem que ser feito, mas não tô dizendo como.
Já os requisitos técnicos, já trazem um pouco do como
se não trazem o como efetivamente.
Os Requisitos Técnicos são os que definem
como as funcionalidades se darão tecnicamente,
salientando meios ou formas.
Isso é uma visão simplificada, tá,
a temática de requisitos ela é bastante ampla,
vou ter que trazer uma visão suficiente
para o que que a gente tá fazendo aqui
pra gente poder chegar na modelagem e depois fazer
a implementação em C++, orientado a objetos.
Último item ali.
Certamente, baseando-se nos requisitos funcionais,
sejam gerais ou específicos, pode-se derivar
requisitos técnicos.
Bom, aqui, no próximo slide
como vocês podem imaginar,
tem requisitos técnicos
derivados lá dos requisitos gerais.
que acabam, no final das contas, retomando a última aula,
na qual havia os seguintes requisitos técnicos.
Que requisitos são esses?
Criar uma classe chamada Universidade
que terá como atributo um nome.
Relacionar a classe Pessoa
para com a classe Universidade.
Cada objeto de Pessoa
poderá ser associado a um objeto de...
a um objeto de Universidade.
A classe Pessoa terá um ponteiro para um objeto
ou variável da classe Universidade
se a gente olhar já do ponto de vista mais técnico.
Por fim, a classe Pessoa, por sua vez,
terá uma função-membro, um método,
que permitirá a cada objeto de Pessoa informar o seu nome
e em que Universidade trabalha.
Legal.
Esses requisitos aqui a gente já tinha
feito eles em termos de código, tá,
já tinha implementado, feito, já tinha...
tratado esses enunciados aí,
mas justamente agora a gente vai fazer
de maneira mais correta
antes de passar direto pro código
que vai modelar a classe
ou as classes.
Como é que modela uma classe
como essa que tá aí de Universidade?
Você faz usando a UML.