FACULDADE DE TECNOLOGIA DA ZONA LESTE
WELLINGTON VIEIRA DOS SANTOS
APLICAÇÃO DA TÉCNICA CRC (CLASSE, RESPONSABILIDADE E
COLABORAÇÃO) EM PROJETOS DE SISTEMA DE SOFTWARE
ORIENTADO A OBJETOS.
ESTUDO DE CASO – FATEC ZL
SÃO PAULO
2010
2
FACULDADE DE TECNOLOGIA DA ZONA LESTE
WELLINGTON VIEIRA DOS SANTOS
APLICAÇÃO DA TÉCNICA CRC (CLASSE, RESPONSABILIDADE E
COLABORAÇÃO) EM PROJETOS DE SISTEMA DE SOFTWARE
ORIENTADO A OBJETOS.
ESTUDO DE CASO – FATEC ZL
Monografia apresentada no curso de
Tecnologia em Informática para
Gestão de Negócios na FATEC – ZL
como requisito parcial para obter o
título de Tecnólogo em Informática
para Gestão de Negócios
Orientador: Msc. Wilson Vendramel
SÃO PAULO
2010
3
Nome: Santos, Wellington Vieira dos.
Título: APLICAÇÃO DA TÉCNICA CRC (CLASSE, RESPONSABILIDADE E
COLABORAÇÃO) EM PROJETOS DE SISTEMA DE SOFTWARE
ORIENTADO A OBJETOS. ESTUDO DE CASO – FATEC ZL.
Monografia apresentada no curso de
Tecnologia em Informática para
Gestão de Negócios na FATEC – ZL
como requisito parcial para obter o
título de Tecnólogo em Informática
para Gestão de Negócios
APROVADO EM:
BANCA EXAMINADORA
Prof.º Msc. Wilson Vendramel
Ass.: ____________________________
FATEC Zona Leste
Prof.º Msc. Ricardo Satoshi Oyakawa
Ass.: ____________________________
FATEC Zona Leste
Prof.ª Esp. Cintia Silva Stocchi
Ass.: ____________________________
Senac São Paulo – Unidade Itaquera
4
“À Minha esposa Adriana e nossas filhas Kathleen e
Gabriela pelo grande amor, compreensão e apoio
constante durante a realização deste trabalho”
5
AGRADECIMENTOS
A Deus, por ter me sustentado neste e em todos os momentos da minha vida
A Minha família pelo amor, carinho e atenção incomensuráveis.
Ao professor orientador Wilson Vendramel que, de forma brilhante, norteou-me
para a realização deste trabalho.
A todos os professores e colegas de turma que juntos trilhamos esta importante
etapa de nossas vidas na FATEC ZL.
Aos colegas Ana, Clayton, Danilo, Melanie, Tamires, Luiz, alunos do terceiro
semestre de informática, que de maneira muito prestativa, contribuiram para o
desenvolvimento do estudo de caso deste trabalho.
Aos colegas Caio Cacá, Stefano Teté, Alex Keké e Wellington Peopinho pela
equipe que formaram nos cinco primeiros semestres.
Aos colegas do SENAC Itaquera pelo companherismo e atenção prestados
durante todo o tempo do curso.
Ao SENAC-SP por permitir a aplicação quase plena dos conteúdos
desenvolvidos no curso.
Ao pastor e amigo Renato Mataitis pelo apoio.
6
LISTA DE FIGURAS
Figura 1. Diagramas da UML ........................................................................... 20
Figura 2. Responsabilidades e colaboradores ................................................. 22
Figura 3. Cartão CRC. ...................................................................................... 24
Figura 4. Cartão que representa a classe relatório. ......................................... 32
Figura 5. Cartão que representa a classe veículo. ........................................... 32
Figura 6. Cartão que representa a classe tabelePreço. ................................... 33
Figura 7. Cartão que representa a classe modeloCarro. .................................. 33
Figura 8. Cartão que representa a classe ticket. .............................................. 34
Figura 9. Diagrama de classes sugerido pela sessão CRC do sistema
estacionamento ................................................................................................ 35
Figura 10. Cartão que representa a classe pedido........................................... 37
Figura 11. Cartão que representa a classe entrega. ........................................ 37
Figura 12. Cartão que representa a classe encomenda. .................................. 38
Figura 13. Cartão que representa a classe cliente. .......................................... 38
Figura 14. Cartão que representa a classe placa. ............................................ 39
Figura 15. Diagrama de classe sugerido pela sessão CRC do sistema
encomenda de placas ...................................................................................... 40
Figura 16. Cartão que representa a classe Carro. ........................................... 42
Figura 17. Cartão que representa a classe cooperadoTaxista. ........................ 42
Figura 18. Cartão que representa a classe logradouro. ................................... 43
Figura 19. Cartão que representa a classe controleCorrida. ............................ 43
Figura 20. Cartão que representa a classe cliente. .......................................... 44
Figura 21. Diagrama de classe sugerido pela sessão CRC do sistema de radio
táxi .................................................................................................................... 45
Figura 22. Cartão que representa a classe cooperadoTaxista com suas
alterações. ........................................................................................................ 46
Figura 23. Cartão que representa a classe controleCorrida com suas
alterações. ........................................................................................................ 46
Figura 24. Cartão que representa a classe Cliente com suas alterações. ....... 47
Figura 25. Cartão que representa a nova classe identificada, HistoricoVr. ...... 47
Figura 26. Cartão que representa a a nova classe identificada, Corrida. ......... 48
Figura 27. Diagrama de classe construído a partir dos cartões CRC. .............. 49
7
LISTA DE QUADROS
Quadro 1. Cronograma das sessões CRC ....................................................... 29
Quadro 2. Alunos participantes das sessões CRC. .......................................... 29
Quadro 3. Descrição do cenário do sistema de estacionamento. .................... 30
Quadro 4. Descrição do cenário de encomenda de placas. ............................. 36
Quadro 5. Descrição do cenário do sistema de rádio táxi. ............................... 41
8
LISTA DE TABELAS
Tabela 1. Nível de conhecimento em orientação a objetos ............................ 27
Tabela 2. Exemplo de tabela de preço do enunciado do sistema de
estacionamento. ............................................................................................... 31
9
LISTA DE GRÁFICOS
Gráfico 1. Técnicas mais relevantes para a elaboração de diagrama de classes.
......................................................................................................................... 28
10
LISTA DE SIGLAS
CRC – Class, Responsibilities and Collaborations
OO – Object Orientation
UML – Unified Modeling Language
SSOO – Sistema de Software Orientado a Objetos
11
SUMÁRIO
1. INTRODUÇÃO ............................................................................................. 15
2. MODELAGEM DE CLASSES DE ANÁLISE................................................. 17
2.1. Conceitos de orientação a objetos ......................................................... 17
2.2. Fundamentos da UML ........................................................................... 19
2.3. Identificando classes de análise ............................................................ 21
2.4. Responsabilidades e colaborações de uma classe ............................... 22
3. MODELAGEM CRC ..................................................................................... 23
3.1. Propósitos do CRC ................................................................................ 23
3.2. A equipe CRC ........................................................................................ 25
3.3. O ambiente CRC ................................................................................... 25
3.4. A Sessão CRC ....................................................................................... 25
3.5. Definição dos Cenários .......................................................................... 26
4. APLICAÇÃO DA TÉCNICA CRC E ANÁLISE DOS RESULTADOS. ........... 27
4.1. Planejamento das sessões CRC ........................................................... 28
4.2. Cronograma ........................................................................................... 29
4.3. Identificação dos participantes ............................................................... 29
4.4. Documentação das sessões .................................................................. 30
4.4.1. Sistema de estacionamento............................................................... 30
4.4.1.1. Descrição do cenário do sistema de estacionamento .................. 30
4.4.1.2. Sessão CRC do cenário do sistema de estacionamento. ............ 31
4.4.2.3. Avaliação da sessão .................................................................... 34
4.4.2. Sistema de encomenda de placas ..................................................... 35
4.4.2.1. Descrição do cenário do sistema de encomendas de placas ....... 35
4.4.2.2. Sessão CRC do cenário do sistema de encomenda de placas .... 36
4.4.2.3. Avaliação da sessão .................................................................... 39
4.4.3. Sistema de rádio táxi ......................................................................... 40
4.4.3.1. Descrição do cenário do sistema de rádio táxi ............................. 40
4.4.3.2. Primeira sessão CRC do sistema de rádio táxi ............................ 41
4.4.3.3. Avaliação da primeira sessão....................................................... 44
4.4.3.4. Segunda sessão do sistema de rádio táxi .................................... 45
4.5. Resultados obtidos ................................................................................ 49
12
5. CONSIDERAÇÕES FINAIS ......................................................................... 51
REFERÊNCIAS ................................................................................................ 53
ANEXOS .......................................................................................................... 55
APÊNDICES..................................................................................................... 70
13
Santos, Wellington Vieira dos. APLICAÇÃO DA TÉCNICA CRC (CLASSE,
RESPONSABILIDADE E COLABORAÇÃO) EM PROJETOS DE SISTEMA
DE SOFTWARE ORIENTADO A OBJETOS. ESTUDO DE CASO – FATEC
ZL. 2010. 74 fls. Trabalho de Conclusão de Curso (Tecnólogo em Informática
para Gestão de Negócio)
RESUMO
O ensino de análise e desenvolvimento de sistemas atualmente fundamenta-se
no paradigma da orientação a objetos. Alunos iniciantes apresentam um alto
nível de dificuldade na elaboração de modelos, como o modelo de Classes,
utilizados na fase de análise de um sistema de software. O objetivo deste
trabalho é conceituar CRC e aplicar a técnica CRC para modelagem de classes
de análise em projetos de sistema de software, entre alunos do terceiro
semestre do curso de Informática para gestão de negócios da FATEC ZL. Com
a realização de sessões (reuniões) intenciona-se, através da atuação dos
participantes, a identificação das classes, permitindo maior compreensão na
elaboração de diagrama de classes da Unified Modeling Language (UML).
Essa técnica traz resultados positivos, por apresentar uma melhora no
entendimento de orientação a objetos pelos participantes.
Palavras-chave: Técnica CRC, Sessão CRC, Orientação a Objetos, Classes
de análise
14
Santos, Wellington Vieira dos. APLICATION CLASS, RESPOSIBILITIES AND
COLABORATIONS (CRC) TECHNIQUE IN DESIGN SYSTEM OF
SOFTWARE OBJECTS ORIENTED. CASE STUDY– FATEC ZL. 2010. 74 f.
Conclusion of Course (Tecnólogo em Informática para Gestão de Negócio).
ABSTRACT
The teaching of analysis and development of systems currently bases on the
paradigm of the objects orientation. Beginning students present one high level
of difficulty in the elaboration of models, as the model of Classes, used in the
phase of analysis of a software system. The objective of this work is to appraise
CRC and to apply technique CRC for modeling of classes’ analysis, into design
system software, between students of the third semester of the businessoriented course of Computer science for management of FATEC ZL. With the
accomplishment of sessions (meetings) intend, through the performance of the
participants, the identification of the classes, allowing bigger understanding in
the elaboration of diagram of classes of Unified Modeling Language (UML). This
technique brings positive resulted, for presenting an improvement in the
orientation agreement the objects for the participants.
Key words: CRC Technique, CRC Session, Objects Orientation, Classes’
Analysis
15
1. INTRODUÇÃO
Com o crescimento das redes de informação e a necessidade do
desenvolvimento de aplicações para muitos fins, aumenta a busca por
especialização na área de sistemas. Isso leva para os cursos técnicos e de
tecnologia em sistema de informação um público bastante eclético. Outro fator
que estimula a procura por esses cursos é a remuneração. Matéria publicada
pela Universia (2006) já apontava para esse fato.
Este trabalho tem por objetivo conceituar CRC e aplicar a técnica CRC para
modelagem de classes de análise em projetos
de desenvolvimento de
sistemas de software orientados a objetos.
Em ambientes educacionais podem ser percebidas dificuldades entre os alunos
no desenvolvimento de conteúdos 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 da análise e
desenvolvimento sistemas de software essas dificuldades, obviamente,
também existem e possuem suas causas e efeitos.
As metodologias utilizadas para o desenvolvimento deste trabalho serão a
pesquisa bibliográfica, com o intuito de ampliar o conhecimento sobre os
assuntos tratados e dar maior embasamento teórico e a 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. Aplicada entre alunos do terceiro semestre do curso de Informática
para gestão de negócios da FATEC ZL. A realização de sessões (reuniões)
visa, através da atuação dos participantes, identificarem tais classes.
Este trabalho está estruturado em cinco capítulos. Introdução, Modelagem de
classes de análise, Modelagem CRC, Aplicação da técnica CRC e análise dos
16
resultados e Considerações finais.
No capítulo segundo são abordados os
conceitos de orientação a objetos, conceitos fundamentais da UML e uma
introdução a responsabilidades e colaborações. No capítulo terceiro é
destacada uma abordagem da modelagem CRC, seu propósito e sua dinâmica
de aplicação. Embora este trabalho utilize uma metodologia de pesquisa-ação,
a FATEC Zona Leste é apresentada como estudo de caso no capítulo quarto.
Este descreve os passos e os resultados obtidos com a aplicação da técnica
CRC, bem como o envolvimento dos participantes, alunos da FATEC ZL na
pesquisa.
17
2. MODELAGEM DE CLASSES DE ANÁLISE
Segundo Bezerra (2007), o modelo de classes evolui conforme são realizadas
as iterações no desenvolvimento do sistema. O modelo vai sendo refinado à
medida que o sistema é desenvolvido, aonde novos elementos vão sendo
inseridos ou eliminados no diagrama. A modelagem de classes existe em três
níveis
sucessivos
de
abstração,
a
saber:
domínio,
especificação
e
implementação. O modelo de classes de domínio é usado para representar as
principais classes do negócio e não possui detalhamento ou definição das
restrições, que poderão 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 é uma extensão do modelo de classes de domínio,
onde neste são inseridos detalhes da solução escolhida. Por isso, nesse
modelo algumas classes são especificadas para desenvolver a solução. Este
modelo é desenvolvido na atividade 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, da solução, em uma linguagem de
programação, linguagem esta normalmente orientada a objetos.
O modelo de classes de domínio representa termos do domínio do
negócio. Seu objetivo é descrever o problema representado pelo
sistema a ser desenvolvido; ele não considera características da
solução a ser utilizada. Já os modelos de especificação e de
implementação consideram detalhes da solução de software a ser
utilizada. No entanto, ao contrário do modelo de implementação, o de
especificação descreve a solução em um nível mais alto de
abstração. (BEZERRA, 2007, p. 97),
2.1. Conceitos de orientação a objetos
Segundo 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 e fácil, 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.
18
Para Bezerra (2007), uma característica presente em um sistema de software é
a complexidade de seu desenvolvimento. Essa aumenta conforme o sistema
cresce. Isso pode ser comparado à construção de sistemas habitacionais, pois
quanto maior o projeto, maiores serão as dificuldades e complexidade para sua
execução. E também serve para conceituar a modelagem de um sistema de
software e revela a necessidade da criação de modelos, que possam
representar de forma mais ampla na 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;

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). Este
paradigma permite a diminuição da diferença semântica entre a realidade
sendo modelada e os modelos sendo construídos
Bezerra (2007) define objetos como sendo coisas do mundo real, na
terminologia da orientação a objetos. Recebem o nome de operações algumas
ações que um objeto sabe realizar quando solicitado. Todos os conceitos até
aqui abordados são, na verdade, a aplicação do mais básico e único conceito,
o princípio da abstração; “abstração é um processo mental pelo qual nós seres
humanos nos atemos as aspectos mais importantes (relevantes) de alguma
coisa”, ao passo que são ignorados os menos importantes.
Rumbaugh, Booch e Jacobson (2004, p. 215) definem classes como “uma
coleção de objetos que compartilham os mesmos atributos, operações,
19
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 computador
(para modelo de projeto) 1
2.2. Fundamentos da UML
A Unified Modeling Language (UML) é uma linguagem padrão para a
modelagem de sistemas de software que permite a elaboração da estrutura de
projetos, definem os criadores da linguagem. “A UML é apenas uma linguagem
e, portanto, é somente parte de método de para desenvolvimento de software”
(BOOCH; RUMBAUGH; JACOBSON, 2005, p. 13). A linguagem UML é
destinada a visualizar, especificar, construir e documentar artefatos de um
sistema complexos de software. Ela 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.
De acordo com Booch, Rumbaugh e Jacobson (2005), existem quatro tipos de
itens especificados na UML, e aqui também seus subitens, a saber:

Itens estruturais: representam a parte estática do modelo
o classes
o interfaces
o colaborações
o caso de uso
o classes ativas
o componentes
1
Tradução nossa. Cf. original: “a set the objects that share the same attributes, operations,
methods, relationships and behavior. A class represents a concept within the system being
modeled. Depending on the kind of model, the concept may be real-word (for an analysis
model), or it may also contain algorithmic and computer implementation concepts (for a design
model)”
20
o artefato
o nó

Itens comportamentais: representam a parte dinâmica do modelo
o interação
o máquina de estado
o ação (atividade)

Itens de agrupamento: representam as partes organizacionais do
modelo
o pacote

Itens anotacionais: representam as partes explicativas dos modelos
o notas
Ainda segundo Booch, Rumbaugh e Jacobson (2005), a UML inclui 13
diagramas que tem por objetivo geral a apresentação gráfica de um modelo,
exibindo conjuntos de elementos que incluem itens e relacionamentos.
Diagramas são criados para permitir uma visualização de um sistema sob
diferentes perspectivas.
A figura 1 exibe os 13 diagramas da UML, este
trabalho dá ênfase ao diagrama de classes.
Figura 1. Diagramas da UML
Fonte: Bezerra, 2007
21
2.3. Identificando 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 do espaço da solução.
Ainda segundo Pressman (2006), classes de análise se manifestam por si
mesmas, por um dos modos como: entidades externas que produzem e
consomem informação a ser usada por um sistema baseado em computador;
coisas que são parte do domínio de informação do problema; ocorrência ou
eventos que ocorrem dentro do contexto da operação; papéis desempenhados
por pessoas que operam o sistema; unidades organizacionais que são
relevantes para a aplicação; lugares que estabelecem o contexto do problema,
ou função macro do sistema; estruturas que definem uma classe de objetos ou
classes relacionadas de objetos.
A identificação das classes também é dividida em duas atividades. Identificar
classes candidatas, primeira atividade, é relativamente fácil, eliminar o conjunto
de classes “desnecessárias”, é a tarefa mais complicada.
... Importante notar que as atividades para identificação de classes
candidatas não são sequenciais. (uma não começa quando a outra
acaba). Ao contrário, os desenvolvedores intercalam a realização
dessas atividades, identificando novas candidatas e removendo
candidatas previamente identificadas... (BEZERRA, 2007, p. 137-138)
Para Bezerra (2007), há dois métodos para identificar classes de domínio de
um sistema. Um dirigido a dados e o outro dirigido a responsabilidade.

Método dirigido a dados: enfatiza a estrutura dos conceitos relevantes
para o domínio do negócio. Isso resulta no modelo conceitual;

Método dirigido a responsabilidade: a ênfase está na identificação das
classes a partir de seus comportamentos mais relevantes para o
sistema.
22
2.4. Responsabilidades e colaborações de uma classe
Nos sistemas de softwares orientados a objetos (SSOO), objetos encapsulam
dados e comportamentos. O comportamento é definido de modo que ele
cumpra suas responsabilidades e essas responsabilidades são definidas como
uma obrigação que o objeto tem no sistema, e por intermédio dessas
responsabilidades um objeto colabora com outros, visando o objetivo sistema,
conforme
figura
2.
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)
Objetos
possuem
realizadas por
Responsabilidades
Colaboradores
O que o objeto conhece
+
O que o objeto faz
O padrão de cooperação
(comunicação) entre objetos
precisam de
Figura 2. Responsabilidades e colaboradores
Fonte: Bezerra, 2007, p. 146
23
3. MODELAGEM CRC
Segundo Bezerra (2007), essa técnica de modelagem CRC se baseia no
paradigma da orientação a objetos, no que diz respeito a responsabilidades e
colaborações e se mostra eficaz quando alunos iniciantes no desenvolvimento
de modelos e profissionais que não tenham tanta experiência nesse
paradigma, estão envolvidos no processo de identificação de classes do
sistema.
Rubin (1998) define como simples e poderosa técnica de análise orientada a
objetos, a modelagem com o uso dos cartões CRC. A modelagem CRC
frequentemente oferece a inclusão de usuários, analistas e desenvolvedores
nos processos de modelagem, formando entre a equipe de desenvolvimento
um entendimento comum do desenvolvimento do projeto orientado a objetos.
Para Börstler (2005), a interpretação (atuação do participante da sessão) do
cenário é 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 dar uma experiência
direta em objetos para aprendizes, alunos iniciantes em engenharia de
software.
Segundo Börstler (2005), o CRC foi originalmente descrito como uma
ferramenta de ensino da idéia de orientação a objetos para programadores.
São simples ferramentas para informar colaboração na modelagem orientada a
objetos. Muitos educadores adotam essa prática para aproximar o ensino da
tecnologia na orientação a objetos
Apesar de o propósito inicial ser ensinar iniciantes na orientação a objetos, “a
sua simplicidade de notação a tornou particularmente interessante para ser
24
utilizada na identificação de classes” (BEZERRA, 2007, p. 147), conclui sobre a
técnica de modelagem CRC.
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 escrita em um cartão com medidas de 4” x 6”, aproximadamente 10
cm x 15 cm , 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 figura 3. O
verso do cartão deve conter uma descrição sucinta da classe em questão.
Figura 3. Cartão CRC.
Fonte: Beck (1989, p. 6)
25
3.2. A equipe CRC
Segundo Bezerra (2007), na modelagem CRC, uma equipe composta por
especialista do domínio e 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 OO, 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: Bons usuários
do domínio devem conhecer o negócio que está sendo modelado, ter
pensamento lógico e boa habilidade de comunicação. Bons analistas de projeto
e facilitadores devem entender os processos e metodologia CRC e habilidades
em reuniões e, é claro, entender os processos e metodologia 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 a interação uns com os
outros. E 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 CRC. Ao ser iniciada, cada membro recebe um cartão. Cada cartão
corresponde a uma classe. Uma vez que os participantes têm distribuídos os
cartões, um conjunto de caso de uso é selecionado. E para cada caso de uso
uma sessão será iniciada. Algum membro do grupo simula o ator e dispara a
26
realização do caso de uso. Em uma única sessão o caso de uso pode ser
analisado, dependendo de sua complexidade.
À medida que esse participante simula a interação do autor com o
sistema, os demais participantes encenam a colaboração entre
objetos que ocorre internamente ao sistema, para que o objetivo do
autor seja alcançado. Graças a essa encenação desempenhada
pelos participantes da sessão CRC, classes, responsabilidades e
colaborações são identificadas. (BEZERRA, 2007, p. 149)
3.5. Definição dos Cenários
O primeiro cenário deve ser definido cuidadosamente, pois segundo Börstler
(2005), iniciantes podem nunca chegar ao fim de quando um cenário é definido
livremente. Um bom cenário deve ter um objetivo claro e bem definido.
27
4. APLICAÇÃO DA TÉCNICA CRC E ANÁLISE DOS RESULTADOS.
Uma pesquisa realizada com 116 alunos dos níveis técnico, do Senac Itaquera
e superior das FATEC Zona Leste (FATEC ZL) e São Caetano do Sul apontou
algumas dificuldades desses estudantes na elaboração de diagrama de classes
da UML. Nessa pesquisa, 75% dos alunos têm entre 16 e 25 anos de idade.
Oitenta e sete por cento cursam o ensino superior e declarem ter baixo nível de
conhecimento em orientação a objetos, 67%, conforme Tabela 1.
Nível de conhecimento com orientação a objetos.
Alto
Médio
Baixo
Nenhum
1
36
78
1
1%
31%
67%
1%
Tabela 1– Nível de conhecimento em orientação a objetos
Fonte: autor
A
maioria
dos
pesquisados
é
formada
por
alunos
iniciantes
em
desenvolvimento de sistemas, e que ainda não cumpriram o ciclo inicial de
análise orientada a objetos. Eles auto-avaliaram em 83% entre baixo e médio
seu nível de conhecimento na elaboração de um diagrama de classes, e os três
itens deste diagrama onde encontram maiores problemas para aplicá-los são
respectivamente:
operação
abstrata
(52%),
classe
abstrata
(43%)
e
composição/agregação (33%).
Quando questionados sobre as técnicas mais relevantes para a elaboração de
um diagrama de classes, 26% das respostas apontam para a Modelagem CRC,
conforme apresentado no Gráfico 1.
28
2%
Técnicas mais
relevantes para
elaboração de
diagrama de classe
Outros
8%
Categoria de objetos
65%
CRC
26%
0%
20%
40%
Análise de Caso de Uso
60%
80%
Gráfico 1. Técnicas mais relevantes para a elaboração de diagrama de classes.
Fonte: autor
O objetivo da pesquisa é a aplicação da técnica de Modelagem CRC para
melhorar o entendimento na elaboração de diagrama de classes. Um dado
importante neste sentido também é visto no Gráfico 1, onde 65% dos alunos
responderam Análise de Caso de Uso como sendo mais relevante para a
elaboração de um diagrama de classes. Importante, pois a técnica CRC se
baseia nos cenários dos casos de uso.
O questionário elaborado para a aplicação desta pesquisa consta no
APÊNDICE A.
4.1. Planejamento das sessões CRC
Serão realizadas sessões para a aplicação da técnica CRC em três diferentes
níveis. Para tal, será entregue aos participantes os cenários que comporão as
três situações. Os cenários apresentados são sistemas de rádio táxi,
encomendas de placas e estacionamento. Todos com uma descrição do
domínio, o diagrama de caso de uso e a descrição textual dos casos de uso. E
acontecerão nas dependências da FATEC ZL, na biblioteca.
A primeira sessão deverá ser realizada para identificar as classes,
responsabilidades e colaboradores do sistema de estacionamento. Deverá
29
durar o tempo necessário para a identificação das principais classes do
sistema, ou até que o condutor da sessão julgue necessário marcar outra
sessão, em concordância com os demais. A segunda e terceira sessões
seguirão os mesmos passos da primeira, mas por se tratar de sistemas
maiores, encomenda de placas e rádio táxi, poderá ser necessária a realização
de mais uma sessão para realizar completamente a modelagem.
4.2. Cronograma
No Quadro 1, é exibida a sequência em que acontecerão as sessões, bem
como o número previsto de sessões CRC para cada sistema.
1. Sistema de estacionamento
Uma sessão prevista
2. Sistema de encomenda de placas
De uma a duas sessões previstas
3. Sistema de rádio táxi
Máximo de três sessões previstas
Quadro 1. Cronograma das sessões CRC
Fonte: autor
4.3. Identificação dos participantes
Alguns alunos do terceiro semestre 2010 do curso de Informática para Gestão
de Negócios da FATEC ZL do vespertino se voluntariaram a participar da das
sessões, relacionados conforme mostra o Quadro 2.
Ana C. S. Esteves
39
Clayton Gertrudes Amorim
21
Danilo Caetano da Silva
26
Melanie Alves Basilio de Souza
20
Tamires Schimith da Silva
19
Quadro 2. Alunos participantes das sessões CRC.
2
Fonte: autor.
2
Os alunos voluntários assinaram termo autorizando a publicação de seus nomes neste
trabalho. Uma cópia desta autorização consta no APÊNDICE B.
30
4.4. Documentação das sessões
A documentação das sessões é feita na sequência descrita no cronograma
das sessões, sendo, o sistema de estacionamento, o do sistema de
encomenda de placas e o sistema de rádio táxi.
4.4.1. Sistema de estacionamento
Este é o primeiro sistema a compor um cenário para a aplicação do CRC. Ele
apresenta um menor nível de detalhamento em relação aos demais. Para este
sistema está prevista apenas uma sessão CRC.
4.4.1.1. Descrição do cenário do sistema de estacionamento
O enunciado que descreve o cenário do sistema é exibido no Quadro 2, e a
Tabela 2, descreve as regras para os preços que devem ser praticados.
Bruno e seu pai compraram um terreno e inaugurarão um estacionamento. Para ajudar, a
irmã de Bruno está desenvolvendo uma aplicação de controle de estacionamento. Quando
o veículo entra no estacionamento, o atendente observa sua placa e a mesma é
cadastrada, juntamente com o modelo do veículo e sua cor. A hora de entrada é gerada
automaticamente, correspondendo ao momento do cadastramento da placa. Após
estacionar o veículo, o cliente pega o ticket onde está impresso: o número da placa, o
modelo do veículo, a cor, a data e a hora da entrada. Ao retornar ao estacionamento, o
cliente entrega o ticket. O tempo de permanência é calculado. Considerando esse tempo de
permanência, é aplicada a tabela de preços, sabendo-se que a tabela de sábado não é a
mesma dos dias úteis e, às vezes, dependendo da época do ano, os donos lançam
promoções durante os dias úteis. Os donos precisam de relatórios de faturamento diário e
semanal.
Quadro 3. Descrição do cenário do sistema de estacionamento.
Fonte: Melo (2006, p. 97-100)
31
Dia da semana
Sábado
Segunda à sexta
Valor
Preço único
1ª. Hora
R$ 3,00
R$ 2,00
A partir da 2ª. hora
R$ 1,00
(inteiro ou fração)
Tabela 2. Exemplo de tabela de preço do enunciado do sistema de estacionamento.
Fonte: Melo (2006)
Os casos de uso e a descrição textual dos casos de uso encontram-se no
ANEXO A.
4.4.1.2. Sessão CRC do cenário do sistema de estacionamento.
A sessão CRC para o levantamento de classes do sistema de estacionamento
teve início às dezoito horas e vinte minutos do primeiro dia de trabalho da
equipe. Esta teve duração de 68 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. O
quarto participante atuou como analista. Por algumas vezes o participante que
conduziu a sessão re-leu o cenário. As Figuras de 4 a 8 ilustram as classes
extraídas.
32
Figura 4. Cartão que representa a classe relatório.
Fonte: autor.
Figura 5. Cartão que representa a classe veículo.
Fonte: autor.
33
Figura 6. Cartão que representa a classe tabelePreço.
Fonte: autor.
Figura 7. Cartão que representa a classe modeloCarro.
Fonte: autor.
34
Figura 8. Cartão que representa a classe ticket.
Fonte: autor.
4.4.2.3. Avaliação da sessão
A sessão teve como ponto forte a identificação da principal classe do sistema,
a partir da leitura da descrição dos casos de uso. O ator, que no cenário
representava o papel de ticket, encenou a sequência descrita e, de forma
pontual, identificou as primeiras responsabilidades do objeto. Contudo, apesar
de na sessão terem sido identificadas algumas classes do domínio, a equipe
apresentou uma solução parcial, embora tenha culminado no diagrama
representado pela figura 9.
35
Figura 9. Diagrama de classes sugerido pela sessão CRC do sistema estacionamento
Fonte: autor
4.4.2. Sistema de encomenda de placas
Este sistema apresenta um nível maior de detalhamento em comparação com
o sistema de estacionamento. Para este sistema está prevista apenas uma
sessão CRC.
4.4.2.1. Descrição do cenário do sistema de encomendas de placas
A descrição completa do cenário proposto é exibida no Quadro 4.
36
João confecciona placas por encomenda. Como o volume dos
pedidos tem aumentado, ele pediu ao filho que lhe fizesse uma
pequena aplicação que controle: - o cadastro de seus clientes; - as
encomendas. Quando ele recebe uma encomenda, João anota num
caderninho o nome do cliente e seu telefone. Para a encomenda, ele
registra: o tamanho da placa (altura e largura), a frase a ser escrita,
cor da placa (branca ou cinza), cor da frase (azul, vermelho, amarelo,
preto ou verde), data de entrega, valor do serviço e valor do sinal. A
aplicação deve obrigar que o valor do sinal seja de, no mínimo, 50%.
Para calcular o valor da placa, as seguintes fórmulas são usadas:
área = altura x largura; custo_material = área x R$ 147,30;
custo_desenho = número_letras x R$ 0,32; valor_placa =
custo_material + custo_desenho. Para calcular o prazo de entrega,
considera-se que ele só consegue produzir seis placas por dia. João
deseja que o sistema controle os pedidos, calcule o preço final das
peças e o prazo de entrega. Para cada encomenda cadastrada, deve
ser emitido um recibo em duas vias (cliente e empresa), contendo
todos os dados da encomenda e do pagamento.
Quadro 4. Descrição do cenário de encomenda de placas.
Fonte: Melo (2006, p. 61-67)
Os casos de uso e a descrição textual dos casos de uso encontram-se no
ANEXO B.
4.4.2.2. Sessão CRC do cenário do sistema de encomenda de placas
A sessão CRC para o levantamento de classes do sistema de encomenda de
placas teve início às dezoito horas e trinta minutos do segundo dia de trabalho
da equipe. Esta teve duração de 71 minutos e contou com a participação de
cinco integrantes. Um atuou como facilitador, e leu o enunciado e as descrições
dos casos de uso. Dois atuaram como especialistas do domínio. O quarto e o
quinto participante atuaram como analistas. As figuras de 10 a 14 ilustram as
classes extraídas a partir dessa sessão.
37
Figura 10. Cartão que representa a classe pedido.
Fonte: autor.
Figura 11. Cartão que representa a classe entrega.
Fonte: autor.
38
Figura 12. Cartão que representa a classe encomenda.
Fonte: autor.
Figura 13. Cartão que representa a classe cliente.
Fonte: autor.
39
Figura 14. Cartão que representa a classe placa.
Fonte: autor.
4.4.2.3. Avaliação da sessão
O enunciado (cenário) para esta sessão apresentou um maior grau de
dificuldade em relação ao primeiro sistema, o de estacionamento. Contudo, foi
possível notar nos participantes um entusiasmo, na medida em que as classes
de domínio eram confirmadas, ainda na leitura do cenário. A equipe se mostrou
muito empenhada na descoberta de novas classes durante a sessão. A
encenação ficou mais evidente a cada linha, que juntos concordavam em
manter, enviar para outra classe ou apagá-la do cartão. O facilitador da sessão
interveio quando necessário e manteve equilibrada a sessão. Re-leituras do
cenário eram frequentemente sugeridas. Os participantes atingiram o objetivo
da sessão, e a partir dos cartões foi possível criar o diagrama de classes
exibido na figura 15.
40
Figura 15. Diagrama de classe sugerido pela sessão CRC do sistema encomenda de placas
Fonte: autor
4.4.3. Sistema de rádio táxi
Este sistema apresenta um nível maior de detalhamento em comparação com
o sistema de encomenda de placas. Para este sistema estavam previstas mais
de uma sessão CRC.
4.4.3.1. Descrição do cenário do sistema de rádio táxi
A descrição completa do cenário proposto para este cenário é descrita no
Quadro 5.
41
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”.
Quadro 5. Descrição do cenário do sistema de rádio táxi.
Fonte: Melo (2006)
Maiores detalhes como os casos de uso e suas descrições textuais encontramse no ANEXO C.
4.4.3.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
início às dezoito horas e quarenta minutos do terceiro dia de trabalho da
equipe. Esta 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. O
quarto participante atuou como analista. As figuras de 16 a 20 ilustram as
classes extraídas a partir dessa sessão.
42
Figura 16. Cartão que representa a classe Carro.
Fonte: autor
Figura 17. Cartão que representa a classe cooperadoTaxista.
Fonte: autor
43
Figura 18. Cartão que representa a classe logradouro.
Fonte: autor
Figura 19. Cartão que representa a classe controleCorrida.
Fonte: autor
44
Figura 20. Cartão que representa a classe cliente.
Fonte: autor
4.4.3.3. Avaliação da primeira sessão
Nesta sessão, em que foi apresentado o enunciado para o sistema de rádio
táxi, os participantes se mostraram mais preparados para atuar no cenário.
Porém a equipe deparou-se com um sistema maior e mais complexo. Este
cenário envolveu mais detalhes e os atores 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, principais, cartões. Apesar
disso, o facilitador, a aluna Tamires, encerrou os trabalhos com os atores. Foi
observada a necessidade da realização de uma nova sessão para concluir o
levantamento das classes para este sistema. A Figura 21 exibe o diagrama de
classes apresentado como solução parcial para resolução do enunciado do
sistema proposto.
45
Figura 21. Diagrama de classe sugerido pela sessão CRC do sistema de radio táxi
Fonte: autor
4.4.3.4. Segunda sessão do sistema de rádio táxi
A segunda sessão para extração de classes para o sistema de rádio táxi foi
realizada uma semana após a primeira. Foi iniciada às dezoito horas e
quarenta minutos, e teve duração de 80 minutos. Contou com a participação de
dois integrantes que não participaram da primeira sessão. Um deles, o Aluno
Luiz Antônio, participou apenas como observador, por isso não exerceu
qualquer atuação no cenário. O outro, o aluno Clayton Gertrudes, atuou como
analista e apoiou os trabalhos na sessão. As figuras de 22 a 26 exibem as
alterações e as inclusões dos novos cartões CRC.
46
Figura 22. Cartão que representa a classe cooperadoTaxista com suas alterações.
Fonte: autor
Figura 23. Cartão que representa a classe controleCorrida com suas alterações.
Fonte: autor
47
Figura 24. Cartão que representa a classe Cliente com suas alterações.
Fonte: autor
Figura 25. Cartão que representa a nova classe identificada, HistoricoVr.
Fonte: autor
48
Figura 26. Cartão que representa a nova classe identificada, Corrida.
Fonte: autor
4.4.3.5. Avaliação da segunda sessão
Na segunda sessão para o levantamento de classes para o sistema de rádio
táxi o facilitador, a aluna Tamires iniciou separando sobre a mesa, os cartões
produzidos na sessão anterior. Após a re-leitura do cenário os atores
repassaram suas responsabilidades e colaborações. O ponto mais importante
dessa sessão se deu quando os participantes concluíram que havia a
necessidade de criação de mais dois cartões. Um representaria a classe
atuando como corrida, o que fez o ator controleCorrida transferir alguma de
suas responsabilidades e colaborações, tornado a atuação mais coerente. E a
decisão de inclusão do cartão que representa a classe HistóricoVr possibilitou a
identificação de responsabilidades que a equipe julgou estarem faltando para
dar por completa a solução do 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
49
suas contribuições na sessão anterior, possibilitou a visão apresentada na
Figura 27.
Figura 27. Diagrama de classe construído a partir dos cartões CRC.
Fonte: autor
4.5. Resultados obtidos
Foram realizadas quatro sessões CRC que contaram com a participação de
seis alunos. Nessas sessões foram apresentados três cenários para três
sistemas diferentes. O sistema de estacionamento, considerado o menor deles,
seguidos pelo sistema de encomenda de placas, e sistema para serviço de
rádio táxi, este último, maior e mais detalhado.
Dos fatos que mereceram
destaque, o mais importante foi a dedicação, o empenho e o envolvimento dos
participantes nas sessões CRC. Os alunos conduziram as reuniões e
identificaram as principais classes dos sistemas propostos. 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 todo no sistema. Num SSOO, a aplicação da
50
técnica CRC, melhora a compreensão em OO, ao passo que estimula aquela,
que segundo a pesquisa aqui realizada, é a maior dificuldade entre alunos
iniciantes em orientação a objetos, a abstração. A aplicação da técnica CRC,
para 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 entre alunos iniciantes. Mas essa contribuição somente
pode ser dada se o aluno já possuir conhecimentos mínimos em orientação a
objetos.
51
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 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 igual modo, a aplicação de técnicas pode auxiliar nos
processos de desenvolvimento. Este trabalho considerou a aplicação da
técnica CRC como apoio ao processo de desenvolvimento software.
A modelagem de classes de análise foi explorada, no segundo capítulo,
conceituando orientação a objetos, e apontado as responsabilidades e
colaborações de uma classe, segundo os autores citados neste trabalho. No
capítulo terceiro, foi introduzido o conceito da modelagem CRC, bem como sua
dinâmica de aplicação.
A pesquisa realizada entre 116 alunos da FATEC São Caetano do Sul, FATEC
Zona Leste (FATEC ZL) e do SENAC SP (unidade Itaquera) revelou a
dificuldade na elaboração de diagrama de classes da UML entre os alunos,
tanto no nível técnico quanto no de graduação. No estudo de caso, a aplicação
da técnica de modelagem CRC, apresentada no capítulo quarto, 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 forem envolvidos como partes do sistema, representando os
objetos, podem melhorar seu entendimento e compreensão na análise e
projetos de SSOO. Apesar de na fase de análise não haver necessidade se
conhecer uma linguagem de programação, a aplicação da técnica CRC
também permitiu verificar que os alunos tendem a enxergar as outras fases do
processo de desenvolvimento de software. Isso ficou evidenciado quando, ao
52
serem descobertas as responsabilidades dos objetos, da supostas classes,
alguns alunos já as associavam aos métodos que seriam implementados 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 trabalho e por isso o envolvimento e a dedicação dos
participantes, alunos e professores, podem contribuir para o desenvolvimento
dos conteúdos em cursos de análise de SSOO. Oportunidades de melhoria
podem ser apresentadas, no sentido de maximizar a aplicação e o uso da
técnica.
53
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.
CASHMAN, M. Object-oriented domain analisys – ACM v.14, n.6, out. 1989.
FERREIRA, Aurélio Buarque de Holanda. Dicionário Aurélio Básico da
Língua Portuguesa. Rio de Janeiro: Folha de São Paulo/Nova Fronteira, 1988.
LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à analise e ao
projeto orientados a objetos. Tradução L. A. M. Salgado. Revisão R. T. Price.
Porto Alegre: Bookman, 2000.
MELO, Ana Cristina. Desenvolvendo Aplicações com UML2.0. 2. ed. Rio de
Janeiro: Brasport, 2004.
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.
SEVERINO, Antonio. Metodologia do Trabalho Cientifico. 23 ed. São
Paulo:Cortez, 2000.
54
THOMASSON, Benjy, RATCLIFFE, Mark, THOMAS, Lynda.. Identifying Novice
Difficulties in Object Oriented Design. University of Wales, Aberystwyth
Penglais Hill Aberystwyth, SY23 1BJ, ACM, 2006.
UNIVERSIA.
Sistemas
de
informação.
Publicado
em
23/01/2006
<http://www.universia.com.br/carreira/materia.jsp?materia=9843>
acessado
em 04/06/2010
VERGARA, Sylvia Constant. Métodos de pesquisa em administração. São
Paulo: Atlas, 2005.
VLIET, Hans van. Some Myths of Software Engineering Education. ICSE’05,
May,15-21,2005, St. Louis, Missouri, USA.
WASLAWICK, Raul Sidnei. Análise e projeto de sistemas de informação
orientados a objetos. São Paulo: Elsevier, 2004.
WIRFS-BROCK,
Rebecca,
McKEAN,
Alan.
Object
Design
-
Responsibilities, and Collaborators. Boston: Pearson Education, 2002.
Roles,
55
ANEXOS
ANEXO A Sistema estacionamento Melo (2006, p. 97-100)
ESTACIONAMENTO
Bruno e seu pai compraram um terreno e inaugurarão um estacionamento.
Para ajudar, a irmã de Bruno está desenvolvendo uma aplicação de controle de
estacionamento.
Quando o veículo entra no estacionamento, o atendente observa sua placa e a
mesma é cadastrada, juntamente com o modelo do veículo e sua cor.
A hora de entrada é gerada automaticamente, correspondendo ao momento do
cadastramento da placa. Após estacionar o veículo, o cliente pega o ticket onde
está impresso: o número da placa, o modelo do veículo, a cor, a data e a hora
da entrada.
Ao retornar ao estacionamento, o cliente entrega o ticket. O tempo de
permanência é calculado. Considerando esse tempo de permanência, é
aplicada a tabela de preços, sabendo-se que a tabela de sábado não é a
mesma dos dias úteis e, às vezes, dependendo da época do ano, os donos
lançam promoções durante os dias úteis. Veja exemplo das tabelas de preço:
Sábado
Preço único = R$ 3,00
Segunda à sexta
1ª. hora = R$ 2,00
A partir da 2ª. hora (inteiro ou fração) = + R$ 1,00
Os donos precisam de relatórios de faturamento diário e semanal.
DIAGRAMA DE CASOS DE USO
DESCRIÇÃO DOS CENÁRIOS
56
REGISTRAR ENTRADA DO VEÍCULO
Descrição: Este caso de uso tem por objetivo registrar os dados do veículo que
esteja entrando no estacionamento.
Ator: Atendente
Cenário Principal:
1. O sistema prepara uma lista de modelos de carro.
2. O usuário informa:
2.1.a placa do carro
2.2.0 modelo, selecionado de uma lista preexistente.
2.3.a cor
3. O sistema verifica e registra automaticamente a data e a hora de início do
estacionamento.
4. O usuário confirma as alterações.
5. O sistema atualiza os dados cadastrais do veículo.
5.1. O sistema imprime o ticket de estacionamento, como comprovante do
motorista. [Extends Caso de Uso Emitir Ticket de Estacionamento]
EMITIR TICKET DE ESTACIONAMENTO
Descrição: Este caso de uso tem por objetivo emitir o ticket de estacionamento
que o cliente irá levar após estacionar o veículo.
Ator: Atendente
Cenário Principal:
1. O sistema imprime:
1.1. data de ocupação da vaga
1.2. hora de início de ocupação da vaga
1.3. placa do veículo
1.4. modelo do veículo
1.5. cor do veículo
REGISTRAR SAÍDA DO VEÍCULO
Descrição: Este caso de uso tem por objetivo registrar a saída do veículo,
calculando o tempo de permanência e o valor a paqar pelo estacionamento.
Ator: Atendente
Cenário Principal:
1. O sistema prepara uma lista dos veículos que ainda não tiveram sua saída
registrada.
1.1. Para cada veículo, é exibido:
1.1.1. a placa do veículo
1.1.2. a hora de início
2. O usuário informa a placa da qual será dada a saída, selecionando de uma
lista preexistente.
2.1. O sistema calcula o tempo de permanência.
2.2.0 sistema calcula o preço do estacionamento, baseado no tempo de
permanência.
3. O sistema atualiza os dados cadastrais do veículo.
MANTER TABELA DE PREÇOS
Descrição: Este caso de uso tem por objetivo permitir a manutenção da tabela
de preços utilizada para calcular a permanência no estacionamento.
Ator: Atendente
57
Cenário Principal:
1. O sistema busca e exibe os valores para as seguintes informações:
1.1. dia da semana
1.2. valor da primeira hora
1.3. valor da hora subseqüente
1.4. se no dia é preço único
GERAR RELATÓRIO DE FATURAMENTO DIÁRIO
Descrição: Este caso de uso tem por objetivo emitir um relatório com o
faturamento diário do estacionamento.
Ator: Diretoria
Cenário Principal:
1. O sistema prepara uma lista de todas as vagas ocupadas no dia.
2. O sistema exibe:
2.1. placa do carro
2.2. tempo de permanência
2.3. valor pago
3. No final, o sistema exibe o total de valor recebido no dia.
GERAR RELATÓRIO DE FATURAMENTO MENSAL
Descrição: Este caso de uso tem por objetivo emitir um relatório com o
faturamento mensal do estacionamento.
Ator: Diretoria
Cenário Principal:
1. O sistema busca todas as vagas ocupadas durante o mês corrente.
2. O sistema exibe, para cada dia, que aparecerá em ordem crescente:
2.1.número de veículos atendidos
2.2. valor faturado no dia
58
ANEXO B. Sistema de encomenda de placas. Melo (2006, p. 61-67)
ENCOMENDA DE PLACAS
João confecciona placas por encomenda. Como o volume dos pedidos tem
aumentado, ele pediu ao filho que lhe fizesse uma pequena aplicação que
controle:
- o cadastro de seus clientes
- as encomendas
Quando ele recebe uma encomenda, João anota num caderninho o nome do
cliente e seu telefone. Para a encomenda, ele registra: o tamanho da placa
(altura e largura), a frase a ser escrita, cor da placa (branca ou cinza), cor da
frase (azul, vermelho, amarelo, preto ou verde), data de entrega, valor do
serviço e valor do sinal. A aplicação deve obrigar que o valor do sinal seja de,
no mínimo, 50%. Para calcular o valor da placa, as seguintes fórmulas são
usadas:
área = altura x largura
custo_material = área x R$ 147,30
custo_desenho = número_letras x R$ 0,32
valor_placa = custo_material + custo_desenho
Para calcular o prazo de entrega, considera-se que ele só consegue produzir
seis placas por dia. João deseja que o sistema controle os pedidos, calcule o
preço final das peças e o prazo de entrega. Para cada encomenda cadastrada,
deve ser emitido um recibo em duas vias (cliente e empresa), contendo todos
os dados da encomenda e do pagamento.
DIAGRAMA DE CASOS DE USO
59
DESCRIÇÃO DOS CENÁRIOS
CONSULTAR CLIENTE
Descrição: Este caso de uso tem por objetivo apresentar os clientes
cadastrados e habilitar a inclusão, alteração ou exclusão de clientes.
Ator: Diretor da empresa
Cenário Principal:
1. O sistema prepara uma lista de todos os clientes cadastrados.
2. O sistema oferece ao usuário:
2.1. Selecionar um cliente, para alterar seu cadastro;
2.2. Localizar um cliente ou conjunto de clientes por meio de pesquisa;
2.3.selecionar a opção de "inserir cliente".
3. Pesquisa de Cliente
3.1. Para localizar um cliente, o usuário deve inserir um trecho de nome e/ou
um trecho de telefone.
O sistema fará a busca parcial.
3.2. O sistema exibe a lista de clientes que satisfaça o critério, exibindo para
cada um:
3.2.1. código de identificação
3.2.2. nome do cliente
3.2.3. telefone
4. Inserção de Cliente
4.1.[lnclude Caso de Uso Manter Cliente)
5. Seleção de Cliente
5.1. Após selecionar um cliente, o sistema habilita as opções de "alterar cliente"
e "excluir cliente".
5.2.Se o usuário selecionar uma dessas opções, o sistema aciona o cadastro
de cliente. [lnclude Caso de Uso Manter Cliente)
MANTER CLIENTE
Descrição: Este caso de uso tem por objetivo permitir a inclusão, alteração ou
exclusão de dados ligados ao cadastro de clientes.
Ator: Diretor da empresa
Pré-condição: Receber a identificação do tipo de operação e os dados
cadastrais do cliente, no caso de alteração ou exclusão.
Cenário Principal:
60
1. Manutenção do Cadastro
1.1. Em caso de "Inclusão", o sistema habilita a edição dos dados.
1.2.Em caso de "Alteração", o sistema exibe os dados cadastrados e os habilita
para edição.
1.3. Em caso de "Consulta" ou "Exclusão", o sistema exibe os dados
cadastrados desabilitados
para edição.
1.3.1. No caso de exclusão, o sistema solicita a confirmação.
2. O usuário informa, no caso de "Alteração" ou "Inclusão":
2.1. nome do cliente
2.2. telefone de contato
3. O usuário confirma a operação realizada.
4.O sistema atualiza os dados cadastrais do cliente.
4.1. No caso de inclusão, o sistema gera automaticamente um código de
identificação.
Cenário Alternativo:
- Exclusão não permitida
Não é possível excluir um cliente que esteja associado a uma encomenda.
CADASTRAR CUSTO PARA CÁLCULO DO VALOR DE VENDA
Descrição: Este caso de uso tem por objetivo cadastrar os valores fixos de
custo, utilizados no cálculo do valor de venda das placas.
Ator: Diretor da empresa
Cenário Principal:
1.
O sistema busca os valores cadastrados para:
1.1. valor fixo do material
1.2. valor fixo da letra
2.
O usuário altera:
2.1. valor fixo do material
2.2. valor fixo da letra
3.
O usuário confirma o cadastramento.
4.
O sistema atualiza os valores no cadastro.
Cenário Alternativo:
- Valores Inexistentes no cadastro
Se não existir valor cadastrado para "valor fixo do material" e/ou "valor fixo da
letra", o sistema apresenta os campos em branco.
- Valores inconsistentes
Não pode ser cadastrado valor negativo para "valor fixo do material" e "valor
fixo da letra".
CADASTRAR ENCOMENDA
Descrição: Este caso de uso tem por objetivo cadastrar encomendas de placas.
Ator: Diretor da empresa
Cenário Principal:
61
1.
O sistema busca e exibe a lista dos clientes cadastrados, em ordem
alfabética de nome.
2.
O usuário seleciona um nome de cliente da lista preexistente.
3.
O sistema exibe ° telefone do cliente.
4.
O usuário informa os dados da encomenda:
4.1. altura da placa
4.2. largura da placa
4.3. frase para impressão
4.4. cor da placa, selecionada dentre as opções: cinza ou branca.
4.5. cor da frase, selecionada dentre as opções: azul, vermelho, amarelo, preto
ou verde.
4.6. o sistema associa a data da encomenda como sendo a data atual.
5.
O sistema calcula e exibe a data prevista de entrega do pedido.
5.1. [Extends Caso de Uso Calcular Prazo de Entrega]
6.
O sistema calcula e exibe o valor a pagar pela encomenda.
6.1. [Extends Caso de Uso Calcular Preço de Venda da Encomenda]
7.
O usuário informa o valor do sinal.
8.
O usuário confirma a encomenda.
9.
O sistema gera automaticamente um número de encomenda.
10.
O sistema emite um recibo, em duas vias, com os seguintes dados:
10.1. nome do cliente, telefone de contato, data da encomenda, frase a ser
impressa na placa, tamanho da placa (altura e largura), cor da placa, cor da
frase, valor da encomenda, data prevista de entrega e valor do sinal.
11. O sistema atualiza os valores no cadastro, lançando o status da
encomenda como "aberto".
Cenários Alternativos:
- Cliente não cadastrado
Se for um cliente novo, o usuário seleciona a opção de "cadastrar novo cliente".
[lnclude Manter Cliente].
- Valor do sinal insuficiente
O sistema não deve aceitar um valor de sinal inferior a 50% do valor de venda
da peça. No caso do sinal ser inferior, o sistema deve exibir uma mensagem de
erro, incluindo na mensagem o valor mínimo permitido.
CALCULAR PREÇO DE VENDA DA ENCOMENDA
Descrição: Este caso de uso tem por objetivo calcular o preço de venda de uma
placa, baseado nas informações recebidas para o cálculo.
Ator: Diretor da empresa
Pré-condição: Receber as seguintes informações: altura da placa, largura da
placa, frase para impressão.
Cenário Principal:
62
1.O sistema busca os valores cadastrados para "valor fixo do material" e "valor
fixo da letra".
2.O sistema calcula o preço de venda da encomenda, considerando as
seguintes fórmulas:
área = "altura da placa" x "largura da placa"
custo_material
= área x ''valor fixo do material"
número jetras
= quantidade de letras da 'frase para impressão".
custo_desenho
= númeroletras x "valor fixo da letra".
valor placa = custo_material + custo_desenho
3. O sistema retorna o "valorplaca",
Cenário Alternativo:
- Valores nulos
Se qualquer um dos valores de pré-condição estiver nulo, o sistema não
efetuará o cálculo.
Será exibida uma mensagem de erro e o valor de retorno será zero.
- Valores fixos inexistentes
Se não houver valor válido para "valor fixo do material" elou para "valor fixo da
letra", o sistema deve exibir uma mensagem de erro, informando que faltam
dados de referência para cálculo da encomenda.
CALCULAR PRAZO DE ENTREGA
Descrição: Este caso de uso tem por objetivo calcular o prazo de entrega de
uma determinada placa, de acordo com as encomendas que estão com o
status = "aberto".
Ator: Diretor da empresa
Cenário Principal:
1.
O sistema busca o total de encomendas com status = "aberto",
agrupados por data, excluindo se o dia atual.
2.
O sistema verifica a primeira data disponível da lista, onde o número de
encomendas seja inferior a seis.
3.
O sistema retoma a data disponível no item 2, como a data prevista de
entrega.
Cenário Alternativo:
- Nenhuma data disponível
Se não houver nenhuma data disponível dentro da lista recebida, o sistema
deve calcular a data prevista de entrega como sendo a maior data da lista
acrescida de um dia. Se a data prevista cair num sábado ou domingo, deve ser
incrementada até a segunda-feira.
- Nenhuma encomenda cadastrada
Se não houver nenhuma encomenda cadastrada, o sistema deve calcular a
data prevista de entrega como sendo a data da encomenda acrescida de um
dia. Se a data prevista cair num sábado ou domingo, deve ser incrementada
até a segunda-feira.
MODIFICAR STATUS DA ENCOMENDA
Descrição: Este caso de uso tem por objetivo modificar o status de uma
encomenda durante a sua execução.
Ator: Diretor da empresa
63
Cenário Principal:
1.
O usuário informa o número da encomenda.
2.
O sistema busca a encomenda e exibe:
2.1. o nome do cliente;
2.2. o telefone;
2.3. a data da encomenda;
2.4. a data de entrega;
2.5. o valor do pedido;
2.6. o valor do sinal;
2.7. o status atual da encomenda.
3.
O usuário modifica o status da encomenda para um dos seguintes
valores: "Pronto", "Cancelado" ou "Fechado".
4.
O usuário confirma a alteração do status.
5.
O sistema atualiza o cadastro com o novo status.
Cenários Alternativos:
- Encomenda Inexistente
Se o número da encomenda não existir, exibir ao usuário uma mensagem de
erro, e abrir uma lista de encomendas com status diferente de "Fechado" e
"Cancelado" para seleção.
- Alteração não permitida
Não é possível alterar o status de encomendas que estejam com o status
"Cancelado" ou "Fechado".
- Validação do Status
O status = "Aberto" só pode ser alterado para "Pronto" ou "Cancelado".
O status = "Pronto" só pode ser alterado para "Cancelado" ou "Fechado".
64
ANEXO C. Descrição do Sistema de Rádio táxi. Melo (2006, p. 67-74)
RÁDIO TÁXI MAR & SOL
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".
DIAGRAMA DE CASOS DE USO
65
DESCRIÇÃO DOS CENÁRIOS
CONSULTAR CLIENTE
Descrição: Este caso de uso tem por objetivo apresentar os clientes
cadastrados e habilitar a inclusão, alteração ou exclusão de clientes.
Ator: Operadora
Cenário Principal:
1. O sistema prepara uma lista de todos os clientes cadastrados.
2. O sistema oferece ao usuário:
2.1.selecionar um cliente, para alterar seu cadastro;
2.2.localizar um cliente ou conjunto de clientes por meio de pesquisa;
2.3.selecionar a opção de "inserir cliente".
3. Pesquisa de Cliente
3.1. Para localizar um cliente, o usuário deve inserir um trecho do nome do
cliente como critério
de pesquisa. O sistema fará a busca parcial.
3.2.0 sistema exibe a lista de clientes que satisfaça o critério, exibindo para
cada um:
3.2.1. código de identificação
3.2.2. nome do cliente
3.2.3. telefone
4. Inserção de Cliente
4.1.[lnclude Caso de Uso Manter Cliente]
5. Seleção de Cliente
5.1.Após selecionar um cliente, o sistema habilita as opções de "alterar cliente"
e "excluir cliente".
5.2.Se o usuário selecionar uma dessas opções, o sistema aciona o cadastro
de cliente. [Include Caso de Uso Manter Cliente]
MANTER CLIENTE
Descrição: Este caso de uso tem por objetivo permitir a inclusão, alteração ou
exclusão de dados ligados ao cadastro de clientes.
Ator: Diretor da empresa
66
Pré-condição: Receber a identificação do tipo de operação e os dados
cadastrais do cliente, no caso de alteração ou exclusão.
Cenário Principal:
1. Manutenção do Cadastro
1.1. Em caso de "Inclusão", o sistema habilita a edição dos dados.
1.2. Em caso de "Alteração", o sistema exibe os dados cadastrados e os
habilita para edição.
1.3.Em caso de "Consulta" ou "Exclusão", o sistema exibe os dados
cadastrados desabilitados para edição.
1.3.1. No caso de exclusão, o sistema solicita a confirmação.
2. O sistema prepara uma lista de todos os logradouros atendidos pela
Cooperativa.
3. O usuário informa, no caso de "Alteração" ou "Inclusão":
3.1. nome do cliente
3.2.logradouro, selecionado de uma lista preexistente. O sistema exibe o bairro,
a cidade e o estado.
3.4.dois telefones de contato, informando para cada um:
3.4.1. prefixo
3.4.2. número
3.4.3. tipo, selecionado entre as opções: residencial, comercial, celular ou
recado.
4. O usuário confirma a operação realizada.
5. O sistema atualiza os dados cadastrais do cliente.
5.1.No caso de inclusão, o sistema gera automaticamente um código de
identificação.
Cenário Alternativo:
- Exclusão não permitida
Não é possível excluir um cliente que esteja associado a uma corrida
cadastrada.
CONSULTAR COOPERADO
Descrição: Este caso de uso tem por objetivo apresentar os cooperados
(taxistas) cadastrados e habilitar a inclusão, alteração ou exclusão de
cooperados.
Ator: Área Administrativa
Cenário Principal:
1. O sistema prepara uma lista de todos os cooperados cadastrados.
2. O sistema oferece ao usuário:
Exercitando a Identificação de Casos de Uso e 71
2.1.selecionar um cooperado, para alterar seu cadastro;
2.2. Localizar um cooperado ou conjunto de cooperados por meio de pesquisa;
2.3.selecionar a opção de "inserir cooperado".
3. Pesquisa de Cooperado
3.1. Para localizar um cooperado, o usuário deve inserir um trecho do nome do
cooperado como critério de pesquisa. O sistema fará a busca parcial.
3.2. 0 sistema exibe a lista de cooperados que satisfaça o critério, exibindo
para cada um:
3.2.1. número da VR do cooperado
3.2.2. nome do cooperado
67
4. Inserção de Cooperado
4.1.[lnclude Caso de Uso Manter Cooperado]
5. Seleção de Cooperado
5.1. Após selecionar um cooperado, o sistema habilita as opções de "alterar
cooperado" e "excluir cooperado".
5.2. Se o usuário selecionar uma dessas opções, o sistema habilita o
cadastramento de cooperado. [Include Caso de Uso Manter Cooperado]
MANTER COOPERADO
Descrição: Este caso de uso tem por objetivo permitir a inclusão ou alteração
de dados ligados ao cadastro de cooperados.
Ator: Área Administrativa
Pré-condição: Receber a identificação do tipo de operação e os dados
cadastrais do cooperado, no caso de alteração ou exclusão.
Cenário Principal:
1. Manutenção do Cadastro
1.1. Em caso de "Inclusão", o sistema habilita a edição dos dados.
1.2. Em caso de "Alteração", o sistema exibe os dados cadastrados e os
habilita para edição.
1.3. Em caso de "Consulta" ou "Exclusão", o sistema exibe os dados
cadastrados desabilitados para edição.
1.3.1. No caso de exclusão, o sistema solicita a confirmação.
2. O sistema prepara uma lista de logradouros cadastrados.
3. O usuário informa, no caso de "Alteração" ou "Inclusão":
3.1.CPF
3.2.nome do cooperado
3.3.dados da carteira de motorista: número, categoria e data de validade
3.4.dados do veículo: número da VR (identificação do veículo na cooperativa),
número da placa, modelo, fabricante
3.5.endereço completo, considerando que o logradouro é selecionado de uma
lista preexistente. Ao selecionar o logradouro, o sistema exibe o bairro, a
cidade e o estado. O usuário completa o cadastro do endereço com o número e
complemento.
3.6. telefones residencial e celular
3.7.data de entrada na Cooperativa
3.8.data de saída da Cooperativa (somente para alteração)
4. O usuário confirma a operação realizada.
5. O sistema atualiza os dados cadastrais do cooperado.
MANTER LOGRADOURO
Descrição: Este caso de uso tem por objetivo apresentar os logradouros
atendidos pela cooperativa e habilitar a inclusão, alteração ou exclusão de
logradouros.
Ator: Área Administrativa
Cenário Principal:
1. O sistema prepara uma lista de todos os logradouros cadastrados.
2. O sistema oferece ao usuário:
2.1. selecionar um logradouro, para alterar seu cadastro;
2.2. localizar um logradouro ou conjunto de logradouros por meio de pesquisa;
68
2.3. selecionar a opção de "inserir cliente".
3. Pesquisa de Logradouro
3.1. Para localizar um logradouro, o usuário deve inserir um trecho do nome
e/ou do bairro como critério de pesquisa. O sistema fará a busca parcial.
3.2.0 sistema exibe a lista de logradouros que satisfaça o critério, exibindo para
cada um:
3.2.1. nome do logradouro
3.2.2. bairro
4. Manutenção do Cadastro
4.1. Em caso de "Inclusão", o sistema habilita a edição dos dados.
4.2. Em caso de "Alteração", o sistema exibe os dados cadastrados e os
habilita para edição.
4.3. Em caso de "Consulta" ou "Exclusão", o sistema exibe os dados
cadastrados desabilitados para edição.
4.3.1. No caso de exclusão, o sistema solicita a confirmação.
5. O usuário informa, no caso de "Alteração" ou "Inclusão":
5.1.nome do logradouro
5.2.bairro
5.3. cidade
5.4.UF
6. O usuário confirma a operação realizada.
7. O sistema atualiza os dados cadastrais do logradouro.
Cenário Alternativo:
- Exclusão não permitida
Não é possível excluir um logradouro que esteja associado a uma corrida,
cooperado ou cliente.
CADASTRAR CORRIDA
Descrição: Este caso de uso tem por objetivo cadastrar a solicitação dos
clientes de corridas programadas (que são pedidas com antecedência maior do
que meia hora) ou imediatas.
Ator: Operadora da central
Cenário Principal:
1, O usuário informa o código de identificação do cliente.
1.1.O sistema pesquisa o código e exibe: o nome do cliente, seu endereço e
telefones.
1.2.0 sistema exibe a lista de corridas programadas.
1.3.0 sistema oferece ao usuário:
1.3.1. selecionar uma corrida, para alterar seu cadastro;
1.3.2. alterar o cadastro do cliente;
1.3.3. selecionar a opção de "inserir corrida",
2. Manutenção do Cadastro
2.1. Em caso de "Inclusão", o sistema habilita a edição dos dados.
2.2. Em caso de "Alteração", o sistema exibe os dados cadastrados e os
habilita para edição.
2,3.Em caso de "Consulta", o sistema exibe os dados cadastrados
desabilitados para edição.
3. Alteração do Cadastro de Cliente:
3.1. [Include Caso de Uso Manter Cliente)
69
4, O usuário informa, no caso de "Alteração" ou "Inclusão":
4.1. Se o endereço de origem da corrida é o mesmo endereço do cliente.
4.2. Se não for o mesmo endereço:
4.2.1. o sistema prepara uma lista dos logradouros atendidos pela Cooperativa.
4.2.2. o usuário informa o logradouro de origem, selecionando de uma lista
preexistente.
4.2.3. o usuário informa o número e o complemento do logradouro, além de um
telefone de contato.
4.3. O usuário informa o bairro de destino da corrida.
4.4. O usuário informa a data e a hora para a qual a corrida deve ser
programada; ou se é uma corrida imediata.
5. Somente para "Alteração" de corrida:
5.1. o sistema prepara uma lista de veículos cadastrados.
5.2. o usuário informa o número da VR escolhida para a corrida.
5.3. se a VR tiver sido informada, o usuário poderá alterar o status da corrida
para uma das seguintes opções:
5.3.1. "aguardando aviso";
5.3.2. "aviso efetuado";
5.3.3. 'tripulado",
5.4. Em qualquer situação, o usuário poderá alterar o status da corrida para:
5.4.1. "cancelado pelo passageiro";
5.5. No caso de corrida imediata e não tendo sido informada a VR, o usuário
poderá alterar o status da corrida para:
5.5.1. "cancelado pela cooperativa por falta de carro".
6. O usuário confirma a operação realizada.
7. O sistema atualiza os dados cadastrais da corrida.
7.1. Se for inclusão, o sistema atualiza o status automaticamente com o valor
"aguardando VR".
Cenário Alternativo:
- Código desconhecido
Se o usuário não possuir o código do cliente, ele poderá pesquisá-lo a partir do
nome do cliente [Include Caso de Uso Consultar Cliente].
- Cliente não cadastrado
Se o cliente não for cadastrado, o usuário poderá efetuar o cadastramento a
partir deste caso de uso. [Include Caso de Uso Manter Cliente]
- Validação do Status
O status "aguardando VR" só pode ser alterado para "aguardando aviso",
"cancelado pelo passageiro" ou "cancelado pela cooperativa por falta de carro"
(este último, no caso específico de corrida imediata).
O status "aguardando aviso" só pode ser alterado para "aviso efetuado" ou
"cancelado pelo passageiro".
O status "aviso efetuado" só pode ser alterado para “tripulado" ou "cancelado
pelo passageiro”.
Os status “tripulado" e "cancelado" não podem ser alterados.
70
APÊNDICES
APÊNDICE A. Questionário aplicado na pesquisa.
Questionário
1)
2)
3)
4)
5)
6)
7)
8)
9)
Qual a sua faixa etária?
a) ( ) 16 a 19 anos
b) ( ) 20 a 25 anos
c) ( ) 26 – 30 anos
d) ( ) 31 – 40 anos
e) ( ) Mais de 40 anos
Qual é o seu nível de escolaridade?
a) ( ) Técnico
b) ( ) Superior
Qual o seu nível de conhecimento com orientação a objetos?
a) ( ) Alto
b) ( ) Médio
c) ( ) Baixo
d) ( ) Nenhum
Como você avalia seu nível de conhecimento na elaboração de diagramas da UML, como:
a) Caso de uso
( ) baixo ( ) médio ( ) intermediário
( )nenhum
b) Classes
( ) baixo ( ) médio ( ) intermediário
( )nenhum
c) Sequência
( ) baixo ( ) médio ( ) intermediário
( )nenhum
d) Atividade
( ) baixo ( ) médio ( ) intermediário
( )nenhum
Quais atividades da análise e projeto orientado a objetos você encontra maiores dificuldades?
(escolha todas as que se aplicam)
a) ( ) Especificação do modelo de casos de uso
b) ( ) Elaboração do diagrama de classes
c) ( ) Elaboração do diagrama de atividades
d) ( ) elaboração do diagrama de sequência
Qual sua motivação para o estudo da linguagem UML?
a) ( ) Pretensão de trabalhar na área de análise de sistemas
b) ( ) Cumprir matéria obrigatória do curso
c) ( ) Me identifico com o assunto
d) ( ) Melhorar o entendimento em linguagem de programação
(Java, C#, .NET)
Quais fatores seriam importantes para melhor aprendizado do diagrama de classes?
a) ( ) atividades práticas durante o estudo da linguagem
b) ( ) maior interação entre as fases do projeto de software
c) ( ) mais atitudes na busca pelo aprendizado
d) ( ) materiais mais intuitivos para o aprendizado, com elaboração de diagramas e
documentação.
Qual das técnicas você considera mais relevante para modelar classes (elaborar diagrama de
classes)?
a) ( ) CRC (Classes, Responsabilidades e Colaborações)
b) ( ) Análise de Caso de Uso
c) ( ) Categoria de objetos
d) ( ) Outros. Indique: _________________
Aponte 3 (três) elementos que você tem maior dificuldade de aplicação ao elaborar um diagrama de
classes.
a) ( ) associação
b) ( ) atributo
c) ( ) classe
d) ( ) classe abstrata
e) ( ) classe associativa
f) ( ) classe de interface
g) ( ) composição / agregação
h) ( ) generalização / especialização
i) ( ) operação
j) ( ) operação abstrata
k) ( ) visibilidade
71
APÊNDICE B. Modelo da declaração de autorização de participação das
sessões CRC
Declaração
São Paulo, 27 de abril de 2010
Eu, «Nome», aluno (a) da FATEC Zona Leste, RA nº. «RA»,
declaro para os devidos fins que participo voluntariamente das sessões da
aplicação do método CRC, nas dependências da faculdade, em apoio ao
colega Wellington Vieira dos Santos, RA nº. 072039-9, aluno do sexto
semestre. Os resultados destas sessões serão analisados por ele e farão
parte do seu Trabalho de Conclusão de Curso. Declaro ainda estar ciente, e
autorizo que meu nome seja incluído neste trabalho, se ele julgar
necessário.
Atenciosamente,
_______________________________________
«Nome» - RA n°. «RA»
72
APÊNDICE C. Resultados tabulados da pesquisa realizada na FATEC e Senac
1)
a)
b)
c)
d)
e)
Qual a sua faixa etária?
16 a 19 anos
20 a 25 anos
26 - 30 anos
31 - 40 anos
Mais de 40 anos
2)
a)
b)
Qual é o seu nível de escolaridade?
Técnico
15
Superior
101
3)
Qual o seu nível de conhecimento com orientação a
objetos?
a)
b)
c)
d)
Alto
Médio
Baixo
Nenhum
4)
Como você avalia seu nível de conhecimento na
elaboração de diagramas da UML, como:
a)
Caso de uso
b)
c)
d)
33
55
16
10
2
28%
47%
14%
9%
2%
13%
87%
1
36
78
1
1%
31%
67%
1%
baixo
médio
intermediário
nenhum
36
62
16
2
31%
53%
14%
2%
baixo
médio
intermediário
nenhum
36
60
18
2
31%
52%
16%
2%
baixo
médio
intermediário
nenhum
68
18
8
22
59%
16%
7%
19%
baixo
médio
intermediário
nenhum
68
21
7
20
59%
18%
6%
17%
Classes
Sequência
Atividade
73
6)
a)
b)
c)
d)
5)
Quais atividades da análise e projeto orientado a objetos você
encontra maiores dificuldades? (escolha todas as que se aplicam)
a)
b)
c)
d)
Especificação do modelo de casos de uso
Elaboração do diagrama de classes
Elaboração do diagrama de atividades
elaboração do diagrama de sequência
47
42
68
76
Qual sua motivação para o estudo da linguagem
UML?
Pretensão de trabalhar na área de análise de sistemas
Cumprir matéria obrigatória do curso
Me identifico com o assunto
Melhorar o entendimento em linguagem de programação (Java,
C#, .NET)
41%
36%
59%
66%
42
26
6
42
36%
22%
5%
36%
7)
a)
b)
c)
d)
Fatores seriam importantes para melhor aprendizado do diagrama de classes
atividades práticas durante o estudo da linguagem
72
maior interação entre as fases do projeto de software
32
mais atitudes na busca pelo aprendizado
51
51
materiais mais intuitivos para o aprendizado
8)
Qual das técnicas você considera mais relevante para modelar classes (elaborar
diagrama de classes)?
a)
b)
c)
d)
CRC
Análise de Caso de Uso
Categoria de objetos
Outros
9)
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
30
75
9
2
Aponte 3 (três) elementos que você tem maior
dificuldade de aplicação ao elaborar um diagrama de
classes.
associação
17 15%
atributo
7 6%
classe
9 8%
classe abstrata
50 43%
classe associativa
23 20%
classe de interface
66 57%
composição / agregação
38 33%
generalização / especialização
28 24%
operação
23 20%
operação abstrata
60 52%
visibilidade
24 21%
62%
28%
44%
44%
26%
65%
8%
2%
74
APÊNDICE D. Cartões gerados nas sessões CRC – sistema estacionamento.