Estudo de caso_com_modelagem_de_software_halan

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

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


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 UsoDomínio de Casos de Uso do Canal 100 Produções

Cliente

Autenticar Acesso de Cliente

Registrar no Canal 100 Loja Virtual

Gerenciar Jogos

Gerenciar Jogadores

Catalogar Jogada

Gerenciar Times de Futebol

Sistema de Controle de Acesso

Sistema de Banco de Dados

Funcionário

Escolher JogadaCompor DVD Personalizado «include»

«extend»

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}


2. O Funcionário solicita que o Sistema recupere todos os jogos que combinem com os dados digitados escolhendo a opção “Consultar”

3. O Sistema retorna uma lista de jogos encontrados na pesquisa 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}.


2. O Funcionário solicita que o Sistema recupere todos os jogos que combinem com os dados digitados escolhendo a opção “Consultar”

3. O Sistema retorna uma lista de jogos encontrados na pesquisa 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

Cartao

- tipo: char- minutosMomentoEvento: int

ChuteAGol

- minutosMomentoEvento: int

Defesa

- minutosMomentoEvento: int- intervaloPartida: int- foiRealizadaNaProrrogacao: boolean

PasseErrado

- minutosMomentoEvento: intSubstituicao

- minutosMomentoEvento: int

PosseDeBola

- tempoPosse1Tempo: int- tempoPosse2Tempo: int

Jogo

- motivo: char- dataRealizacao: char- horaInicioPartida: char- tipoDecisaoPartida: char- tempoTotalPartida: int- placarFinal: char- placarDisputaPenaltis: char

PessoaJogador

- apelido: char- posicaoEmCampo: char- totalParticipacoesCampeonatoBrasileiro: int

TimeFutebol

- nome: char- apelido: int- totalSocios: int- tamanhoTorcida: int- anoFundacao: int- patrocinadores: char- temEstadioProprio: boolean

Jogada

- nomeArquivo: char- tempoCena: int- preco: float- ehFilmeColorido: boolean

0..*

registrado em

0..*

1

+Partida

cenas registrados em

0..*

+Cena da Partida

*+Fundamento

realizado em

1+Partida

0..*

+Estatística acontece em

1

+Partida

1+Partida

acontece em

0..*+Troca Jogador

1+Partida

acontece em

0..*+Estatística 0..*

tomado por

1

1

+Fundamento +Timemantida por

1

1+Estatística

acontece em

1+Partida

*

+Estatística

acontece em

1

+Partida

*+Fundamento

executado por

1+Atleta

*+Atleta

pertence a

1+Clube

0..*+Partida

executado por

2+Participante

Figura 2a: Classes de Negócio


3.2 Classes de Negócio – Diagrama II

cd Diagrama de Classe II

Jogo

Penalti+Gol

- foiConvertido: boolean


PessoaJogador


Jogada


TimeFutebol


Gol

- minutosMomentoEvento: int- intervaloPartida: int- foiMarcadoNaProrrogacao: boolean

Prorrogacao

- placar1Tempo: char- placar2Tempo: char- tempoTotal: int- placarFinal: char

Escalacao

- l istaTitulares: char- l istaReservas: char

1..*

+Jogadores

escalado com

1

+Time

1+Partida

configurado com

1+Jogadores

1

+Partida cenas registrados em

0..*

+Cena da Partida

0..*0..*

ocorrido emregistrado em

0..*+Partida0..*

complementado por

*

+Atleta pertence a

1

+Clube

0..*+Partida

executado por

2+Participante

0..*+Grupo

escalado em

1..*+Atleta

10..1

registrado emmarcado em

0..*1

0..* 0..*

1

sofredor

0..*

1

1

marcador

marcado por

0..*

0..*

Figura 2b: Classes de Negócio


3.3 Classes de Negócio – Diagrama I

cd Diagrama de Classe I

Cliente

PessoaEndereco

- numeroCartaoDeCredito: char- timeTorcedor: char

DVD

- numeroID: int- statusProduto: short- tempoFilme: int- precoVenda: float- quantidadeJogadas: int- dataProducao: char- dataEntrega: char

+ selecionarJogada() : void+ descartarJogada() : void+ notificarCliente() : void+ verificarPagamento() : void+ notificarLoja() : void

Jogada


Jogo


- rua: char- bairro: char- cidade: char- estado: char- pais: char- cep: char

Tecnico

- apelido: char- esti loComando: char- totalCompeticoesCampeao: int

Arbitro

- federacaoFutebol: char- totalAnosExperiencia: int- jaApitouCopadoMundo: boolean

- nome: char- sexo: char- e-mail: char- telefone: char- dataNascimento: char- naturalidade: char- nacionalidade: char- escolaridade: int

Estadio

- capacidadePublico: int- proprietario: char

TimeFutebol


CobrancaDVD

- tipoPagamento: char- precoProduto: float- dataCobranca: char- horaCobranca: char- status: int

Jogador


1+Juiz

apita

0..*

+Partida

1+Consumidor

consome

0..*+Mercadoria

0..1

mora

1

sede fica em

1

1

localizado em

0..1

0..1

1

+Partidacenas registrados em

0..*

+Cena da Partida

1..+Auxiliar

auxilia

0..*+Partida

1+Devedor

compra

0..*

+Dívida

1

+Produto

compra

0..1+Pagamento

0..*+Partida

executado por

2+Participante

*+Atleta

pertence a

1

+Clube

+Produto

compõe

1..*+Peça_de_Produto

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

Consumidor :Cliente

Tela Logon GerenciadorSegurança Clientes

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

Logon

ValidarCliente(Consumidor)

RecuperaDetalhesCliente(Consumidor)

{DetalhesCliente}

Validar

Resultado : {Ok / Access Denied}

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

Object1

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)

Consumidor :Cliente

Tela Gerenciamento

de Jogos

Formulário de Edição de Jogos

ControladorJogos GerenciadorPersistencia Jogos

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

Cadastrar ()

MostrarFormularioVazio ()

Salvar

SalvarJogo(Jogo)

ChecarConsistencia(Jogo)

TornarPersistente(Jogo)InserirJogo(Jogo)

{DetalhesJogo}

{Detalhes Jogo}

{Detalhes Jodo Gravado}

ApresentarMensagemJogoGravado

AtualizarDadosNaTela(Jogo)

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


5 Diagramas de Transição de Estado Descrevem aspectos do comportamento dinâmico do sistema de software a ser

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

Processando

Personalizando

+ Do Action / Selecionar Jogada

Fabricando

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

Aguardando

Cobrando

+ Do Action / Verificar Pagamento

Arquivado

Cancelado Entregue

+ On Entry / Notificar Cliente via E-mail

Rejeitado

+ On Entry / Notificar Loja Virtual

Expedindo

+ Do Action / Postar no Correio

Consumidor cancelando a compra

Jogada catalogada [Arquivo de cena disponível]

Jogada catalogada [Arquivo MPEG não disponível]

[Algunas jogadas selecionadas estão sem arquivo MPEG]

[Pagamento Ok]

[Pagamento não Ok]

[Todas jogadas selecionadas]

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

Consumidor consulta jogada

DVD pronto para entrega ao consumidor

Serviço de correio entrega mercadoria a consumidor

Figura 4: Estados de objeto DVD


6 Diagramas de Atividade Descrevem aspectos do comportamento dinâmico do sistema de software a ser

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çãoCiclo de interação com Cliente para seleção de Jogadas visando produção de DVD personalizado

Apresentar Telade Autenticação

(Logon)

Início

Apresentar Telade Consulta de

Jogadas

ApresentarJogadas

Catalogos porJogos

ApresentarJogadas

Combinadascom Critérios de

Busca

Efetuar Logoff

Fim

Cliente

AutenticarCliente

RecuperarJogadas v iaCritérios de

Busca

ApresentarMensagem"Nenhuma

JogadaEncontrada."

RecuperarJogadas

Catalogadas porJogos

ApresentarMensagem"Nenhuma

JogadaCatalogada."

Limpar Tela deConsulta de

Jogadas

[sim]

[não][não]

botão entrar

botão consultarbotão recuperar

botão logoff botão cancelar

[sim]

[não]

[sim]

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 Lógica de Negócio

Classes de Persistência de Dados

Classes de Infra-Estrutura Serviços Comuns

Classes de Interface do Usuário

Classes deLógica de Negócio

Classes dePersistência de Dados

Classes deInfra-Estrutura

Serviços Comuns

Mecanismo de Persistência Oracle

9i :Sistema de Banco de Dados

Microsoft Activ e Diretory System :

Sistema de 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.

http://www.ambysoft.com/books/theObjectPrimer.html

http://www.sparxsystems.com.au/products/ea_downloads.html

http://www.cetus-links.org/

ANÁLISE E PROJETO ORIENTADOS A OBJETOS

ENGENHARIA DE SOFTWARE 1/2

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

ANÁLISE E PROJETO ORIENTADOS A OBJETOS

ENGENHARIA DE SOFTWARE 2/2

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:

[email protected], [email protected]

Estudo de caso_com_modelagem_de_software_halan

Technology

Transcript of Estudo de caso_com_modelagem_de_software_halan