ESTUDO DE CASO: "PROBLEMA DA ACADEMIA DE GINÁSTICA" Maria Alice Grigas Varella Ferreira
1995/1996 1. ENUNCIADO
Uma academia de ginástica, preparando-se para o "boom" de alunos que antecede o verão, decide implantar um sistema informatizado de controle do acesso dos alunos às várias modalidades oferecidas. Os cursos oferecidos são: natação, ginástica localizada, ginástica: aeróbica, ginástica rítmica, judô, capoeira, basquete, volei, caratê e futebol. Cada modalidade pode ser cursada por alunos nas faixas etárias "infantil" e "adulto'', e são abertas aos dois sexos, com excessão da ginástica localiza, que só pode ser praticada por mulheres adultas, da ginastica rítmica destinada às meninas, e o futebol, praticado só por homens. As classes de adultos são separadas das classes infantis.
Quando um novo aluno se matricula, paga uma taxa de matrícula que lhe dá direito a escolher dois dos cursos oferecidos. A escolha é feita apresentando-se ao aluno as opções de horário disponíveis para as modalidades desejadas; quando o aluno define os cursos desejados, ele é cadastrado na lista de alunos daquele curso.
Os horários dos cursos são previaamente elaborados, havendo um limite de alunos específico para cada modalidade. O aluno, ao se inscrever no curso, recebe uma cartela de tickets com seu número de identificação e a identificação da turma em que está matriculado gravados em código de barras. Os tickets são válidos parra todo o mês, e são emitidos novamente mediante o pagamento da mensalidade.
Quando o aluno entra na classe, entrega um ticket ao grofessor, que o lê com a leitora de código de barras. Se o aluno estiver matriculado naquele curso, o sistema registra a presença; do contrário emite um alarme. Alunos que não faltarem a nenhuma aula no mês recebem um desconto de 5% na mensalidade.
Todos os alunos matriculados podem frequentar a sala de musculação, no horário que considerar mais conveniente e dependendo da disponibilidade dos aparelhos. Para ter acesso aos aparelhos, o aluno deve submeter sua carteirinha à leitora do aparelho, e estando este aluno habilitado, o aparelho é liberado para seu uso. Durante os exercícios, o aparelho registra o desempenho do aluno e outros dados do aluno; estes dados são armazenados e um relatório é emitido posteriormente, para fins de avaliação de seu desempenho.
2
2. MODELAMENTO
O modelamento deste sistema deve ser feito, utilizando-se os conceitos de Análise Estruturada. Para isso, deve-se fornecer:
• Diagrama de Contexto • Tabela de Eventos
• Diagrama de Fluxo de Dados, em níveis sucessivos de forma a representar as funções constantes do enunciado
• Dicionário de dados (fluxos e depósitos)
• Descrição sucinta (narrativa) de cada bolha do DFD. 2.1. Diagrama de Contexto
A entidade GERÊNCIA é encarregada do estabelecimento de horários de aulas, custos etc. Estes elementos poderiam ainda ser representados através de um depósito externo, produzido por um outro programa, porém entende-se que é mais natural definir aqui tal processo, apesar de não ter sido mencionado no enunciado.
A entidade MONITOR tem acesso aos dados de desempenho do aluno, a fim de estabelecer os programas mais convenientes para o mesmo. Também nada disso é mencionado no enunciado
O PROFESSOR está encarregado de realizar a leitura dos tickets, na entrada do aluno para as aulas.
Note-se ainda que a seta dupla representa fluxos de materiais e as setas simples, fluxos de dados. "tickets" é entendido como sendo um conjunto de "ticket", podendo ser definido como:
tickets = { ticket } 2.2. Tabela de Eventos
4
Caso esta saída não exista, o processamento associado ao evento está apenas alterando valores internos ao sistema, ou armazenando estes valores em depósitos internos.
Evento Tipo Parâmetros Saída associada Outros dados
associados
matricula F dados pessoais do
aluno, idade e sexo
turmas tipo_curso
opcao_turma F turmas escolhidas ---dados_cursos F horários das turmas e
informações sobre os cursos associados a estas turmas, como faixa etária, modalida-de, sexo dos participan-tes, etc.
---dados_vitais F dados coletados pelos sensores ligados ao aluno
---ticket F identificação do aluno e
da turma; são os dados que deverão compor a informação do ticket
liga /
----ident_ap F identificação do aluno e identificacão do apare-lho
libera_ap
mensalidade F identificação do aluno e dados do pagamento
progressos_aluno
ident F identificação do aluno valor_mens.
Sobre a tabela construída pode-se fazer algumas observações:
• Na primeira coluna, o evento "matrícula" exige alguns dados associados, que estão expressos na coluna da direita; "tipo_curso" é um fluxo exigido para o processamento de "matricula", e não um evento, como poderia ser imaginado a princípio.
• Os hífens, colocados na coluna "Saída associada", representam ações internas, sem respostas para o mundo exterior.
• "Dados do pagamento" são detalhes a serem resolvidos posteriormente.
• Finalmente, supõe-se que o relatório contendo os progressos do aluno, "progressos_aluno" é expedido por ocasião do pagamento da mensalidade pelo aluno, sendo encaminhado para o MONITOR deste aluno que irá fazer o seu julgamento sobre o mesmo. Analisando melhor esta opção feita, ela parece "pouco consistente" e, provavelmente, deverá ser alterada ao se analisar melhor o assunto.
que nesta fase conterá a definição dos fluxos ligados ao Diagrama de Contexto. A seguir detalham-se estes fluxos; os fluxos que contêm a anotação (*) ao lado, representam opções de projeto que poderiam ser consideradas prematuras para esta etapa da análise.
O Dicionário de Dados seguinte foi codificado através de um Editor de Textos e não segue nenhuma regra especial de formatação, isto é, não utiliza um formato do tipo empregado pelo PC-CASE, por exemplo.
matrícula = nome + sexo + idade nome = string [30 ] ( * )
sexo = M / F ( * ) idade = 1..90 ( * ) opções = 2 { tipo + turma } 2
tipo-curso = (vôlei, basquete,..., futebol)
turma = (1..m) m = número máximo de turmas
turmas = 0 { turma }m1 m1 = número máximo de turmas na modalidade opção-turma = turma
horário = dia-semana + hora-ini + hora-fim dia-semana = (segunda, ..., sábado)
hora-ini = hora hora-fim = hora hora = h +min h = (0..23) (*) min = (0..59) (*)
ticket = ident + turma +tipo-curso
tickets = 0 { ticket } n n = no. de aulas da turma no mês ident = integer ( * )
opção-turma = turma + tipo-curso
sinais-vitais = * dados referentes ao desempenho do aluno * ( * ) liga = * sinal de ativação do alarme * ( * )
ident-ap = ident-aparelho + ident
libera-ap = * sinal de liberação do aparelho de musculação * ident-aparelho = integer ( * )
dados-cursos = 0 {dado-curso}m2 , m2 = número máximo de especificações de cursos fornecidos
dado-curso = tipo-curso + turma + horário + faixa-etária + tipo-turma faixa etária = (infantil / adulto / idoso / bebê )
tipo-turma = M / F / A
valor-mensalidade = 99.999, 99 ( * )
6
São colocadas, em seguida, alguma recomendações iniciais sobre a construção do Diagrama de Fluxo de Dados, e que caracterizam os erros mais típicos, cometidos pelos projetistas que se iniciam nesta técnica; assim, leia atentamente estes itens.
• Todos os processos de um DFD devem ser nomeados (receber um nome: emitir fatura, por exemplo) e identificados (receber um número: 2, por exemplo). A identificação é usada como recurso auxiliar, na busca através de vários níveis de diagramas, onde o número grande de processos dificulta a busca por nome; a alegação de que "o meu problema é pequeno" não vale, porque é necessário manter-se o padrão de documentação para qualquer que seja o tamanho do problema. Também os depósitos de dados e entidades externas devem receber nomes e identificação. Convém indicar a duplicação destes elementos para lembrar o leitor de que eles já apareceram antes, ou devem ocorrer ainda em outro local do Diagrama de Contexto. Quando fizer a duplicação do elemento utilize fluxos correlacionados entrando ou saindo dos elementos duplicados.
• Os nomes dos fluxos não devem aparecer duplicados no DFD, mesmo que seu conteúdo seja o mesmo; para isso, utilize fluxos auxiliares, que auxiliam a descrição dos fluxos semelhantes (ver 5). Lembre que um fluxo que entra num processo_1 é diferente daquele que ocorre no processo_2, pois ocorrem em tempos e situações diferentes.
• O DFD só tem valia quando acompanhado de uma Descrição de Processos; sem isso, não se sabe exatamente o que está sendo feito em cada bolha. Também é necessário elaborar-se o Dicionário de Dados com a descrição de todos os fluxos e itens elementares, correspondente ao DFD; isto implica em “estender” o Dicionário apresentado no item 2.3.
• Colocar Diagrama de Contexto e cada Diagrama de Fluxo de Dados em uma folha separada, quando se elabora estes diagramas manualmente, pois isto, além de melhorar a estética" facilita a manutenção através da substituição da folha considerada, caso um erro seja detectado. Apesar de não se admitir, atualmente, que a elaboração dos DFDs seja feita por processo manual - para isso existem os CASEs- quando se desenha à mão, pode-se usar lápis, borracha, brancol ou recortes, conforme o caso. Evite sempre refazer diagramas, pois o ato de "passar a limpo" um diagrama irá, com grande probabilidade adicionar erros, já que a atenção não é a mesma do processo inicial.
• Não colocar nos DFDs observações que podem ser colocas em glossários ou Dicionários de Dados; também não entram aí especificações de fluxos compostos, na forma:
nome+sexo+idade.
• Estas expressões só comparecem no Dicionário de Dados. Quando uma destas expressões ocorrem em vários fluxos, por ex: ID_Ônibus+pontos +tempos + data, ela pode ser identificada por uma expressão auxiliar, como:
Onibus_percurso = ID_Ônibus+pontos +tempos ---> expressão auxiliar viagem = Ônibus_percurso + data
de atuarem no ambiente. Por trás de um vídeo ou de uma impressora estará sempre uma pessoa, que desempenha uma certa função: funcionário do RH, vendedor, secretária etc. Estes dispositivos são considerados apenas "meios de produção de uma saída".
• Cuidado com os depósitos de dados que só recebem dados, mas cujas informações não são utilizadas nunca. Eles não têm valia em seu projeto, a menos que sejam partilhados com um outro problema, e neste caso, são externos, devendo comparecer no Diagrama de Contexto.
• Não gerar níveis artificialmente; a geração de níveis é necessária para limitar o número de bolhas/nível; este número é de, no máximo, 10 bolhas por nível.
A página seguinte apresenta o DFD de nível 1 do problema.
2.5. Descrição dos processos
No diagrama da página seguinte estão apresentados 7 processos, compondo o DFD de nível 1. A descrição dos processos será apresentada na forma de narrativa.
8
controle_de_frequência - o professor fornece um ticket, com a identidade do aluno ao sistema e este consulta a lista de chamada do curso; se o aluno consta desta lista de chamada, sua frequência é anotada e a entrada do aluno na aula é liberada; caso contrario o sistema aciona um alarme para indicar que o aluno não está autorizado nesta turma;
atualiza_horários - a gerência atualiza os horários das turmas dos cursos;
controle_musculação - o aluno fornece sua identidade ao aparelho, e este libera a leitura dos dados vitais do aluno, que serão armazenados para a verificação do seu relatório de progressos mensais; o aparelho é também liberado para uso do aluno; sem este fornecimento de identidade o aparelho permanece travado; o seu uso só é permitido para os alunos regularmente matriculado e que portanto têm esta identidade.
2.6. Dicionário de Dados - Complementação
Após a explosão do Diagrama de Contexto, na qual se gera o nível 1 do DFD , deve-se complementar o DD, incluindo-se os depósitos e os novos fluxos que resultaram desta explosão. Estes novos fluxos não serão descritos aqui; descrevem-se entretanto, a título de exemplo alguns depósitos:
