Artigo Completo Aplicacao Da Tecnica CRC Em Projetos de Sistema de Software Orientado a Objetos

Anais do CONCISTEC'11 2º Congresso Científico da Semana Tecnológica – IFSP © 2011, copyright by IFSP 17-21 de outubro de 2011, Bragança Paulista, SP, Brasil

APLICAÇÃO DA TÉCNICA CRC (CLASSE, RESPONSABILIDADE E

COLABORAÇÃO) EM PROJETOS DE SISTEMA DE SOFTWARE ORIENTADO A OBJETOS

Wellington Vieira dos Santos, [email protected] FATEC Zona Leste Avenida Águia de Haia, 2893 Cidade A. E. Carvalho, São Paulo – SP Wilson Vendramel, [email protected] Instituto Federal de São Paulo Avenida Francisco Samuel Luchesi Filho, 770 Penha – Bragança Paulista – SP Cristina Correa de Oliveira, [email protected] Instituto Federal de São Paulo Avenida Francisco Samuel Luchesi Filho, 770 Penha – Bragança Paulista – SP RESUMO. O conteúdo de análise e desenvolvimento de sistemas comumente fundamenta-se no paradigma da orientação a objetos. Alunos iniciantes costumam apresentar um alto nível de dificuldade na elaboração de diagramas, principalmente do diagrama de classes da Unified Modeling Language (UML). O objetivo deste trabalho é conceituar e aplicar a técnica Classe, Responsabilidade e Colaboração (CRC) que visa uma maior compreensão do problema do domínio e uma melhor modelagem das classes na etapa de análise do ciclo de desenvolvimento de um software. Por meio de sessões, a técnica foi aplicada em um projeto de software com a participação de alunos iniciantes de um curso superior da área de Informática. A utilização da CRC proporcionou resultados positivos, pois houve um maior entendimento por parte dos alunos. Cada discente representou um papel de objeto durante a construção das classes, favorecendo o processo de aprendizagem. A técnica CRC ainda precisa ser explorada em outros projetos de desenvolvimento de software para que a equipe possa ganhar maturidade e obter cada vez mais resultados melhores. Sua aplicação exige disponibilidade e empenho dos participantes (alunos e professores). A CRC aplicada de forma correta pode contribuir para o ensino de Análise e Projeto Orientado a Objetos (APOO) em cursos relacionados à Computação.

Palavras chaves: CRC, UML, orientação a objetos, modelagem de classes. 1. INTRODUÇÃO

Com o crescimento das redes de informação e a necessidade do desenvolvimento de aplicações para muitos fins,

aumenta-se a busca por conhecimento na área de sistemas, e os cursos técnicos e superiores em desenvolvimento de sistemas recebem um público bastante eclético.

Em ambientes educacionais é comum perceber as dificuldades encontradas entre os alunos para acompanhar o conteúdo das disciplinas. Tais dificuldades podem ser causadas por vários fatores e são pesquisadas por especialistas em educação (THOMASSON; RATCLIFFE; THOMAS, 2006).

No ensino de análise e desenvolvimento sistemas de software, as dificuldades também existem e possuem suas causas e efeitos. O conteúdo deste curso geralmente fundamenta-se no paradigma da orientação a objetos. Alunos iniciantes costumam apresentar um alto nível de dificuldade na elaboração de diagramas da Unified Modeling Language (UML).

Este trabalho tem por objetivo conceituar e aplicar a técnica Classe, Responsabilidade e Colaboração (CRC) para modelagem de classes de análise em projetos de sistemas de software orientado a objetos. Por meio de sessões, a técnica CRC foi aplicada em um projeto de software com a participação de alunos iniciantes de um curso superior da área de Informática.

As metodologias utilizadas para o desenvolvimento deste trabalho são: pesquisa bibliográfica, com o intuito de ampliar o conhecimento sobre os assuntos tratados e dar maior embasamento teórico e pesquisa-ação que, segundo Vergara (2005), “tem como objetivo resolver problemas por meio de ações definidas por pesquisadores e sujeitos envolvidos com a situação investigada.” A pesquisa-ação busca elaborar e desenvolver conhecimento teórico. 2. MODELAGEM DE CLASSES

Segundo Bezerra (2007), o modelo de classes evolui conforme as iterações são realizadas no desenvolvimento do

sistema. O modelo vai sendo refinado à medida que o sistema é desenvolvido, sendo que novos elementos são inseridos ou eliminados no diagrama. A modelagem de classes existe em três níveis sucessivos de abstração: análise, especificação e implementação. O modelo de classes de análise (ou domínio) é usado para representar as principais classes do negócio e não possui detalhamento ou definição das restrições, que podem ser incorporadas ou especificadas de acordo com a solução do problema. Este modelo é criado na fase de análise. Já o modelo de classes de especificação (ou projeto) é uma extensão


do modelo de classes de análise, onde são inseridos detalhes da solução escolhida. Por este motivo, algumas classes são especificadas neste modelo para desenvolver a solução. Este modelo é desenvolvido na etapa de projeto. E por fim, o modelo de classes de implementação é uma extensão do modelo de classes de especificação e corresponde a implementação das classes em uma linguagem de programação.

2.1. PARADIGMA DA ORIENTAÇÃO A OBJETOS

De acordo com Pressman (2006), se alguém observar ao redor de uma sala, pode se notar uma coleção de objetos que poderiam ser classificados e definidos de forma simples, mas quando o espaço é uma aplicação de software pode não ser tão fácil compreender esses objetos e seus possíveis atributos e comportamentos.

Para Bezerra (2007), uma característica presente em um sistema de software é a complexidade de seu desenvolvimento. Essa complexidade aumenta conforme o sistema cresce, e pode ser comparada à construção de sistemas habitacionais, pois quanto maior o projeto, maiores são as dificuldades para sua execução. O projeto de uma aplicação de software requer a criação de modelos que possam representar de forma mais ampla a visão do problema. São várias as razões para o uso de modelos: gerenciamento da complexidade, comunicação entre as pessoas envolvidas, redução nos custos de desenvolvimento e previsão no comportamento futuro do sistema.

Um paradigma é a uma forma ou uma maneira de abordar um problema. ”O paradigma da orientação a objetos visualiza um sistema de software como uma coleção de agentes interconectados chamados objetos. Cada objeto é responsável por realizar tarefas específicas...” (BEZERRA, 2007, p.6).

Bezerra (2007) ainda define objetos como sendo coisas do mundo real. Os conceitos relacionados à orientação a objetos são na verdade, a aplicação do mais básico e único conceito: o princípio da abstração que é um processo mental pelo qual se preocupa com os aspectos mais importantes (relevantes) de alguma coisa, ao mesmo tempo em que os menos importantes são ignorados.

Rumbaugh, Booch e Jacobson (2004, p.215) definem classes como “uma coleção de objetos que compartilham os mesmos atributos, operações, métodos, relacionamentos e comportamentos e que uma classe representa um conceito dentro de um sistema sendo modelado.” Dependendo do tipo do modelo, o conceito pode ser do mundo real (para modelo de análise) ou ele pode também conter algoritmo e conceitos de programação de computadores (para modelo de projeto). 2.2. FUNDAMENTOS DA UML

Para Booch, Rumbaugh e Jacobson (2005), a Unified Modeling Language (UML) é uma linguagem padrão para a modelagem de sistemas de software. A UML é apenas uma linguagem e, portanto, é somente parte do processo de desenvolvimento de software. A linguagem UML é destinada para visualizar, especificar, construir e documentar artefatos de um sistema de software. Esta linguagem fornece regras que tem foco na representação conceitual e física de um sistema. No modelo conceitual, a UML especifica três elementos principais, sendo: bloco de construção, regras que determinam como esses blocos serão utilizados e alguns mecanismos comuns. Itens, relacionamentos e diagramas são os três tipos de blocos de construção no vocabulário UML.

Ainda de acordo com Booch, Rumbaugh e Jacobson (2005), existem quatro tipos de itens especificados na UML: Itens estruturais que representam a parte estática do modelo; Itens comportamentais que representam a parte dinâmica do modelo; Itens de agrupamento que representam as partes organizacionais do modelo; Itens anotacionais que representam as partes explicativas dos modelos. A UML inclui diagramas que tem por objetivo geral a apresentação gráfica de um modelo, exibindo conjuntos de elementos que possuem itens e relacionamentos. Os diagramas são criados para permitir uma visualização de um sistema sob perspectivas diferentes. 2.3. IDENTIFICAÇÃO DAS CLASSES DE ANÁLISE

Para Pressman (2006), as classes são identificadas quando são observadas suas respectivas necessidades dentro do projeto e então, esta classe é aproveitada como parte da solução. As classes de análise se manifestam por si mesmas de algumas maneiras: como entidades externas que produzem e consomem informação a ser usada por um sistema baseado em computador; como coisas que são parte do domínio de informação do problema; como ocorrências ou eventos que ocorrem dentro do contexto da operação; como papéis desempenhados por pessoas que operam o sistema; como unidades organizacionais que são relevantes para a aplicação; como lugares que estabelecem o contexto do problema, ou função macro do sistema; e como estruturas que definem uma classe de objetos ou classes relacionadas de objetos.

A identificação das classes também é dividida em duas atividades: A primeira que é identificar classes candidatas, é relativamente fácil, e a segunda que é eliminar o conjunto de classes desnecessárias, é uma tarefa mais complicada.

Para Bezerra (2007), há dois métodos para identificar classes de domínio de um sistema: um dirigido a dados, que enfatiza a estrutura dos conceitos relevantes para o domínio do negócio, e o outro dirigido a responsabilidade, onde a ênfase está na identificação das classes a partir de seus comportamentos mais relevantes para o sistema.


��

��

� ��

��

� ��

� ��

��

��

2.4. RESPONSABILIDADES E COLABORAÇÕES DE UMA CLASSE Nos sistemas de software orientados a objetos (SSOO), objetos encapsulam dados e comportamentos. O comportamento

é definido de modo que ele cumpra suas responsabilidades e estas são definidas como uma obrigação que o objeto tem para com o sistema, e por intermédio dessas responsabilidades, um objeto colabora com outros, visando o objetivo do sistema, conforme representa a figura 1. Portanto, “cada objeto tem um conjunto de responsabilidades dentro do SSOO. Esse objeto tem como cumprir sozinho algumas dessas responsabilidades. Já para outras responsabilidades, o objeto necessita da colaboração de outros objetos.” (BEZERRA, 2007, p.145).

Figura 1. Responsabilidades e Colaboradores Fonte: Bezerra, 2007, p. 146

3. CRC

Segundo Bezerra (2007), a técnica de modelagem CRC baseia-se no paradigma da orientação a objetos, no que diz respeito a responsabilidades e colaborações, e se mostra eficaz quando alunos iniciantes e profissionais que não tenham tanta experiência neste paradigma estão envolvidos no processo de identificação das classes do sistema.

Rubin (1998) define a modelagem com o uso dos cartões CRC como uma técnica simples e poderosa de análise orientada a objetos. A modelagem CRC frequentemente oferece a inclusão de usuários, analistas e desenvolvedores nos processos de modelagem, formando entre os integrantes da equipe de desenvolvimento, um entendimento comum da construção do projeto orientado a objetos.

Para Börstler (2005), a interpretação do cenário (atuação do participante na sessão) é a forma mais efetiva de simular ou explorar situações hipotéticas. 3.1. PROPÓSITOS DO CRC

Beck (1989) introduziu os cartões CRC com o objetivo de possibilitar uma experiência direta em orientação a objetos para aprendizes (alunos iniciantes).

Segundo Börstler (2005), a CRC foi originalmente descrito como uma ferramenta de ensino de orientação a objetos para programadores. Trata-se de uma prática simples para modelar a colaboração entre os objetos. Muitos educadores adotaram essa prática para aproximar o ensino à tecnologia da orientação a objetos.

Apesar de o propósito inicial da técnica ter sido ensinar iniciantes na orientação a objetos, “a sua simplicidade de notação a tornou particularmente interessante para ser utilizada na identificação de classes” (BEZERRA, 2007, p.147).

Segundo Beck (1989), o cartão CRC caracteriza objetos pelo nome da classe, suas responsabilidades e colaboradores. Todas as informações dos objetos devem ser escritas em um cartão com medidas de 4”x 6”, com aproximadamente 10cm x 15cm, e ainda com a vantagem de serem baratos, de fácil leitura, com boa portabilidade, ou seja, fáceis de manipular. O topo do cartão deve conter o nome da classe com a primeira letra em maiúsculo, as responsabilidades devem ser escritas na coluna do lado esquerdo do cartão e os colaboradores, se existirem, devem ser escritos do lado direito do cartão, conforme mostra a figura 2. O verso do cartão deve conter uma descrição sucinta da classe em questão.


Figura 2. Cartão CRC Fonte: Beck (1989, p.6)

3.2. A EQUIPE CRC

Segundo Bezerra (2007), durante a modelagem CRC, uma equipe composta por especialista do domínio, desenvolvedores e colaboradores se reúnem e iniciam a sessão CRC. Essa sessão conta com no máximo seis pessoas.

De acordo com Rubin (1998), usuários do domínio, analistas, facilitadores, documentadores e observadores podem fazer parte de uma sessão CRC, mas somente os três primeiros atuam ativamente na sessão. Os membros dessa equipe devem ter algumas características, como por exemplo: os usuários do domínio devem conhecer o negócio que está sendo modelado, ter pensamento lógico e boa habilidade de comunicação, enquanto que os analistas e facilitadores devem entender os processos, a própria técnica e possuir habilidades em reuniões, além de entender os aspectos da modelagem orientada a objetos. 3.3. O AMBIENTE CRC

Para Rubin (1998), a sessão CRC deve acontecer em uma sala ampla, ao redor de uma mesa de reuniões, que possibilite total interação entre os participantes. Uma sala extra pode ser considerada, dependendo da quantidade de observadores. 3.4. A SESSÃO CRC

Segundo Bezerra (2007), uma sessão CRC é uma reunião que envolve a equipe. Ao ser iniciada, cada membro recebe um cartão. Cada cartão corresponde a uma classe. Uma vez que os participantes têm os cartões distribuídos, um caso de uso é selecionado e a sessão é iniciada. Algum membro do grupo simula o ator e dispara a realização do caso de uso. Em uma única sessão, mais de um caso de uso pode ser analisado, dependendo de sua complexidade. À medida que esse participante simula a interação do ator com o sistema, os demais participantes encenam a colaboração dos objetos que ocorre internamente no sistema, para que o objetivo do sistema seja alcançado. Devido à encenação desempenhada pelos participantes da sessão CRC, classes, responsabilidades e colaborações são identificadas (BEZERRA, 2007, p. 149).

4. APLICAÇÃO DA TÉCNICA CRC

Uma pesquisa realizada com 116 alunos iniciantes de cursos de Informática apontou algumas dificuldades na elaboração do diagrama de classes da UML. Nessa pesquisa, 75% dos alunos possuíam entre 16 e 25 anos de idade, e 67% declararam ter um baixo nível de conhecimento em orientação a objetos, conforme é apresentado na Tabela 1.

Nível de conhecimento com orientação a objetos.

Alto 1 1%

Médio 36 31%

Baixo 78 67%

Nenhum 1 1%

Tabela 1. Nível de conhecimento em orientação a objetos

Fonte: (AUTORES, 2010)


Quando questionados sobre as técnicas mais relevantes para a elaboração de um diagrama de classes, 26% das respostas apontaram para a Modelagem CRC, conforme demonstra a figura 3.

Figura 3. Técnicas mais relevantes para elaboração do diagrama de classes Fonte: (AUTORES, 2010)

Este trabalho aplica a técnica de Modelagem CRC para melhorar o entendimento na elaboração de diagramas de

classes. Um dado interessante neste sentido também é visto na figura 3, em que 65% dos alunos responderam Análise de Caso de Uso como sendo a técnica mais relevante para a elaboração de um diagrama de classes. Uma informação importante é que a técnica CRC também se baseia nos cenários dos casos de uso. 4.1. PLANEJAMENTO DAS SESSÕES CRC

O projeto escolhido neste trabalho refere-se a um projeto de software de rádio táxi. Para cada participante foi entregue a documentação do sistema que era composta por uma descrição do domínio, o diagrama de caso de uso e a descrição textual dos casos de uso. Para este projeto, 2 sessões CRC foram previstas. A equipe foi formada por 6 alunos além do acompanhamento do trabalho por 1 professor. A descrição do cenário do sistema de rádio táxi é apresentada no Quadro 1 (MELO, 2006).

Quadro 1. Descrição do cenário do sistema de rádio táxi Fonte: Melo (2006)

A empresa de Rádio Táxi Mar & Sol precisa de uma aplicação que controle: o cadastro de seus clientes; o cadastro dos cooperados; o cadastro das corridas programadas. Para cada cliente são cadastrados os seguintes dados: código (que deve ser gerado pelo sistema), nome, endereço completo (Iogradouro, número, complemento, bairro, município, estado) e dois telefones de contato. O cliente pode se cadastrar apenas com o nome para agilizar o processo. Quando fizer sua primeira chamada por telefone, seus dados serão atualizados. Para o cooperado (taxista) cadastram-se: nome, CPF, número da carteira de motorista, categoria, data de validade da carteira, número do táxi na cooperativa (conhecido como número de VR), número da placa, modelo do veículo, fabricante, cor do veículo, endereço residencial completo, telefone residencial e celular e data de entrada na Cooperativa. Quando o cooperado se desliga, deve ser cadastrada a data de desligamento. Quando o cliente solicitar uma corrida programada (pedidos com antecedência maior do que meia hora), cadastra-se no controle de corridas: o endereço de saída do carro, o bairro de destino, a data e hora de saída, telefone de contato (se local de saída diferente do cadastro). Se o cliente não for cadastrado, seu cadastro deve ser feito no momento da solicitação do carro. O status dessa corrida deve ser definido como: "aguardando VR". Uma hora antes da corrida programada, a operadora questiona, pelo rádio, aos cooperados que estejam em trânsito, qual deseja pegar a corrida programada. Deve ser cadastrado na aplicação o número da VR do taxista que se candidatou à corrida. Meia hora antes do horário, o cliente deve ser avisado a respeito do número da VR. Antes de avisar ao cliente, o status deve ser assinalado como: "aguardando aviso". Após o aviso, o status muda para "aviso efetuado". Após ser atendido, o status deve ser alterado para: "tripulado". Em qualquer momento a corrida pode ser cancelada pelo passageiro. Se for uma solicitação de carro imediato, a operadora deve retornar à tela, informando o status dentre as opções: "aguardando aviso", "aviso efetuado", "cancelado pelo passageiro" ou "cancelado pela cooperativa por falta de carro". Se um logradouro não estiver na lista, a solicitação não será atendida. Quando o cliente for atendido, o status deve ser alterado para: "tripulado”.


O diagrama de casos de uso do sistema de rádio táxi é apresentado na Figura 4 (MELO, 2006).

Figura 4. Diagrama de casos de uso do sistema de rádio táxi.

Fonte: Melo (2006) 4.2. PRIMEIRA SESSÃO CRC DO SISTEMA DE RÁDIO TÁXI

A sessão CRC para o levantamento de classes do sistema de rádio táxi teve duração de 75 minutos e contou com a participação de quatro integrantes. Um atuou como facilitador, e leu o enunciado e as descrições dos casos de uso. Dois atuaram como especialistas do domínio enquanto que o quarto participante atuou como analista. As figuras 5 e 6 ilustram os cartões CRC indicando algumas classes extraídas a partir dessa sessão: Carro e Logradouro, respectivamente.

Figura 5. Cartão representando a classe Carro Fonte: (AUTORES, 2010)


Figura 6. Cartão representando a classe Cliente Fonte: (AUTORES, 2010)

Nesta sessão, em que foi apresentado o enunciado para o sistema de rádio táxi, os participantes se mostraram

preparados para atuar no cenário, porém a equipe deparou-se com um sistema um pouco complexo. Este cenário envolveu detalhes e os participantes dispensaram a maior parte do tempo da sessão procurando por um cartão CRC (uma classe de objetos) que estabelecesse uma ligação para todos os demais cartões. Apesar disso, o facilitador encerrou os trabalhos e foi observada a necessidade da realização de uma nova sessão para concluir a identificação das classes para este sistema. 4.3. SEGUNDA SESSÃO DO SISTEMA DE RÁDIO TÁXI

A segunda sessão para a identificação de classes para o sistema de rádio táxi foi realizada uma semana após a primeira. Teve duração de 80 minutos e contou com a participação de dois integrantes que não participaram da primeira sessão. Um deles participou apenas como observador, por isso não exerceu qualquer atuação no cenário. O outro atuou como analista e apoiou os trabalhos na sessão.

Na segunda sessão para o levantamento de classes para o sistema de rádio táxi, o facilitador iniciou a sessão separando sobre a mesa os cartões produzidos na sessão anterior. Após uma nova leitura do cenário, os participantes repassaram suas responsabilidades e colaborações. O ponto mais importante dessa sessão se deu quando os atuantes concluíram que havia a necessidade de criação de mais dois cartões. Um cartão representaria a classe Corrida, o que fez o objeto controleCorrida transferir alguma de suas responsabilidades e colaborações, tornando a atuação mais coesa. Também ocorreu a inclusão do cartão representando a classe HistóricoVr que possibilitou a identificação de responsabilidades que a equipe julgou estar faltando, gerando assim uma solução mais completa para o cenário.

A nova sessão resultou numa melhoria substancial no diagrama de classes. O envolvimento dos participantes na busca pela solução do cenário, bem como suas contribuições na sessão anterior, possibilitou a visão apresentada na Figura 7.


Figura 7. Diagrama de classes construído a partir dos cartões CRC Fonte: (AUTORES, 2010)

4.4. RESULTADOS OBTIDOS

Para o sistema de rádio táxi, duas sessões CRC foram realizadas. Dos aspectos observados e que merecem destaque, pode-se mencionar o empenho e o envolvimento dos participantes nas sessões CRC. Os alunos conduziram as reuniões e identificaram as principais classes do sistema proposto. Eles mesmos reconheceram que é possível melhorar ainda mais os modelos gerados por meio dessas atuações, e que o fato de participar como sendo o próprio objeto contribui para a compreensão do sistema como um todo. Em um SSOO, a aplicação da técnica CRC melhora a compreensão dos princípios e conceitos da orientação a objetos, ao passo que estimula a abstração, que geralmente é a maior dificuldade entre os alunos iniciantes em orientação a objetos. A aplicação da técnica CRC para o levantamento de classes de análise de um projeto de software orientado a objetos pode contribuir para um melhor entendimento do paradigma da orientação a objetos, mas essa contribuição somente pode ser dada se o aluno já possui conhecimentos mínimos deste paradigma.

5. CONSIDERAÇÕES FINAIS

O ensino do paradigma da orientação a objetos traz aos alunos e professores alguns desafios. De um lado, mestres introduzindo e contextualizando os conceitos de análise e projeto de sistemas de software. De outro, alunos que precisam entender e aplicar os conceitos em seus projetos. Como em um projeto de construção de um edifício, a sistematização dos processos e a aplicação de técnicas de construção podem contribuir para o sucesso da empreitada, em sistemas de software, de modo similar, a aplicação de técnicas pode auxiliar nos processos de desenvolvimento. Este trabalho considerou a aplicação da técnica CRC como um apoio ao processo de desenvolvimento de software.

A pesquisa realizada com 116 alunos revelou a dificuldade na elaboração de diagrama de classes da UML. Durante a pesquisa, a aplicação da técnica de modelagem CRC buscou explorar a mitigação dessa dificuldade, com a atuação de um grupo de alunos exercendo os papéis de objetos.

A pesquisa realizada e a aplicação da técnica CRC permitiram considerar que se os alunos atuarem como partes do sistema, representando seus objetos, esta atuação pode melhorar a compreensão durante as etapas de análise e projeto de um SSOO. Apesar de na etapa de análise não haver necessidade de se conhecer uma linguagem de programação, a aplicação da técnica CRC também permitiu constatar que os alunos tendem a enxergar as outras etapas do processo de


desenvolvimento de software. Este visão ficou evidenciada quando as responsabilidades dos objetos foram descobertas, alguns alunos já as associavam aos métodos que seriam implementados futuramente na linguagem de programação.

A técnica CRC pode ser mais bem explorada, para que seu propósito seja efetivamente atendido. Sua aplicação, no meio acadêmico exige tempo disponível e muito empenho. Por esta razão, o envolvimento e a dedicação dos participantes (alunos e professores), podem contribuir para o desenvolvimento dos conteúdos em cursos de análise e desenvolvimento de sistema, cujo paradigma é a orientação a objetos. Oportunidades de melhoria podem ser apresentadas, no sentido de maximizar a aplicação da técnica. 6. REFERÊNCIAS BECK, Kent. A Laboratory for Teaching Object-Oriented Thinking. OOPSLA’89, October, 1-6, 1989. BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus, 2007. BOOCH, Grady, RUMBAUGH, James, JACOBSON, Ivar. UML - Guia do usuário. Rio de Janeiro: Campus, 2005. BÖRSTLER, Jungen. Improving CRC-Card Role-Play with Role-Play Diagrams. OOPSLA’05, October16-20, 2005, San

Diego, California, USA. MELO, Ana Cristina. Exercitando modelagem em UML. Rio de Janeiro: Brasport, 2006. PRESSMAN, Roger. Engenharia de Software. São Paulo: McGraw-Hill, 2006. RUBIN, David M. Methodologies and Practices - Introduction to CRC Cards. Softstar Research, Inc:1998. RUMBAUGH, James, BOOCH, Grady, JACOBSON, Ivar. The Unifield Modeling Language References Manual. Boston:

Pearson Education, 2004. THOMASSON, Benjy, RATCLIFFE, Mark, THOMAS, Lynda.. Identifying Novice Difficulties in Object Oriented Design.

University of Wales, Aberystwyth Penglais Hill Aberystwyth, SY23 1BJ, ACM, 2006. VERGARA, Sylvia Constant. Métodos de pesquisa em administração. São Paulo: Atlas, 2005. WIRFS-BROCK, Rebecca, McKEAN, Alan. Object Design - Roles, Responsibilities, and Collaborators. Boston: Pearson

Education, 2002. 7. NOTA DE RESPONSABILIDADE

Os autores são os únicos responsáveis pelo conteúdo deste artigo.

Documents

Artigo Completo Aplicacao Da Tecnica CRC Em Projetos de Sistema de Software Orientado a Objetos