[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]
