Neste curso, assumimos que você já sabe desenvolver programas pequenos em Java, mas você talvez não se sinta ainda confortável em projetar programas mais complexos com método e organização. O objetivo deste curso é fazer você compreender os princípios de orientação a objetos por meio da linguagem Java e saber como eficientemente aplicar esses princípios na prática quando projetando e desenvolvendo software de maneira ágil. Os conceitos discutidos e experimentados por você neste curso serão a base para você poder compreender os novos conceitos apresentados nos cursos seguintes desta especialização. Os conceitos Java apresentados neste curso incluem o seguinte: revisão de conceitos básicos de orientação a objetos, tais como classes, objetos, métodos e atributos, variáveis de instância e de classe; responsabilidades, colaborações e cartões CRC; testes de unidade, uso de plataforma IDE como o Eclipse; herança, classes concretas e abstratas, interfaces, modificadores de acesso, encapsulamento, métodos de acesso; aprofundamento nos conceitos de polimorfismo, sobrecarga e sobreposição; associação de classes, agregação e composição; exceções, delegação e acoplamento abstrato. Em seguida, vocês serão apresentados aos principais princípios usados para organizar o desenvolvimento de programas orientados a objetos com qualidade, dentre os quais, os princípios "Tell, Don't Ask!" e "Law of Demeter". Sempre que conveniente, cada conceito será representado por meio de diagramas UML. Você será exposto a propriedades e anotações em Java. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que você será capaz de implementar versões iniciais do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Modelagem CRC: Identificando Classes
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Orientação a Objetos com Java
851 classificações
Na lição
Classes com Java e Modelagem CRC
Olá! Bem-vindo à semana 2 do curso Orientação a Objetos com Java! Nesta semana você aprofundará seu contato com classes e métodos, bem como com modelagem CRC. Ao final desta semana, você será capaz de: 1) modelar o comportamento de classes com métodos em Java; 2) projetar novas classes para uma aplicação por meio da modelagem CRC
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá,
bem vindo ao curso de Orientação a Objetos com Java.
Meu nome é Clovis Fernandes e hoje iremos trabalhar com modelagem CRC.
Na sua parte 1 iremos tratar da identificação
de classes no contexto da modelagem CRC.
Anteriormente mostrei a vocês os conceitos do Cartão CRC,
onde C significa classe, o R significa responsabilidade e o C,
o segundo C, corresponde a colaboração.
Na aula de hoje iremos dar aplicações orientadas a objetos usando Cartões CRC.
É diferente do que a gente vinha fazendo anteriormente.
Anteriormente eu simplesmente mostrava para vocês algumas
classes e mostrava como identificar as responsabilidades e as
colaborações classes pré-definidas, que eu apresentava.
Já na modelagem CRC, CRC modeling,
nós iremos entrar no mundo da modelagem no desenvolvimento de aplicações.
Nós teremos que dada uma especificação de uma aplicação,
descobrir quais são essas classes,
como essas classes estão relacionadas com outras através de colaboração,
quais são as responsabilidades, é para isso que a modelagem CRC: vai facilitar
descobrir e modelar as classes de uma determinada aplicação,
porque eu não saberei de antemão quais são essas classes, eu tenho que fazer uma
modelagem descobrir e identificar e no caso vamos usar
o contexto de Cartões CRC responsabilidades e colaborações.
A modelagem CRC que nós adaptamos para apresentação neste curso
consta de 6 passos.
Nesta aula iremos apresentar apenas até ao passo 2,
que identificaremos as classes de uma aplicação fictícia.
Os passos de 3 a 6 serão vistos na próxima aula.
Antes de começar o passo 1, eu tenho uma suposição,
que eu estou chamando de passo 0 aqui, que é ter a especificação
de uma dada aplicação, no caso aqui eu estou fazendo uma especificação,
apresentando uma especificação de sistema de automação de uma biblioteca.
Para fazer a modelagem CRC então é primordial, é essencial,
que a especificação dos requisitos da aplicação alvo já esteja pronta.
Com base nesta especificação então poderemos seguir os
passos da modelagem CRC.
Neste caso vamos trabalhar num sistema de automação de biblioteca.
Eu vou mostrar só o começo dessa especificação.
Porquê?
Mais à frente iremos ver hands on que eu vou trabalhar com a mesma
especificação para exemplificar com mais detalhes como se
faz uma modelagem CRC cima de uma especificação prévia de sistema.
No caso aqui eu tenho o sistema de automação da biblioteca,
a biblioteca tem nome, mantém catálogo de livros, onde cada livro tem título,
autor e número único de catálogo, há usuários da biblioteca registrados,
há uma bibliotecária que realmente vai ficar responsável por fazer
toda a entrada de dados, a transação com o sistema,
a bibliotecária vai poder criar os usuários e registrar
esses usuários no sistema, vai poder adicionar novos livros,
vai poder listar os livros disponíveis para empréstimos,
o usuário vai poder tirar livros, emprestar livros e vai poder também
devolver esses livros e outros requisitos que podem ter num sistema de biblioteca,
mas que simplificadamente nós reduzimos só para ter uma apresentação mais didática.
Na modelagem CRC o passo 1 significa identificar as classes da minha aplicação.
E como é que eu faço isso?
De uma maneira bastante simples, embora seja engenhosa: no texto da especificação
da aplicação eu procuro os substantivos e os nomes e eu marco esses nomes.
Esses substantivos que eu encontro na especificação podem ser
considerados potenciais objetos ou classes,
vai depender de uma análise que eu vou exemplificar aqui.
Vamos exemplificar cima do trecho da especificação do sistema de
automação da biblioteca, que carinhosamente eu chamo de SAB,
S de sistema, A de automação e B de biblioteca.
Então quais são os substantivos que eu encontro neste texto?
Eu marquei aí amarelo: biblioteca, nome, catálogo de livros,
livro, título, autor, número único de catálogo,
usuários de biblioteca e outros que estão no resto do texto que eu não apresento,
mas que eu poderia listar aí para vocês,
bibliotecária e assim por diante.
Então eu separei, fiz uma lista dos substantivos.
Eles são potenciais classes, nem todas vão ser consideradas classes.
Então eu tenho lá biblioteca, nome, catálogo de livros, livro,
título, autor, número único de catálogo, usuários de biblioteca e etc.
No passo 2 a primeira coisa que eu tenho que fazer é refinar a lista.
Às vezes nomes diferentes podem significar a mesma coisa,
posso ter sinônimos ou nomes parecidos, análogos,
eu vou ter que ter esse cuidado na hora de refinar os substantivos que eu encontrei.
Outra coisa que eu tenho que fazer é retirar os nomes que vão corresponder
a atributos.
No nosso exemplo anterior nós tínhamos lá o nome da biblioteca,
então esse nome vai ser atributo de biblioteca provavelmente,
nós iremos então desconsiderar o nome da biblioteca,
nesse momento que eu estou querendo descobrir objetos e classes.
Outra coisa que eu vou fazer é olhar se os substantivos têm algum
relacionamento uns com os outros.
Por exemplo se eu tiver substantivo pessoa e tiver
substantivo soldado por exemplo, existe relacionamento entre soldado e pessoa,
soldado é uma pessoa, então existe relacionamento de herança.
Então eu posso identificar que uma classe,
se soldado é uma classe e pessoa também é uma classe,
eu posso então identificar que soldado é subclasse de pessoa.
Por fim, ao eliminar, refinar, encontrar as
possíveis classes eliminando os sinônimos,
eliminando classes que não devem fazer parte,
que não devem ser considerados classes nesse sistema que eu estiver fazendo,
identificar as associações de herança entre uma classe e outra,
as potenciais classes, eu vou descrever o que é que elas fazem,
eu tenho que dizer o que elas fazem.
É uma maneira de representar cada uma dessas classes
descrevendo o que é que elas fazem.
Bom eu estou apresentando agora para vocês a lista de todos os substantivos
ou locuções substantivas que eu encontrei na minha especificação,
como todo, não nesse trechinho apenas que eu apresentei anteriormente.
Então eu tenho potenciais classes: biblioteca, nome, catálogo de livros,
livro, título, autor, número único de catálogo, usuários da biblioteca,
nome único de usuário, sistema, bibliotecária e SAB.
SAB é a abreviatura do sistema de automação de biblioteca,
é o acrônimo para isso.
Com essa lista de substantivos eu levantei isso
cima da especificação como todo, não está na minha apresentação,
posteriormente nós iremos ver essa especificação como todo.
O passo seguinte é examinar as relações entre esses nomes,
se o nome realmente pode ser uma classe potencial ou não.
O primeiro ponto que eu coloco para vocês, que é uma coisa básica: classe
corresponde a uma abstração de objetos que têm características comuns,
características tanto de atributos quanto de
comportamento e eles devem ser registados sempre no singular.
Nós vemos aqui que eu levantei usuários da biblioteca,
está no plural, então o nome de classe deve vir sempre no singular.
Então a primeira providência que eu faço é transformar os nomes das classes,
se aparecer algum no plural, como era o caso de usuários da biblioteca,
eu deixo ele na forma singular.
A segunda coisa que eu vou examinar, nesse passo 2, nesse refinamento,
são nomes que representam atributos.
Então por exemplo: o nome de catálogo de livros que estava lá na
especificação, se referiam à biblioteca Eles possivelmente,
nós não precisamos ter uma certeza se estamos fazendo certo ou não,
total nesse momento, possivelmente eles serão atributo de biblioteca.
Então eu já posso eliminar, por isso é que eles aparecem ai riscados.
Com relação aos outros substantivos, título do livro, título que aparecia,
autor e número único de catálogo estavam associados lá no texto da
especificação ao substantivo livro.
Então eu suponho que eles são atributos ou serão atributos da potencial classe livro.
Já o usuário da biblioteca, o nome único de usuário estava também
associado no texto da especificação ao usuário da biblioteca.
Possivelmente também vai ser atributo.
O que é que eu faço?
Elimino todos esses possíveis atributos.
Ficamos então aqui apenas com biblioteca, livro, sistema,
usuário da biblioteca, bibliotecária e SAB.
Então os nomes que representam atributos são eliminados.
Eu estou identificando neste momento que existem sinônimos.
Existem sinônimos.
Por exemplo: a biblioteca, quando na minha especificação me refiro a biblioteca
estou-me referindo ao sistema que vai automatizar a biblioteca.
O SAB,
que é acrônimo para Sistema de Automação de Biblioteca significa a mesma coisa.
Então no meu sistema eu escolho: qual é que seria o mais apropriado para essa
aplicação?
Podia ser qualquer dos 3.
Sistema é uma coisa muito geral, talvez não.
SAB também poderia ser mas é uma sigla, quem é que vai saber o que é isso?
Então biblioteca talvez seja o melhor nome.
Mas não existe uma coisa muito precisa.
Tem que ser avaliado com calma.
Após eliminar sistema e SAB, eu fiquei com as potenciais
classes biblioteca, livro, usuário da biblioteca e bibliotecária.
Esses 4, a bibliotecária é ator.
É alguém que vive papel, que vai interagir com o sistema SAB.
Eu não vou manter informações no sistema sobre a bibliotecária.
Se o meu sistema mantivesse os nomes das bibliotecárias que eles precisassem,
por exemplo, serem reconhecidos e entrarem com senha, etc.
e tal, ai eu precisaria representá-los no meu sistema.
Nesse meu exemplo é só para mostrar que quando eu tenho alguém que vai interagir
com o sistema mas não preciso, eu não preciso guardar informação nenhuma
sobre essa pessoa que vai interagir com o sistema, quando eu não sei o nome dessa
pessoa eu chamo genericamente de ator, ele está fora do sistema.
É o contrário, por exemplo, do usuário da biblioteca,
aquele que vai na biblioteca para retirar o livro, emprestar o livro.
Eu preciso identificar esse usuário da biblioteca para diferenciar
qual usuário pegou tal livro, outro pegou outro livro, se devolveu ou não.
Então eu preciso gerenciar no sistema.
Usuário da biblioteca está dentro do sistema.
Biblioteca é o sistema como todo.
Livro, eu preciso gerenciar também os livros porque eu vou ter livros
sobre física 1, livros sobre física 2, livros sobre computação 1,
computação 2, eu preciso autores diferentes, eu preciso gerenciar isso.
Que livro vai ser emprestado para algum usuário, e assim por diante?
Então biblioteca, livro e usuário estão dentro do sistema.
Bibliotecária está fora.
Chegamos então ao conjunto de classes que identificamos para o
sistema de automação da biblioteca.
Então temos as 3 classes: biblioteca, livro e usuário.
As 3 classes que nós conseguimos identificar usando a modelagem CRC.
Aproveito para realçar que a imagem do fundo é a biblioteca do ITA.
Prédio iii pelo património histórico nacional que foi projetado por Niemeyer.
O próximo item dentro do passo 2 é descrever as classes.
Para cada uma das classes nós vamos apresentar a sua descrição:
o que foi planejado ou planejaremos para essas classes?
Então no caso da classe biblioteca, por exemplo,
ela representa o sistema de automação da biblioteca.
Vai ter a interação do usuário com o sistema
SAB e vai passar pela classe biblioteca.
Não estou considerando aqui as classes de interface que vão ficar realmente,
interface com o usuário que vai ficar realmente entre o usuário e o sistema.
Já a classe livros, ela representa livros
que serão emprestados a usuários da biblioteca.
Por sua vez a classe usuário representa os usuários
que desejam fazer empréstimos de livros da biblioteca.
Antes de completar o passo 2 nós temos que
representar essas classes que foram identificadas na forma de cartões CRC.
Nós temos aqui a representação de cartão CRC.
Diferentemente do que a gente apresentou até agora, que o cartão CRC tinha apenas
o nome da classe, as responsabilidades e as colaborações,
agora nós introduzimos uma informação adicional que é a descrição da classe.
Ela vai ser muito importante quando estivermos trabalhando com outros
princípios de projeto de classes.
Saber essa informação vai ser muito importante,
saber como é que se descreve uma classe.
Isso vai ser importante inclusive, por exemplo, para você decidir se vai
dividir a classe duas ou coisas desse gênero.
Neste caso nós temos então o cartão CRC
para a classe biblioteca, que eu tenho a descrição do que
a biblioteca ela representa o sistema de automação da biblioteca.
Nós temos a outra classe, cartão para outra classe que é a classe livro.
E por fim, o cartão para a classe usuário.
Concluímos a parte 1 da modelagem CRC.
Nesta parte nós identificamos as classes que conseguimos
iii da especificação dos requisitos do sistema de automação da biblioteca.
Os demais items que vão ser trabalhados na modelagem CRC,
descobrir as responsabilidades e as colaborações,
nós iremos ver na próxima aula nos passos 3 a 6.
Muito obrigado!
[MÚSICA] [MÚSICA]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
