Análise de Sistema de Gerenciamento de Acervo de Jogos

POLI / UFRJ
MBA Engenharia de Software – Turma 2004
Disciplina: Análise e Projeto Orientado a Objetos
Professor: Alessandro Cerqueira
Aluno: Halan Ridolphi Alves

MBA-ENGSOFT Análise e Projeto Orientado a Objetos 1
© 2005 Halan Ridolphi

Sumário
1 Requisitos ................................................................................................................. 3
1.1 Contexto de Negócio ........................................................................................... 3
1.2 Escopo do Software ............................................................................................ 3
1.3 Requisitos de Negócio ......................................................................................... 3
1.4 Requisitos Funcionais .......................................................................................... 3
1.5 Requisitos Não Funcionais ................................................................................... 4
2 Casos de Uso ............................................................................................................ 5
2.1 Conceitos .......................................................................................................... 5
2.2 Autenticar Acesso de Cliente ................................................................................ 7
2.3 Registrar no Canal 100 Loja Virtual ....................................................................... 7
2.4 Gerenciar Jogos ................................................................................................. 8
3 Modelo de Classes.................................................................................................... 11
3.1 Classes de Negócio – Diagrama III ..................................................................... 11
3.2 Classes de Negócio – Diagrama II....................................................................... 12
3.3 Classes de Negócio – Diagrama I ........................................................................ 13
4 Diagramas de Seqüência ........................................................................................... 14
4.1 Autenticar Acesso de Cliente .............................................................................. 14
4.2 Gerenciar Jogos ............................................................................................... 15
5 Diagramas de Transição de Estado ............................................................................. 16
5.1 Estados de objeto DVD ..................................................................................... 16
6 Diagramas de Atividade ............................................................................................ 17
6.1 Cliente selecionando Jogadas visando DVD personalizado ....................................... 17
7 Projeto Arquitetural .................................................................................................. 18
8 Bibliografia ............................................................................................................. 20


1 Requisitos
Este documento tem por objetivo detalhar alternativa básica de solução técnica para
construção do sistema de software proposto visando automação das necessidades de negócio do
cliente Canal 100 Produções. Neste sentido, com enfoque nas funcionalidades que devem ser
providas pelo sistema de software depois de construído, os seguintes modelos de software serão
apresentados: requisitos, casos de uso, modelo de classes, diagramas de seqüência e diagramas
de transição de estado.
Este seção visa descrever todos os requisitos a serem satisfeitos e alcançados pelo
sistema de software a ser desenvolvido.

1.1 Contexto de Negócio
O Canal 100 Produções é uma empresa que detém um vasto acervo com cenas e
narrações de jogos de futebol realizados no Brasil. A empresa deseja digitalizar e organizar este
acervo com vistas a gerar um novo modelo de negócio: a venda de DVDs personalizados com
jogadas.

1.2 Escopo do Software
A construção de um novo sistema de software objetiva o gerenciamento de acervo de
cenas e narrações de jogos de futebol, visando suportar a confecção de DVDs personalizados
com as jogadas e dados sobre os jogos selecionados pelos clientes do Canal 100 Produções.
Neste sentido, as seguintes funcionalidades principais deverão ser reunidas pelo sistema de
software proposto:
• Organizar uma base de dados que contenha todos os dados referentes aos jogos;
• Realizar a separação de arquivos de jogadas digitalizadas para a produção de
DVDs personalizados e sua cobrança.

1.3 Requisitos de Negócio
Para cada jogo em seu acervo, o Canal 100 Produções tem uma série de dados
relacionados ao mesmo, a saber: os times, técnicos, escalação, substituições, local, horário,
motivo do jogo (campeonato, amistoso, etc.), placar de cada tempo, placar final, cartões,
prorrogação, disputa de pênaltis, arbitragem. Além destas informações de súmula, a produtora
tem as estatísticas do jogo (chutes agol, defesas, passes errados, posse de bola) que
costumamos a ver nas transmissões de TV.
A produtora conta também com uma série de jogadas que foram digitalizadas por uma
empresa externa e estão em formato MPEG. Para cada jogada, há o texto da narração onde
quase sempre são citados os envolvidos na jogada.
Com relação aos jogadores, a produtora possui os dados como os nomes de escalação,
nome completo, data de nascimento, e também apelidos comumente utilizados na imprensa
(ex.: Zico -> Galinho de Quintino, Roberto -> Dinamite, Pelé -> Rei).

1.4 Requisitos Funcionais
O sistema de software deverá prover as funcionalidades a seguir:
• Organização de base de dados que contenha todos os dados referentes acervo de
jogos;
• Inclusão dos dados de jogos do acervo supracitado;
• Recuperação de conjunto de jogadas a partir de detalhes passados pelo cliente do
Canal 100 Produções, como: todas os gols marcados pelo Júnior no Campeonato
Brasileiro, todas as defesas realizadas pelo Manga quando atuou por times do Rio,
etc.


• Para cada jogo que teve uma jogada catalogada, devemos gerar um arquivo digital
contendo os dados desse jogo. A partir de um número de jogadas selecionadas, o
sistema de software irá calcular a produção de CD pelo tempo total das jogadas
mais o número de arquivos com dados dos respectivos jogos.
• Realização da separação adequada de arquivos de jogadas digitalizadas para a
produção de DVDs personalizados e sua cobrança.

1.5 Requisitos Não Funcionais
A construção do sistema de software deve atentar para os quesitos de qualidade,
restrições operacionais e tecnologia de desenvolvimento de software, a saber:
• A solução de gerenciamento da base de dados referente ao acervo de jogos deve
ser amigável, de fácil aprendizagem, baseada em tecnologia web e operada
através de softwares navegadores da Internet;
• O módulo de interface do usuário Web será codificado com utilização da linguagem
de programação JSP/Java, utilização de Framework STRUTS, servidor de aplicação
JBOSS e padrões de projeto J2EE;
• A conexão entre usuário e sistema deve ser segura orientada pela combinação dos
protocolos HTTP e SSL;
• A base de informações de jogos será armazenada de forma centralizada, em um
sistema gerenciador de banco de dados Oracle;
• O desempenho de execução deverá ser considerado nas operações de publicação
de jogadas;
• Precisão no cálculo de montagem e personalização de DVDs.


2 Casos de Uso
2.1 Conceitos
2.1.1 Atores
Um ator é uma entidade externa que desempenha um papel na interação com o sistema
de software. Um ator pode ser um sistema externo que necessita de alguma informação do
sistema de software sendo modelado.

2.1.2 Casos de Uso
Um caso de uso descreve um conjunto particular de funcionalidades do sistema de
software, modelando a interação que uma entidade externa, denominada ator (usuário,
dispositivo, outro sistema), realiza com o sistema. Um caso de uso é baseado num cenário
descritivo de como a entidade externa interage com o sistema de software, identificando eventos
que podem ocorrer e descrevendo a resposta do sistema para estes eventos. Um caso de uso é
uma seqüência de eventos completa, descrita a partir de uma perspectiva ou uma situação de
uso particular do sistema de software. Casos de uso fornecem uma visão do sistema de software
que está focada principalmente na funcionalidade.
Este artefato formará uma base de concordância entre o cliente e desenvolvedores sobre
o que o sistema de software deve fazer. Casos de Uso também possibilitam a validação se o
sistema de software está sendo modelado em conformidade com regras de funcionamento
esperadas pelo cliente.
Sempre que possível, utilizamos o Modelo de Casos de Uso como ferramenta de apoio à
garantia de qualidade:
1. Inspeção de requisitos (identificar defeitos na definição):
a. Estão corretos, consistentes, sem ambigüidades, completos;
2. Validação de requisitos (conceber o software correto):
a. Estão refletindo a realidade, sem omissão, sem informação estranha;


ud Diagrama de Casos de Uso
Domínio de Casos de Uso do Canal 100 Produções

Autenticar Acesso
de Cliente

Sistema de Controle
de Acesso

«extend»

Registrar no Canal
100 Loj a Virtual

Cliente

Compor DVD
Escolher Jogada
Personalizado «include»

Sistema de Banco de
Dados

Gerenciar
Jogadores

Gerenciar Times
de Futebol

Gerenciar Jogos

Funcionário

Catalogar Jogada

Figura 1: Alguns Casos de Uso da Aplicação Canal 100 Produções
Recomenda-se a utilização de pacotes de casos de uso para possibilitar melhor
compreensão e controle dos domínios (ou grupos) de funcionalidades requeridos pelo sistema de
software.

2.1.3 Protótipo da Interface do Usuário
Descrição da forma de apresentação do sistema de software. Como é realizada a
interação com o usuário e o que será utilizado para construí-la.
Os protótipos da interface do usuário comumente são abstraídos a partir das
funcionalidades (casos de uso) que os participantes (atores) obtêm ao interagirem com o sistema
de software. Os cenários descritos nos Casos de Uso são os alicerces para elaboração desses
protótipos. Um dado protótipo da interface do usuário pode compreender a realização de um
conjunto de Casos de Uso. Os protótipos também constituem uma ferramenta eficaz para captura
de requisitos do software.


2.2 Autenticar Acesso de Cliente
2.2.1 Descrição
A aplicação de loja on-line do Canal 100 Produções armazena informações básicas dos
consumidores de seus produtos e serviços. Tais clientes necessitam autenticar-se (logon) junto
ao sistema para obterem acesso aos seus recursos.

2.2.2 Atores

2.2.2.1 Sistema de Banco de Dados
Sistema externo encarregado de manter persistente todas as informações acerca de
jogos, times de futebol, estatísticas de jogos, clientes, vendas de DVD, jogadas, jogadores e
demais informações no domínio da aplicação do Canal 100 Produções.

2.2.2.2 Cliente
Representa um consumidor dos produtos e serviços da loja virtual do Canal 100.

2.2.2.3 Sistema de Controle de Acesso
Sistema externo encarregado de autenticar e autorizar o acesso aos recursos no domínio
da rede de computadores na loja virtual do Canal 100 Produções, ou seja, representa a
autoridade em segurança da informação que controle os privilégios dos perfis de usuários da
aplicação.

2.2.3 Fluxo de Eventos
Autenticação (logon) {Fluxo Básico}
1. O caso de uso começa quando Cliente acessa a página de Logon
2. Cliente digita nome da conta e senha
3. Sistema valida informações digitadas
4. Caso os dados sejam validados então o Cliente utilizará os recursos do Sistema
5. O caso de uso termina
Falha na Autenticação (access denied) {Fluxo Alternativo}
1. Altera o passo 4 do fluxo “Autenticação”
2. Sistema invalida os dados digitados pelo Cliente
3. Prossiga para o passo 2 do fluxo “Autenticação”
Registrar Cliente {Fluxo Alternativo}
1. Altera o passo 4 do fluxo “Autenticação”
2. Prossiga para o caso de uso “Registrar no Canal 100 Loja Virtual”
3. Prossiga para o passo 1 do fluxo “Autenticação”

2.3 Registrar no Canal 100 Loja Virtual
2.3.1 Descrição
Um cliente que não é registrado necessitará digitar seus detalhes e obter uma conta na
loja virtual do Canal 100. Isto normalmente incluirá detalhes tais como nome, email, endereço,
telefone, preferências e etc. Este caso de uso estende o caso de uso “Autenticar Acesso de
Cliente” nas situações onde o usuário não tem uma conta na loja virtual. Uma vez registrado o
cliente pode completar o caso de uso “Autenticar Acesso de Cliente”. Um cliente usará este caso
de uso para registrar-se a si próprio na loja virtual se ele ainda não for membro registrado.


2.3.2 Atores


2.3.2.2 Cliente
Representa um consumidor dos produtos e serviços da loja virtual do Canal 100.

2.3.2.3 Sistema de Controle de Acesso
Sistema externo encarregado de autenticar e autorizar o acesso aos recursos no domínio
da rede de computadores na loja virtual do Canal 100 Produções, ou seja, representa a
autoridade em segurança da informação prestando serviços de controle de acesso.

2.3.3 Restrições

2.3.3.1 Pós-Condicões
Cliente registrado.

2.3.3.2 Pré-Condições
Cliente ainda não registrado. O cliente não deve estar registrado no Sistema.

Efetuar registro de cliente {Fluxo Básico}
1. Cliente digita seu nome de conta preferido, detalhes pessoais e senha.
2. Sistema valida se nome de conta não está em uso
3. Caso os dados sejam aceitos então o Cliente é registrado na loja virtual
4. Caso os dados sejam recusados o Cliente é compelido a tentar novamente
fornecendo outro nome de conta

2.4 Gerenciar Jogos
2.4.1 Descrição
Este caso de uso descreve todos os aspectos da forma como o Funcionário gerencia as
informações de jogos de futebol mantidas em repositório base de dados do Canal 100 Produções.
O Funcionário estará apto a criar, atualizar, apagar e consultar os dados dos jogos desde que ele
esteja operando com conta que tenha permissão de acesso.

2.4.2 Atores


2.4.2.2 Funcionário
Representa um empregado da loja virtual do Canal 100.

2.4.3 Restrições

2.4.3.1 Pós-Condicões
Cadastro de jogos de futebol atualizado.


2.4.3.2 Pré-Condições
Funcionário utiliza nome de conta com privilégios para acessar os recursos administrativos
e de manutenção da loja virtual do Canal 100 Produções.

Cadastrar Novo Jogo {Fluxo Básico}
1. O caso de uso inicia quando o Funcionário seleciona a opção “Cadastrar” na tela de
“Gerenciamento de Jogos”.
2. O Sistema apresenta na tela um formulário vazio com os campos de informação
associados ao jogo para o Funcionário completá-los. A seguir, alguns destes
campos são mencionados:
Nomes dos Times (obrigatório)
Estádio (obrigatório)
Arbitragem (obrigatório)
Motivo do Jogo {Campeonato, Amistoso}
Escalações
Local
Data e Horário
Placar do primeiro tempo
Placar do segundo tempo
Placar final
Número de Cartões Amarelo
Total de Substituições
Nota: Os campos obrigatórios deverão ser indicados apropriadamente para o
usuário da aplicação.
3. O Funcionário completa o preenchimento do formulário e seleciona a opção de
salvar os dados.
4. O Sistema checa a consistência das entradas e grava os detalhes do novo jogo
5. O Sistema informa ao Funcionário que as informações para novo jogo foram
armazenadas
6. O Sistema atualiza a tela “Gerenciamento de Jogos” para mostrar os detalhes do
novo jogo recém cadastrado
Apagar Jogo {Fluxo Alternativo}
1. O Funcionário preenche em formulário na tela “Gerenciamento de Jogos” alguns
dados de jogos
2. O Funcionário solicita que o Sistema recupere todos os jogos que combinem com
os dados digitados escolhendo a opção “Consultar” na tela “Gerenciamento de
Jogos”
3. O Sistema retorna uma lista de jogos encontrados na pesquisa
4. O Funcionário seleciona uma ou mais jogos da lista e então seleciona a opção
“Apagar” na tela “Gerenciamento de Jogos”
5. O Sistema indaga ao usuário se ele quer mesmo remover os jogos selecionados
6. Caso sim o Sistema remove os jogos escolhidos da base de dados
Atualizar Jogo {Fluxo Alternativo}
dados de jogos
os dados digitados escolhendo a opção “Consultar”
4. O Funcionário escolhe um jogo e então seleciona a opção “Atualizar” na tela
“Gerenciamento de Jogos”
5. O Sistema apresenta o formulário de edição dos dados jogo escolhido
6. O Funcionário altera os dados necessários do jogo no formulário de edição


7. O Funcionário completa a edição dos dados e seleciona a opção de salvar as
modificações.
8. O Sistema checa a consistência das entradas e grava os detalhes do novo jogo
9. O Sistema informa ao Funcionário que as modificações no jogo escolhido foram
gravadas
10. O Sistema atualiza a tela “Gerenciamento de Jogos” para mostrar os detalhes do
jogo cujos dados foram recém modificados
Consultar Jogo {Fluxo Alternativo}.
dados de jogos
os dados digitados escolhendo a opção “Consultar”
4. O Funcionário escolhe um jogo e então seleciona a opção “Visualizar” na tela
“Gerenciamento de Jogos”
5. O Sistema apresenta o formulário de visualização dos detalhes do jogo escolhido
Nota: O usuário está apto a selecionar outros jogos e visualizar estes jogos ao mesmo
tempo.


3 Modelo de Classes
Descreve aspectos estruturais, ou seja, as classes de objetos, interfaces e seus
relacionamentos, os quais formam os elementos de construção do sistema de software.
Classes de negócio são representações de objetos do mundo real tais como, lugares,
coisas, conceitos e eventos que são pertinentes ao nosso domínio do problema. Cada classe
representa uma coleção de objetos similares.
Um objeto é uma pessoa, lugar, coisa, conceito, evento, tela ou relatório que é relevante
para o sistema de software em construção. Objetos conhecem coisas (isto é, eles têm dados) e
fazem coisas (isto é, eles têm funcionalidades).

3.1 Classes de Negócio – Diagrama III
cd Diagrama de Classe III
+Fundamento mantida por +Time
TimeFutebol
PosseDeBola 1 1
- nome: char
- tempoPosse1Tempo: int - apelido: int
- tempoPosse2Tempo: int - totalSocios: int
- tamanhoTorcida: int
Defesa - anoFundacao: int
+Estatística 1 - patrocinadores: char
- minutosMomentoEvento: int
- intervaloPartida: int - temEstadioProprio: boolean
- foiRealizadaNaProrrogacao: boolean
+Participante 2 +Clube 1
0..*
+Fundamento *

pertence a
acontece em

registrado em executado por
Jogada realizado em

- nomeArquivo: char 0..*
- tempoCena: int
- preco: float +Cena da Partida
+Atleta *
- ehFilmeColorido: boolean
0..* Pessoa
Jogador
cenas registrados em
+Partida 1+Partida 1 +Partida 0..* - apelido: char
- posicaoEmCampo: char
Jogo - totalParticipacoesCampeonatoBrasileiro: int
+Partida
- motivo: char 1 +Atleta 1
1 - dataRealizacao: char
- horaInicioPartida: char
- tipoDecisaoPartida: char
ChuteAGol +Estatística +Partida - tempoTotalPartida: int +Partida
acontece em
- placarFinal: char
- minutosMomentoEvento: int 0..* 1 - 1
placarDisputaPenaltis: char
executado por
+Partida 1 +Partida 1 tomado por

acontece em acontece em
acontece em

+Estatística +Fundamento *
+Troca Jogador 0..*
* PasseErrado
Substituicao +Estatística 0..* 0..*
- minutosMomentoEvento: int Cartao

- tipo: char

Figura 2a: Classes de Negócio


3.2 Classes de Negócio – Diagrama II

cd Diagrama de Classe II

+Gol Penalti

0..* - foiConvertido: boolean
0..*

ocorrido em
registrado em
Prorrogacao

- placar1Tempo: char
+Partida 0..* - placar2Tempo: char
0..*
complementado por - tempoTotal: int
Jogo - placarFinal: char
0..1 1 Jogada
- motivo: char
+Partida cenas registrados em +Cena da Partida - nomeArquivo: char
- dataRealizacao: char
- tempoCena: int
- horaInicioPartida: char 1 0..* - preco: float
marcado em registrado em - ehFilmeColorido: boolean
- tempoTotalPartida: int
- placarFinal: char 1 0..*
- placarDisputaPenaltis: char

+Partida 1 +Partida 0..*
0..* 0..*

Gol
configurado com
- intervaloPartida: int 1
- foiMarcadoNaProrrogacao: boolean
+Jogadores 1
1 1

Escalacao
executado por
- listaTitulares: char
+Jogadores
- listaReservas: char
marcador
1..* sofredor
+Grupo 0..* marcado por

escalado em escalado com

+Participante 2 0..* 0..*

+Atleta 1..* 0..*
TimeFutebol
+Time
Pessoa
- nome: char
Jogador 1
+Atleta pertence a +Clube - apelido: int
- totalSocios: int
- apelido: char
* 1 - tamanhoTorcida: int
- anoFundacao: int
- totalParticipacoesCampeonatoBrasileiro: int
- patrocinadores: char
- temEstadioProprio: boolean

Figura 2b: Classes de Negócio


3.3 Classes de Negócio – Diagrama I
cd Diagrama de Classe I

Pessoa
Endereco sede fica em
- nome: char
- sexo: char - rua: char 1
- e-mail: char mora - bairro: char
- telefone: char - cidade: char 1
0..1 1
- dataNascimento: char - estado: char
- naturalidade: char - pais: char
- nacionalidade: char - cep: char
localizado em
- escolaridade: int

0..1

Estadio

- capacidadePublico: int
Jogador
Cliente - proprietario: char
- apelido: char
- numeroCartaoDeCredito: char
- timeTorcedor: char
- totalParticipacoesCampeonatoBrasileiro: int 0..1
+Devedor 1 +Consumidor 1 +Atleta *
TimeFutebol
consome pertence a +Clube
- nome: char
1 - apelido: int
+Mercadoria 0..* - totalSocios: int
- tamanhoTorcida: int
Tecnico
- anoFundacao: int
DVD
- apelido: char - patrocinadores: char
- numeroID: int - estiloComando: char - temEstadioProprio: boolean
- statusProduto: short - totalCompeticoesCampeao: int
- tempoFilme: int +Participante 2
- precoVenda: float
- quantidadeJogadas: int
+Produto Arbitro
- dataProducao: char
- dataEntrega: char 1 - federacaoFutebol: char
- totalAnosExperiencia: int
+ selecionarJogada() : void - jaApitouCopadoMundo: boolean
+ descartarJogada() : void
+Juiz 1 +Auxiliar 1..
+ notificarCliente() : void
+ verificarPagamento() : void
+ notificarLoja() : void executado por

+Produto
auxilia

compõe
compra

+Peça_de_Produto 1..*

Jogada
+Partida 0..*
+Partida 0..*
- nomeArquivo: char +Cena da Partida cenas registrados em +Partida
- tempoCena: int Jogo
0..* 1
- preco: float
- ehFilmeColorido: boolean +Partida -
apita motivo: char
- dataRealizacao: char
0..* - horaInicioPartida: char
- tempoTotalPartida: int
+Pagamento 0..1 - placarFinal: char
- placarDisputaPenaltis: char
CobrancaDVD

compra +Dívida - tipoPagamento: char
- precoProduto: float
0..* - dataCobranca: char
- horaCobranca: char
- status: int

Figura 2c: Classes de Negócio


4 Diagramas de Seqüência
Descrevem aspectos do comportamento dinâmico do sistema de software a ser
desenvolvido, especificamente, demonstram a cooperação dos objetos nos cenários propostos
pelos casos de uso.

4.1 Autenticar Acesso de Cliente

sd Autenticar Acesso de Cliente

Tela Logon GerenciadorSegurança Clientes
Consumidor
:Cliente
Logon

ValidarCliente(Consumidor)

RecuperaDetalhesCliente(Consumidor)

{DetalhesCliente}

Validar

Resultado : {Ok / Access Denied}

Um Cliente deverá autenticar-se (logon) junto ao Sistema antes de poderem utilizar os serviços e produtos da Loja Virtual do Canal
100 Produções, notamente, realizar compras de DVDs personalidades.

Figura 3a: Objetos e Interações para Autenticar Acesso de Cliente
Ressalta-se que o diagrama acima expressa o padrão MVC (Model-View-Controller),
comumente empregada na construção de grande variedade de aplicações que requerem interface
do usuário, lógica de aplicação ou negócio e persistência de dados.
A seguir, comentamos legenda para os alguns dos possíveis elementos no diagrama de
seqüência e seus ícones estereotipados.
Elemento Ator: Uma instancia de um Ator em tempo de execução.
cd Diagrama de

Actor1

Objeto: Um elemento padrão, instância de uma classe qualquer, não especializado.
cd Diagrama de Colabora

Obj ect1

Elemento de Fronteira: Representa uma interface do usuário ou dispositivo de entrada
e saída.


cd Diagrama de C

Screen1

Elemento de Entidade: Um elemento persistente, tipicamente implementado como
objeto ou tabela de banco de dados.
sd Modelo de Inte

Entity1

Elemento Controlador: O componente ativo que control qual trabalho será feito,
quando e como.
sd Modelo de Inte

Controller1

4.2 Gerenciar Jogos

sd Gerenciar Jogos (fluxo cadastrar novo jogo)

Tela Formulário ControladorJogos GerenciadorPersistencia Jogos
Consumidor Gerenciamento de Edição
:Cliente de Jogos de Jogos
Cadastrar ()

MostrarFormularioVazio ()

Salvar

SalvarJogo(Jogo)

ChecarConsistencia(Jogo)

TornarPersistente(Jogo)
InserirJogo(Jogo)

{DetalhesJogo}

{Detalhes Jogo}

{Detalhes Jodo Gravado}

ApresentarMensagemJogoGravado

AtualizarDadosNaTela(Jogo)

No formulário vazio de edição de jogos campos de informação associados ao jogo são apresentados ao Funcionário para que ele possa completá-los. A seguir, alguns
destes campos são mencionados:
. Nomes dos Times (obrigatório) . Estádio (obrigatório)
. Arbitragem (obrigatório) . Motivo do Jogo {Campeonato, Amistoso}
. Escalações . Local
. Data e Horário . Placar final
. Número de Cartões Amarelo . Total de Substituições

Figura 3b: Objetos e Interações para Cadastrar Novo Jogo


5 Diagramas de Transição de Estado
desenvolvido, especificamente, demonstram as mudanças de estados ou ciclos de vida para
objetos do sistema de software em operação.

5.1 Estados de objeto DVD

sm DVD

Início

Consumidor consulta jogada

Processando

Personalizando [Todas jogadas selecionadas] Cobrando

+ Do Action / Selecionar Jogada + Do Action / Verificar Pagamento

[Restam jogadas a selecionar] /Selecionar próxima jogada

[Pagamento Ok]
[Algunas jogadas selecionadas estão sem arquivo MPEG]

Jogada catalogada [Arquivo de cena disponível] Fabricando

+ On Exit / Verificar Embalagem
+ Do Action / Gravar Jogadas

DVD pronto para entrega ao consumidor
Aguardando [Pagamento não Ok]

Expedindo

+ Do Action / Postar no Correio
Jogada catalogada [Arquivo MPEG não disponível]

Consumidor cancelando a compra Serviço de correio entrega mercadoria a consumidor

Cancelado Entregue Rej eitado

+ On Entry / Notificar Cliente via E-mail + On Entry / Notificar Loja Virtual

Arquivado

Figura 4: Estados de objeto DVD


6 Diagramas de Atividade
desenvolvido, mais especificamente, modelam mapa de navegação pela interface do usuário,
padrões de usabilidade e fluxos de processos do sistema de software.

6.1 Cliente selecionando Jogadas visando DVD personalizado

ad Mapa de Navegação
Ciclo de interação com Cliente para seleção de Jogadas visando produção de DVD personalizado

Cliente

Início

Apresentar Tela
[não] de Autenticação
(Logon)

botão entrar

Autenticar
Cliente

[sim]

Apresentar Apresentar
Jogadas Jogadas
Combinadas Catalogos por
com Critérios de Jogos
Busca
Apresentar Tela
[sim] de Consulta de [sim]
Jogadas
Apresentar Apresentar
Mensagem [não] [não] Mensagem
"Nenhuma "Nenhuma
Jogada Jogada
Encontrada." Catalogada."

Recuperar Recuperar
Jogadas v ia botão recuperar botão consultar Jogadas
Critérios de Catalogadas por
Busca Jogos

botão logoff botão cancelar

Efetuar Logoff Limpar Tela de
Consulta de
Jogadas

Fim

Figura 5: Mapa de Navegação


7 Projeto Arquitetural
A arquitetura de software visa detalhar estrutura dos componentes do sistema de software,
seus inter-relacionamentos e topologia, diretrizes de projeto (modularização, coesão,
acoplamento) e evolução ao longo do tempo. Visa também especificar o projeto de subsistemas,
mostrando dependências e interações.
A aplicação Canal 100 será inteiramente codificada em linguagem Java framework J2EE,
utilizando componentes do framework Struts para interface do usuário, mecanismo do Active
Directory para autenticação e controle de acesso, ORACLE como ferramenta SGDB para
armazenamento, recuperação e indexação de informações e rodando sob servidor de aplicação
JBOSS. A aplicação será organizada em 4 camadas (coleção de classes ou componentes) de
software, a saber: Persistência de Dados, Lógica de Negócio, Interface do Usuário e Infra-
Estrutura de Serviços Comuns.

cd Arquitetura

Consumidor :Cliente Administrador :
Funcionário

Classes de Interface do Usuário

Classes de Interface do Usuário

Classes de Lógica de Negócio Classes de Infra-Estrutura Serviços Comuns

Classes de
Lógica de Negócio Classes de
Infra-Estrutura
Classes de Persistência de Dados
Classes de Serviços Comuns
Persistência de Dados

Mecanismo de Microsoft Activ e
Persistência Oracle Diretory System :
9i :Sistema de Sistema de
Banco de Dados Controle de Acesso

Figura 6: Arquitetura de Camadas
As classes de interface do usuário contêm o código que provê a capacidade de usuários
interagem com aplicação. Classes de interface do usuário tipicamente implementam uma
interface do usuário gráfica para aplicação, embora outros estilos de interface, tais como
comando de voz, HTML, multimídia, são também implementados via esta categoria de classes.
Por exemplo, uma interface do usuário gráfica pode ser implementada como uma coleção de
classes de menus, telas de edição, painéis, caixas de seleção, caixas de listagem, relatórios.


As classes de negócio implementam conceitos pertinentes ao domínio da aplicação, tais
como, “Jogo” ou “DVD”, focando nos aspectos de dados dos objetos de negócio e mais
comportamentos específicos para conceitos de negócio individuais. Cabe a estas classes também
implementar a lógica de negócio que envolve a colaboração de vários objetos, os quais são
instâncias de distintas classes de negócio.
As classes de persistência de dados encapsulam a capacidade para armazenar, recuperar,
atualizar e remover objetos permanentemente sem revelar detalhes secretos da tecnologia de
armazenamento. A estratégia de uso de um framework de persistência habilita-nos utilizar
distintas tecnologias de armazenamento sem afetar ou necessidade de alterar nossa aplicação.
As classes de infra-estrutura de serviços comuns provêem os serviços específicos do
sistema operacional ou encapsulam funcionalidades fornecidas por ferramentas e aplicações de
terceiros. Estas classes isolam nossa aplicação do sistema operacional, tornando a aplicação
portável entre ambientes via o empacotamento de serviços específicos do SO. Estas classes
tipicamente fornecem serviços para geração de trilhas de auditoria (log, registro de ações
críticas), gerenciamento de arquivos, comunicação inter-processos, multitarefa, gerenciamento
de memória, manipulação de documentos XML e dentro outros recursos não orientados a
objetos.
Colaboração entre classes é permitida dentro de uma camada. Por exemplo, classes IU
podem enviar mensagens a outras classes IU e classes de negócio podem enviar mensagens a
outras classes de negócio. Colaboração pode também ocorrer entre classes em camadas
conectadas entre si. Como pode ser observado pela figura Arquitetura de Camadas, classes IU
podem enviar mensagens para classes de lógica de negócio, mas não podem fazê-lo para classes
de persistência de dados. Classes de negócio podem enviar mensagens para classes de
persistência de dados, mas não podem fazê-lo para classes de interface do usuário. Pela
restrição do fluxo de mensagens em uma somente uma direção, dramaticamente incrementa-se
a portabilidade de nossa aplicação pela redução do acoplamento entre classes. Por exemplo,
classes de negócio independem dos serviços providos pelas classes IU, implicando que podemos
modificar a interface do usuário da aplicação sem afetar a lógica de negócio fundamental.


8 Bibliografia
Fontes de artigos e livros consultados acerca de Projeto de Software Orientado a Objetos e
assuntos correlatos:
• The Object Primer: Application Developer’s Guide to Object Orientation, Second Edition –
Scott W. Ambler, SIGS Books & Multimedia 2000.
• Enterprise Architect UML modeling tool
• Cetus Links on Objects & Components
• Escrevendo Casos de Uso Eficazes – Alistair Cockburn, Editora Bookman 2003.
• Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos – Erich
Gamma… [et al.], Editora Bookman 2000.
• Engenharia de Software: Teoria e Prática – Shari Lawrence Pfleeger, Prentice Hall 2003.


ANÁLISE E PROJETO ORIENTADOS A OBJETOS

EXERCÍCIO DE MODELAGEM – CANAL 100 PRODUÇÕES

PROBLEMA:

O Canal 100 Produções é uma empresa que detém um vasto acervo com
cenas e narrações de jogos de futebol realizados no Brasil. A empresa
deseja digitalizar e organizar este acervo com vistas a gerar um novo
modelo de negócio: a venda de DVDs personalizados com jogadas. Para
isto, será necessário construir um Sistema de Informação que terá dois
objetivos principais:
• Organizar uma base de dados que contenha todos os dados
referentes aos jogos;
• Realizar a separação de arquivos de jogadas digitalizadas para a
produção de DVDs personalizados e sua cobrança.
Para cada jogo em seu acervo, o Canal 100 Produções tem uma série de
dados relacionados, a saber: os times, técnicos, escalação, substituições,
local, horário, motivo do jogo (campeonato, amistoso, etc.), placar de cada
tempo, placar final, cartões, prorrogação, disputa de pênaltis, arbitragem.
Além destas informações de súmula, a produtora tem as estatísticas do jogo
(chutes a gol, defesas, passes errados, posse de bola) que costumamos a
ver nas transmissões de TV.
A produtora conta também com uma série de jogadas que foram
digitalizadas por uma empresa externa e estão em formato MPEG. Para
cada jogada, há o texto da narração onde quase sempre são citados os
envolvidos na jogada.
Com relação aos jogadores, a produtora possui os dados como os nomes de
escalação, nome completo, data de nascimento, e também apelidos
comumente utilizados na imprensa (ex.: Zico -> Galinho de Quintino,
Roberto -> Dinamite, Pelé -> Rei).
O sistema deverá permitir a inclusão dos dados acima citados e deverá
permitir que possamos recuperar um conjunto de jogadas a partir de
detalhes passados pelo cliente, como: todos os gols marcados pelo Júnior
no Campeonato Brasileiro, todas as defesas realizadas pelo goleiro Manga
quando atuou por times do Rio, etc. Para cada jogo que teve uma jogada
catalogada, devemos gerar um arquivo digital contendo os dados desse
jogo. A partir de um número de jogadas selecionadas, o sistema irá calcular
a produção de CD pelo tempo total das jogadas mais o número de arquivos
com dados dos respectivos jogos.

MODELAGEM DE SOFTWARE:

Neste exercício, espera-se o desenvolvimento dos seguintes artefatos para
modelagem do sistema de software proposto:

1. Modelo de Classes do Domínio
a. Estimativa de +/- 20 classes
2. Modelo de Casos de Uso
a. Especificação detalhada de 2 casos de uso
3. Diagrama de Estados
a. Especificação detalhada de 2 diagramas

ENGENHARIA DE SOFTWARE 1/2

ANÁLISE E PROJETO ORIENTADOS A OBJETOS

4. Diagrama de Seqüência
a. Especificação detalhada de 1 diagrama

DICAS:

1. Classes de domínio possíveis:
Jogada, Time, Jogo, Gol, Jogador, Escalação, DVD, Cliente, Técnico.
2. Contatos para dúvidas:
alessandro@tdi.com.br, alessandro.cerqueira@uniriotec.br

ENGENHARIA DE SOFTWARE 2/2

Análise de Sistema de Gerenciamento de Acervo de Jogos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Análise de Sistema de Gerenciamento de Acervo de Jogos

Semelhante a Análise de Sistema de Gerenciamento de Acervo de Jogos (20)

Mais de Halan Ridolphi

Mais de Halan Ridolphi (13)

Análise de Sistema de Gerenciamento de Acervo de Jogos