EAD
Estudo de Caso: Sistema de
Controle de Alunos de Uma
Universidade
8
1. OBJETIVOS
• Visualizar, na prática, os principais conceitos estudados nas unidades anteriores, por
meio do desenvolvimento de um estudo de caso sobre um sistema de controle de alunos para uma universidade.
• Conhecer a ferramenta de modelagem UML Astah Community.
2. CONTEÚDOS
• Apresentação do desenvolvimento de um sistema para controle de alunos de uma universidade.
• Descrição do sistema.
• Apresentação dos requisitos.
• Apresentação das regras de negócio.
• Definição e descrição dos principais Casos de Uso.
• Elaboração do glossário. • Identificação das classes de análise.
• Construção do diagrama de classes de análise.
• Construção dos principais diagramas de sequência.
• Construção do Diagrama de Classes de projeto. • Construção do Diagrama de Atividades.
198
© Análise e Projeto de Sistemas
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE
Por se tratar da última unidade de estudo, é recomendável, nesta etapa, que você esteja
bem familiarizado com os assuntos estudados até o momento, pois faremos um estudo de caso
que permitirá uma breve revisão do conteúdo e o acompanhamento das etapas mais importantes do levantamento de requisitos e da modelagem de software.
Veja a seguir, os tópicos que devem ser objeto de estudo para esta unidade.
1) Entender bem o que é e quais são os propósitos da Linguagem de Modelagem Unificada (UML – Unified Modeling Language).
2) Durante o decorrer do estudo desta unidade é importante que você compreenda o
que são os requisitos para um sistema e com que finalidade eles são classificados em
funcionais e não funcionais, é importante também, que saiba como diferenciá-los.
3) Compreender o que são as regras de negócio e a sua importância para o desenvolvimento do software também será uma tarefa que você terá nesta unidade.
4) Lembre-se de que para ter um bom aproveitamento dos seus estudos é fundamental que conheça e coloque em prática as técnicas de levantamento de requisitos. É
importante que você compreenda essa etapa do desenvolvimento, e saiba avaliar as
consequências para um sistema de software quando essa tarefa não é devidamente
realizada.
5) É importante entender o que são os artefatos de software e quais são os artefatos
produzidos nas diferentes etapas do desenvolvimento de um software.
6) Entender o que são os casos de uso e saber a finalidade que eles são criados é imprescindível para o seu aprendizado, por isso fique atento a estes conceitos.
7) Durante o estudo desta unidade, é fundamental que compreenda que existem ferramentas que são abertas e podem ser copiadas para o seu computador. Sugerimos o Astah Community. No entanto, nada o impede de utilizar outra que já possua ou conheça.
O importante é saber que essas ferramentas nos auxiliam na elaboração dos desenhos,
podem gerar algum tipo de código, imprimem maior qualidade ao projeto etc.
4. INTRODUÇÃO À UNIDADE
Para que você possa rever os conceitos estudados na unidade anterior, de forma prática,
esta unidade tem por objetivo apresentar um sistema para controle de alunos de uma universidade. Acreditamos, com isso, que você terá seus conhecimentos consolidados.
Com certeza, sabemos que para desempenhar bem as tarefas de desenvolvedor de
software você precisa agregar muitas coisas. O conhecimento é fundamental, mas ele precisa
ser colocado em prática.
Você viu, nos estudos das unidades iniciais, quais são as características desejáveis ao perfil
do desenvolvedor de software. E, viu também, que a participação do usuário perante o desenvolvedor é de grande importância, pois enquanto o desenvolvedor tem conhecimento da área
técnica, o usuário tem o conhecimento sobre o domínio de negócio. Portanto, além dos conhecimentos técnicos, para que um sistema alcance o sucesso desejado, é de extrema importância
a presença do especialista do domínio de negócio, e ninguém melhor que o cliente/usuário para
isso.
Nesta unidade faremos uma revisão breve de cada conceito antes de colocá-lo em prática
para que você possa compreender bem cada etapa. E, fica a nossa sugestão: procure revisar
cada tópico, tentando elaborar uma solução melhor que a apresentada.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
199
É interessante colocar em prática seus conhecimentos procurando sempre conhecer novas técnicas. Não esqueça que um mesmo problema pode apresentar soluções diferentes, e
as mais simples podem ser, muitas vezes, as melhores. O desenvolvimento de software requer
também criatividade do desenvolvedor.
Vamos, então, começar nossa última etapa. Bons estudos a todos!
5. DESCRIÇÃO DO SISTEMA
Trata-se de um sistema para controle de alunos de uma universidade. Um sistema acadêmico para uma universidade é bastante extenso. Nosso foco será apenas nos processos relacionados mais diretamente aos alunos, ou seja, cadastro de alunos, matrícula, publicação das
notas.
Para isso, consideremos uma universidade que oferece diversos cursos. Um aluno pode
cursar mais que um curso, tanto ao mesmo tempo quanto em épocas diferentes. Ao ingressar
na universidade, um cadastro do aluno é feito, com suas informações pessoais.
O aluno é admitido e, no momento da matrícula, é realizado seu cadastro. Isso acontece
apenas na primeira matrícula do aluno. Os cursos são semestrais. Assim, o aluno faz nova matrícula a cada semestre, ou quando ingressa em um novo curso.
Existe um cadastro com todas as disciplinas, e também um com as disciplinas oferecidas
por semestre, para cada curso. Para cada semestre, o aluno faz uma matrícula nas disciplinas
que ele deseja cursar, e turmas são oferecidas para cada disciplina. Um professor pode ministrar
aulas em diversas disciplinas, e em cursos diferentes.
Para cada turma, é designada uma sala de aula ou laboratório, que podem ser utilizados
por diversas turmas. Disciplinas podem ter ou ser pré-requisito para/de outra disciplina. Um
aluno somente se matricula em determinada disciplina caso não haja qualquer tipo de impedimento para isso.
6. REQUISITOS DO SISTEMA
O levantamento de requisitos é uma fase em que se busca, com usuários, informações sobre as funções e restrições impostas ao sistema que será desenvolvido. As formas de obtenção
dessas informações, conforme já estudado, são as entrevistas com os usuários, a observação de
sua rotina de trabalho, a análise de documentos e os sistemas utilizados nas atividades atuais
do usuário.
Lembramos que os requisitos podem sofrer alterações durante todo o tempo de desenvolvimento do sistema, podendo aumentar ou diminuir o número de requisitos do sistema. No
nosso exemplo, como se trata de um sistema fictício (não temos realmente um cliente que possa
solicitar alterações nos requisitos), os requisitos levantados não sofrerão alterações no decorrer
do desenvolvimento do projeto do sistema.
Os requisitos são classificados em requisitos funcionais e requisitos não funcionais. Os requisitos funcionais correspondem a todas as funcionalidades do sistema, ou seja, a tudo o que
o sistema deve fazer. E, os requisitos não funcionais correspondem às restrições sobre como o
sistema deve realizar os requisitos funcionais.
Portanto, com base na descrição do sistema, em relação às funcionalidades que o siste-
200
© Análise e Projeto de Sistemas
ma de controle de alunos de uma universidade deve ter, podemos listar os seguintes requisitos
funcionais:
Requisitos funcionais – Sistema de Controle de Alunos de uma Universidade
a) RF1. O Sistema deve manter informações cadastrais sobre as disciplinas oferecidas
nos diversos cursos.
b) RF2. O Sistema deve manter informações cadastrais sobre os Professores/Coordenadores.
c) RF3. O Sistema deve manter informações cadastrais sobre as turmas abertas para
cada disciplina.
d) RF4. O Sistema deve manter informações cadastrais sobre as salas e os laboratórios
disponíveis para cada turma.
e) RF5. O Sistema deve manter informações cadastrais sobre os Alunos.
f) RF6. O Sistema deve permitir que Alunos façam matrícula em disciplina.
g) RF7. O Sistema deve permitir que Professores lancem as notas e faltas dos Alunos.
h) RF8. O Sistema deve permitir que Alunos visualizem as notas obtidas durante o semestre, assim como o número de faltas.
i) RF9. O Sistema deve manter as informações sobre os históricos escolares dos Alunos.
j) RF10. O Sistema deve permitir que o Aluno tranque ou cancele sua matrícula a qualquer momento, desde que ele não tenha pendências que o impeçam de tal ato.
k) RF11. O Sistema deve manter informações sobre a grade curricular de cada curso.
l) RF12. O Sistema deve permitir que os Coordenadores visualizem o andamento das
matrículas.
m) RF13. O Sistema deve permitir que o Professor mantenha as informações sobre o plano de ensino e o plano de aulas.
n) RF14. O Sistema deve calcular a média final do Aluno.
o) RF15. O Sistema deve calcular o percentual de faltas do Aluno.
p) RF16. O Sistema deve permitir que o aluno fique em uma lista de espera quando a
disciplina por ele solicitada para matrícula não tiver mais vagas, ou não tiver número
suficiente de interessados para ser aberta.
Como forma de apresentação do documento de requisitos, utilizaremos um formulário (já
apresentado para você quando estudamos os requisitos do Sistema). Ressaltamos que os requisitos funcionais podem ser classificados em evidentes ou ocultos.
Assim, a primeira versão do documento de requisitos funcionais fica:
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Requisitos Funcionais
Nome: Cadastrar Cursos.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações cadastrais sobre as disciplinas oferecidas nos diversos cursos.
Nome: Cadastrar Professores/Coordenadores.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações cadastrais sobre os Professores.
Nome: Cadastrar Turmas.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações cadastrais sobre as turmas abertas para cada disciplina.
Nome: Cadastrar Salas/Laboratórios.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações cadastrais sobre as salas e os laboratórios disponíveis para cada turma.
Nome: Cadastrar Alunos.
Centro Universitário Claretiano
Evidente/Oculto: (E)
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
201
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Descrição: O Sistema deve manter informações cadastrais sobre os Alunos.
Nome: Matricular Aluno.
Descrição: O Sistema deve permitir que Alunos façam matrícula em disciplina.
Evidente/Oculto: (E)
Nome: Lançar Notas e Faltas de Alunos.
Evidente/Oculto: (E)
Descrição: O Sistema deve permitir que Professores lancem as notas e faltas dos Alunos.
Nome: Visualizar Notas e Faltas.
Evidente/Oculto: (E)
Descrição: O Sistema deve permitir que Alunos visualizem as notas obtidas durante o semestre, assim como o número de
faltas.
Nome: Manter Controle sobre Históricos Escolares.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter as informações sobre os históricos escolares dos Alunos.
Nome: Trancar ou Cancelar Matrícula.
Evidente/Oculto: (E)
Descrição: O Sistema deve permitir que o aluno tranque ou cancele sua matrícula a qualquer momento, desde que ele não
tenha pendências que o impeçam de tal ato.
Nome: Cadastrar Grade Curricular.
Evidente/Oculto: (E)
Descrição: O Sistema deve manter informações sobre a grade curricular de cada curso
Nome: Visualizar Andamento das Matrículas.
Evidente/Oculto: (E)
Descrição: O Sistema deve permitir que os Coordenadores visualizem o andamento das matrículas.
Nome: Elaborar Plano de Ensino e Planos de Aula.
Evidente/Oculto: (E)
Descrição: O Sistema deve permitir que o Professor mantenha as informações sobre o plano de ensino e planos de aula.
Nome: Cálculo da Média Final.
Descrição: O Sistema deve calcular a média final do Aluno.
Evidente/Oculto: (O)
Nome: Cálculo do Percentual de Faltas.
Descrição: O Sistema deve calcular o percentual de faltas do Aluno.
Evidente/Oculto: (O)
Nome: Atender Lista de Espera.
Evidente/Oculto: ( E)
Descrição: O Sistema deve permitir que o aluno fique em uma lista de espera quando a disciplina por ele solicitada para
matrícula não tiver mais vagas, ou não tiver número suficiente de interessados para ser aberta.
Os requisitos não funcionais podem ser classificados em várias categorias, como já foi
visto anteriormente. Dentre estas categorias temos: usabilidade, confiabilidade, performance,
configurabilidade, segurança, implementação, interface, entre outras.
Além disso, os requisitos não funcionais podem ser classificados em obrigatórios ou desejáveis, e também em permanentes ou transitórios.
Os seguintes requisitos não funcionais podem ser listados, inicialmente, para o sistema de
controle de alunos de uma universidade:
Nome: Controle de Acesso.
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Requisitos Não Funcionais
Obrigatório/Desejável (O)
Permanente/Transitório (P)
202
© Análise e Projeto de Sistemas
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Requisitos Não Funcionais
Restrições:
1. As operações de cadastro de cursos, salas e
laboratórios, disciplinas, turmas e alunos somente
serão realizadas por usuários com permissão
concedida aos funcionários administrativos da
secretaria escolar.
2. As operações de cadastro de Professores e
Coordenadores somente serão realizadas por
usuários com permissão concedida aos funcionários
administrativos do departamento de recursos
humanos.
3. As operações referentes a matricula de alunos,
trancamento ou cancelamento de matrículas,
manutenção das informações geradas em históricos Categoria: Segurança
escolares apenas serão realizadas por usuários
com permissão concedida aos funcionários
administrativos da secretaria escolar.
4. Lançamentos de notas, elaboração de plano de
ensino e planos de aulas somente serão efetuados
por usuários com permissão de Professor.
5. Visualização do andamento das matrículas,
manutenção de grade curricular, abertura e
fechamento de turmas e atendimento de listas de
espera são operações realizadas por usuários com
a permissão de coordenador.
6. Aos usuários com perfil de aluno somente serão
permitidas as operações de consultas aos boletins,
planos de ensino e de aulas, grade curricular e
grade de horários.
Nome: Identificação do aluno.
Obrigatório/Desejável (D)
Permanente/Transitório (P)
Restrição: O aluno será identificado por seu nome
Categoria: Interface
ou pelo número do Registro Acadêmico (RA).
Nome: Identificação do Professor/Coordenador.
Obrigatório/Desejável (D)
Permanente/Transitório (P)
Restrição:
O
Professor/Coordenador
será
identificado por seu nome ou por seu código Categoria: Interface
funcional.
Nome: Armazenamento de dados.
Obrigatório/Desejável (O)
Permanente/Transitório (P)
Restrição: O Sistema deve ser desenvolvido
(camada de persistência) de forma que diferentes
Categoria: Persistência
tecnologias de banco de dados possam ser
utilizadas.
7. DOCUMENTAÇÃO DAS REGRAS DE NEGÓCIO
Uma das etapas do desenvolvimento de um sistema é a determinação das regras de negócio. Trata-se das políticas, condições ou restrições a serem consideradas para a execução do
sistema. São específicas da organização para a qual o sistema está sendo desenvolvido, pois elas
descrevem a forma como a organização funciona. E, é na fase de levantamento de requisitos que
elas são determinadas.
Depois de definidas, elas são documentadas no modelo de regras de negócio. Assim, podemos definir as seguintes regras de negócio para o sistema de controle de alunos de uma universidade:
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
203
Número máximo de alunos admitidos por turma.
Número máximo de créditos a serem cursados por semestre.
Habilitação do Professor para ministrar as aulas em um determinado curso.
Pré-requisitos para uma disciplina.
Cancelamento de matrícula.
Trancamento de matrícula.
Valor mínimo da média para aprovação do aluno.
Percentual mínimo de frequência para aprovação do aluno.
Para uma turma ser aberta, ela deve estar cadastrada no sistema.
Número mínimo de alunos para abertura de uma turma.
As regras de negócio podem ser acomodadas em um formulário denominado modelo de
regras de negócio. O layout deste formulário fica a critério do desenvolvedor. Deve ser simples,
apenas com as informações necessárias para a documentação.
Veja as regras de negócio do sistema acomodadas no documento:
SISTEMA DE CONTROLE DE ALUNOS DE UMA UNIVERSIDADE
Regras de Negócio
RN1. Número máximo de alunos admitidos por turma.
Descrição
Cada turma, independentemente do curso, poderá ter, no máximo, 50 alunos.
RN2. Número máximo de créditos a serem cursados por semestre.
Descrição
Um aluno pode cursar, no máximo, a quantidade de disciplinas referentes a 30 créditos por semestre.
RN3. Habilitação do Professor para ministrar as aulas em um determinado curso.
Descrição
Um Professor deverá possuir, no mínimo, a titulação de especialista para ministrar aulas.
RN4. Pré-requisitos para uma disciplina.
Uma disciplina poderá ser pré-requisito para apenas uma disciplina.
Descrição
RN5. Cancelamento de matrícula.
Um aluno pode cancelar sua matrícula, desde que não haja qualquer pendência referente ao período em que
Descrição
esteve matriculado.
RN6. Trancamento de matrícula.
Um aluno pode cancelar sua matrícula, desde que não haja qualquer pendência referente ao período em que
Descrição
esteve matriculado.
RN7. Valor mínimo da média para aprovação do aluno.
O valor mínimo para que um aluno esteja aprovado em uma disciplina é 6,0 (além do percentual mínimo de
Descrição
frequência).
RN8. Percentual mínimo de frequência para aprovação do aluno.
Um aluno deve ter um percentual mínimo de 75% de frequência em cada disciplina para ser aprovado (além
Descrição
do valor mínimo para a média).
RN9. Turma deve ser cadastrada antes da abertura.
Descrição
Para uma turma ser aberta, ela deve estar cadastrada no Sistema.
RN10. Número mínimo de alunos para abertura de uma turma.
Descrição
Uma turma deve ter um mínimo de 30 alunos para ser aberta.
204
© Análise e Projeto de Sistemas
8. DOCUMENTAÇÃO DO MODELO DE CASOS DE USO
A documentação dos Casos de Uso envolve identificar os atores e os Casos de Uso envolvidos em cada caso.
No sistema de controle de alunos de uma universidade identificamos os seguintes atores:
001) Secretaria Acadêmica: setor da universidade responsável por manter todas as informações sobre os alunos e sua vida acadêmica na universidade.
a) Sistema de Recursos Humanos: Sistema responsável por manter e fornecer informações sobre Professores/Coordenadores ao Sistema de controle de alunos de uma universidade.
b) Aluno: aquele que ingressa em um curso na universidade.
c) Professor: aquele que leciona disciplinas oferecidas nos cursos da universidade.
d) Coordenador: aquele que é responsável por manter o controle e cuidar dos assuntos
referentes a determinado curso (alunos, professores, grade curricular, planos de ensino e de aulas, andamento das matrículas).
Uma vez identificados os atores que vão interagir com o Sistema, é necessário identificar
os Casos de Uso e associá-los aos atores que deles participam:
a) Cadastrar Turmas (Secretaria Acadêmica).
b) Abrir Turma (Coordenador).
c) Fechar Turma (Coordenador).
d) Inserir Informações sobre Aluno (Secretaria Acadêmica).
e) Pesquisar Informações sobre Aluno (Secretaria Acadêmica).
f) Atualizar Informações sobre Aluno (Secretaria Acadêmica).
g) Pesquisar Informações sobre Professor (Secretaria Acadêmica).
h) Pesquisar Informações sobre Coordenador (Secretaria Acadêmica).
i) Manter Informações sobre Disciplina (Secretaria Acadêmica).
j) Manter Informações sobre a Grade Curricular de Curso (Coordenador).
k) Manter Informações sobre Plano de Ensino (Professor).
l) Manter Informações sobre Plano de Aulas (Professor).
m) Manter Informações sobre Sala/Laboratório (Secretaria Acadêmica).
n) Matricular Aluno (Aluno).
o) Cancelar Matrícula (Aluno).
p) Trancar Matrícula (Aluno).
q) Lançar Notas e Faltas (Professor).
r) Visualizar Boletim (Aluno).
s) Visualizar Andamento das Matrículas (Coordenador).
t) Atender Lista de Espera (Coordenador).
Depois que os Casos de Uso foram definidos, o próximo passo é elaborar uma descrição
dos processos identificados. Os Casos de Uso que representam os processos mais complexos
merecem mais atenção, pois da descrição bem elaborada deles depende da compreensão do
processo por parte dos envolvidos com o Sistema. Portanto, não há necessidade de descrever
todos os Casos de Uso.
Apresentamos, então, a descrição de apenas alguns Casos de Uso. Como sugestão, procure descrever todos os Casos de Uso. Lembre-se de que quanto mais praticar, mais fáceis essas
tarefas vão se tornando.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
205
Quando estudamos os Casos de Uso, você aprendeu que eles podem ser descritos sob
formatos diferentes. Apresentamos, naquela ocasião, o formato tabular. Neste projeto, utilizaremos outro formato, o sequencial. A escolha do formato de apresentação da descrição dos
Casos de Uso fica a critério do desenvolvedor da tarefa. Qualquer uma das formas apresentadas
é correta. O importante é que a descrição seja clara e colabore para a compreensão do processo
descrito.
Vamos, neste exemplo, descrever os seguintes Casos de Uso:
a) Matricular Aluno.
b) Lançar Notas e Faltas.
c) Atender Lista de Espera.
d) Visualizar Boletim.
e) Visualizar Andamento das Matrículas.
f) Abrir Turma.
Descrição dos Principais Casos de Uso do Sistema
a) Caso de Uso: Matricular Aluno.
b) Sumário: Aluno solicita matrícula em disciplina.
c) Ator Primário: Aluno.
d) Ator Secundário: Secretaria Acadêmica.
e) Pré-condições: o Aluno deve estar cadastrado no Sistema; o Aluno não pode estar
reprovado em disciplina que seja pré-requisito para a disciplina na qual deseja se matricular.
Fluxo Principal
a) O Aluno solicita realização de matrícula.
b) O Sistema apresenta a lista de disciplinas nas quais o Aluno pode se matricular (o Sistema não disponibiliza para o Aluno as disciplinas que são pré-requisitos para aquelas
que ele ainda não tenha cursado ou nas quais esteja reprovado).
c) O Aluno seleciona as disciplinas que deseja cursar.
d) Para cada disciplina escolhida, o Sistema apresenta as turmas que oferecem tal disciplina.
e) O Aluno escolhe a turma desejada.
f) Para a turma escolhida, o Sistema informa a sala/laboratório no qual as aulas serão
ministradas, assim como o nome do Professor e os dias e os horários das aulas. A
sequência dos passos 4, 5 e 6 deve ser repetida para cada disciplina escolhida pelo
Aluno.
g) O Sistema solicita a confirmação do Aluno para as turmas escolhidas.
h) O Aluno confirma suas escolhas.
i) O Sistema registra a matrícula do Aluno nas disciplinas escolhidas.
j) O Sistema encerra a operação.
Fluxo Alternativo (4): Inclusão do Aluno em lista de espera.
a) O sistema informa que não existe turma aberta para a disciplina escolhida, ou que não
há mais vagas na turma.
b) O Sistema oferece uma lista de espera para o Aluno aguardar pela possibilidade de
abertura de turma para a disciplina escolhida.
c) Se o aluno aceitar, o sistema o insere na lista de espera. O sistema volta ao passo 4,
caso haja mais disciplinas escolhidas, ou vai para o passo 7.
206
© Análise e Projeto de Sistemas
d) Se o aluno não aceitar, o sistema volta ao passo 4, caso haja mais disciplinas escolhidas, ou vai para o passo 7.
Fluxo de Exceção (4): Violação da RN02.
a) Excesso de créditos nas disciplinas escolhidas pelo aluno para o semestre. O sistema
informa ao aluno a quantidade de créditos excedentes, para que ele possa refazer suas
escolhas. O Sistema volta ao passo 3.
Pós-condições: o aluno foi matriculado nas disciplinas selecionadas e/ou foi inscrito em
uma ou mais listas de espera.
Regras de Negócio: RN1, RN2, RN4.
Caso de Uso: lançar notas e faltas.
Sumário: Professor lança notas e faltas dos Alunos para a disciplina que ele ministrou no
período.
Ator Primário: Professor.
Ator Secundário: não há.
Pré-condições: o Professor deve estar cadastrado no sistema.
Fluxo Principal
a) O Professor solicita o lançamento de notas.
b) O Sistema apresenta a lista de disciplinas relacionadas ao Professor.
c) O Professor escolhe a disciplina para a qual as notas e faltas serão lançadas.
d) Para a disciplina escolhida, o Sistema exibe as turmas.
e) O Professor escolhe a turma para a qual fará o lançamento das notas e faltas.
f) O Sistema exibe a lista com os nomes dos Alunos matriculados na turma.
g) Para cada Aluno, o Professor lança as notas e o número de faltas no período.
h) O Sistema solicita a confirmação dos dados pelo Professor.
i) O Professor confirma os dados.
j) Para cada Aluno, o Sistema calcula a média das notas e o percentual de frequência no
período.
k) O Sistema registra os resultados.
l) O Sistema encerra a operação.
Fluxo Alternativo (9): Professor não confirma os dados digitados.
a) O Professor verifica que lançou nota ou falta errada para um ou mais alunos.
a) O Professor faz as devidas correções.
b) O Sistema registra a correção e vai para o passo 10.
Fluxo de Exceção (8): Lançamento de nota ou falta não realizada para um ou mais alunos.
a) O Sistema informa ao Professor que não houve o lançamento de nota e/ou falta para
o aluno.
b) O Professor faz o lançamento que falta.
c) O Sistema retorna ao passo 8.
Pós-condições: as notas e frequências dos alunos que cursaram uma disciplina em determinada turma foram lançadas, e a média das notas, assim como o percentual de frequência para
cada aluno, no período, foram calculados e registrados.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
207
Pós-condições: o Aluno foi matriculado nas disciplinas selecionadas e/ou foi inscrito em
uma ou mais listas de espera.
Regras de Negócio: RN7, RN8.
Caso de Uso: Atender Lista de Espera.
Sumário: Coordenador cria uma turma extra para atender demanda.
Ator Primário: Coordenador.
Ator Secundário: Aluno.
Pré-condições: O Coordenador deve estar cadastrado no Sistema; deve existir uma lista de
espera com um mínimo de 30 alunos para ser atendida.
Fluxo Principal
a) Ao completar 30 alunos na lista de espera para determinada disciplina, o Sistema sinaliza esta informação.
b) O Coordenador solicita abertura da lista sinalizada, com os nomes dos interessados
em determinada disciplina.
c) O Sistema apresenta as informações da lista solicitada.
d) O Coordenador solicita que a lista seja atendida.
e) O Sistema solicita as informações para abertura da turma extra.
f) O Coordenador informa o(s) dia(s) e horário(s) para o funcionamento da nova turma.
g) O Sistema apresenta a lista de Professores disponíveis.
h) O Coordenador seleciona o Professor.
i) O Sistema exibe as salas/laboratórios disponíveis.
j) O Coordenador seleciona a sala/laboratório.
k) O Sistema solicita confirmação dos dados informados.
l) O Coordenador confirma os dados.
m) O Sistema registra a abertura da turma extra.
n) O Sistema transfere cada Aluno da lista para a nova turma, excluindo a lista.
o) O Sistema registra as novas matrículas.
p) O Sistema envia um e-mail automático a cada Aluno informando sobre a efetivação
da matrícula.
q) O Sistema encerra a operação.
Fluxo Alternativo (7): Não há Professores disponíveis para os dias/horários informados.
b) O Sistema informa que não existe disponibilidade de Professor para os dias/horários
informados pelo Coordenador, e solicita nova entrada de dias/horários.
c) O Coordenador informa novos dias/horários. Caso haja possibilidade de Professores, o Sistema continua no passo 9.
d) Caso não haja disponibilidade de Professores, o Sistema volta ao passo (a) deste fluxo
alternativo até que haja disponibilidade, ou o Coordenador pode solicitar ao Sistema
que cancele a lista e encerre a operação.
Fluxo Alternativo (9): não há salas/laboratórios disponíveis para os dias/horários informados.
a) O Sistema informa que não existe disponibilidade de sala/laboratório para os dias/
horários informados pelo Coordenador, e solicita nova entrada de sala/laboratório.
b) O Coordenador informa nova sala/laboratório. Caso haja possibilidade de sala/laboratório, o Sistema continua no passo 11.
208
© Análise e Projeto de Sistemas
c) Caso não haja disponibilidade de sala/laboratório, o Sistema volta ao passo (a) deste
fluxo alternativo até que haja disponibilidade, ou o Coordenador pode solicitar ao
Sistema que cancele a lista e encerre a operação.
Pós-condições: uma turma extra foi criada para determinada disciplina.
Regras de Negócio: RN1, RN9.
Caso de Uso: Visualizar Boletim.
Sumário: Aluno solicita visualização de seu boletim (notas e faltas) para o período escolar.
Ator Primário: Aluno.
Ator Secundário: Não há.
Pré-condições: O Aluno deve estar cadastrado no Sistema e matriculado em disciplinas.
Fluxo Principal
a) O Aluno solicita visualização de seu boletim.
b) O Sistema exibe as notas, médias, número de faltas e percentual de frequência para
cada disciplina.
c) O Aluno visualiza as informações exibidas.
d) O Sistema encerra a operação.
Pós-condições: O boletim do Aluno foi exibido.
Caso de Uso: Visualizar Andamento das Matrículas.
Sumário: Coordenador solicita ao Sistema a visualização do andamento das matrículas nas
disciplinas que estão sendo oferecidas para o próximo semestre letivo.
Ator Primário: Coordenador.
Ator Secundário: Não há.
Pré-condições: O Coordenador deve estar cadastrado no Sistema.
Fluxo Principal
a) O Coordenador solicita ao Sistema a visualização do andamento das matrículas realizadas até o momento nas disciplinas oferecidas.
b) O Sistema exibe a lista com todas as disciplinas oferecidas para o próximo semestre.
c) O Coordenador seleciona uma disciplina para a qual deseja ver o andamento das matrículas.
d) O Sistema exibe a lista das turmas que foram abertas para oferecer tal disciplina.
e) O Coordenador seleciona a turma para a qual deseja ver o andamento das matrículas.
f) O Sistema exibe uma lista contendo os dias e horários nos quais a disciplina será ministrada, o nome do Professor e a relação de todos os Alunos que já efetuaram suas
matrículas na referida turma.
g) O Coordenador visualiza as informações contidas na lista.
h) Caso o Coordenador deseje continuar com a visualização de outras turmas, o Sistema
retorna ao passo 4; caso contrário, o Sistema encerra a operação.
Pós-condições: Listas com matrículas realizadas até o momento foram visualizadas pelo
Coordenador.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
209
Caso de Uso: Abrir Turma.
Sumário: Coordenador abre turma para atender a demanda de Alunos em disciplinas no
próximo semestre letivo.
Ator Primário: Coordenador.
Ator Secundário: Não há.
Pré-condições: O Coordenador deve estar cadastrado no Sistema; o nome de turma deve
estar cadastrado no Sistema.
Fluxo Principal
a) O Coordenador solicita ao Sistema a relação de turmas cadastradas e ainda não abertas para determinada disciplina de um curso.
b) O Sistema exibe a lista das turmas disponíveis.
c) O Coordenador seleciona uma turma para a qual deseja ofertar disciplina no próximo
semestre, referente a determinado curso sob sua coordenação.
d) O Sistema exibe a lista com os nomes dos Professores que ministram tal disciplina e
suas disponibilidades de horários.
e) O Sistema solicita a escolha de um Professor.
f) O Coordenador seleciona o Professor.
g) O Sistema solicita o(s) dia(s) e horário(s) das aulas.
h) O Coordenador informa o(s) dia(s) e horário(s) das aulas, de acordo com a disponibilidade do Professor.
i) O Sistema solicita confirmação das escolhas.
j) O Coordenador confirma as escolhas.
k) O Sistema registra as informações e a turma é aberta.
l) O Sistema encerra a operação.
Fluxo Alternativo (2): Não existe turma criada para tal disciplina.
a) O Sistema informa que não existe turma criada para tal disciplina.
e) Se o Coordenador desejar que a turma seja criada, executar o Caso de Uso "Cadastrar Turma"; caso contrário, o Sistema executa o passo 12.
Fluxo de Alternativo (6): Coordenador não escolhe Professor.
a) O Coordenador não escolhe Professor, por haver algum tipo de impedimento de dia/
horário para a abertura da turma, de acordo com as disponibilidades dos Professores
que ministram a disciplina.
f) O Sistema executa o passo 12.
Fluxo de Alternativo (10): Coordenador não confirma as escolhas.
b) O Coordenador não confirma suas escolhas.
g) Se Coordenador quiser repetir as escolhas, o Sistema retorna ao passo 2; caso
contrário, o Sistema executa o passo 12.
Pós-condições: uma turma foi aberta para oferecer uma disciplina no próximo semestre
letivo.
Regras de Negócio: RN9.
Todos os diagramas que serão criados no projeto Controle de Alunos de uma Universidade
serão mostrados, passo a passo, no Tópico 14.
210
© Análise e Projeto de Sistemas
Diagrama de Casos de Uso
O primeiro diagrama que vamos elaborar para o nosso sistema é o Diagrama de Casos de
Uso. Ele representa, por meio de elementos gráficos definidos pela UML, os atores, os Casos de
Uso e os relacionamentos entre eles.
Para desenhar os diagramas deste sistema, utilizaremos uma ferramenta gráfica aberta,
denominada Astah Community, e que pode ser acessada por meio do endereço: <http://astah.
change-vision.com/en/product/astah-community.html>. Caso tenha alguma dificuldade, entre
em contato com seu tutor.
A seguir, o Diagrama de Casos de Uso para o Sistema de Controle de Alunos de uma Universidade.
Figura 1 Diagrama de Casos de Uso para o Sistema de Controle de Alunos de
uma Universidade.
9. DOCUMENTAÇÃO DO MODELO DE CLASSES
Vimos que existem três fases para o modelo de classes: o modelo de classes de análise, o
modelo de classes de projeto e o modelo de classes de implementação.
A primeira delas refere-se à modelagem conceitual de classes, cuja finalidade é descrever
as informações que o sistema vai gerenciar. É uma fase associada ao domínio do problema,
fazendo parte da fase de análise do desenvolvimento de um projeto. Nela são descobertos os
conceitos relacionados ao sistema, ou seja, quem contém as informações a serem tratadas pelo
sistema. É um modelo independente da solução física. O modelo de classes de análise é representado pelo Diagrama de Classes da UML, e tem três elementos que representam a informação: conceitos, atributos e associações.
Conforme já visto anteriormente, este modelo pode ser obtido pela análise dos Casos de
Uso. Por meio de cada caso de uso, é possível identificar quais classes são necessárias para obtenção dos resultados externamente visíveis.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
211
Observemos como fazer para descobrir os elementos do modelo conceitual:
• Identificamos, nos Casos de Uso, palavras que correspondam a conceitos sobre os quais
desejamos manter informações no sistema.
• Identificamos e agrupamos palavras que são sinônimos.
• Procuramos, dentre as palavras identificadas, separar aquelas que são atributos, das
que são conceitos.
Revendo os Casos de Uso do Sistema de Controle de Alunos de uma Universidade, podemos, inicialmente, identificar os seguintes conceitos:
a) Curso;
b) Disciplina;
c) Grade Curricular;
d) Turma;
e) Plano de Ensino;
f) Plano de Aulas;
g) Lista de Espera;
h) Sala/Laboratório;
i) Coordenador;
j) Professor;
k) Aluno;
l) Boletim.
Você deve estar lembrado que, apesar de conseguirmos identificar alguns conceitos diretamente nos Casos de Uso, nem sempre o diagrama é construído apenas com estes conceitos.
Vejamos o Diagrama de Classes em sua primeira versão (consulte o tutorial do tópico 14, para
acompanhar o passo a passo da construção do diagrama).
Figura 2 Diagrama de Classes para o Sistema de Controle de Alunos de uma Universidade.
212
© Análise e Projeto de Sistemas
Note que temos, nesse diagrama, uma classe associativa chamada ItemMatricula. Essa
classe contém informações das duas classes às quais ela está relacionada, isto é, as classes Matricula e DisciplinaOfertada.
Imagine um aluno cursando seis disciplinas no semestre de determinado curso. A classe
Matricula deve conter informações como o nome do aluno, o ano e o semestre da matrícula, o
curso etc. Na classe DisciplinaOfertada temos informações sobre cada disciplina que está sendo oferecida no semestre. A classe associativa ItemMatricula deve conter informações como o
nome do aluno e a disciplina que ele está cursando (atualmente matriculado) ou, inclusive, as
disciplinas que ele já tenha cursado. Portanto, é nesta classe que conseguimos perceber quais
são todas as disciplinas nas quais o aluno já esteve ou encontra-se matriculado em determinado
curso.
Outra classe associativa é a classe Ministra. Ela está associada às classes DisciplinaOfertada e ProfessorDisc. Esta classe deve conter informações que nos permitem responder, por
exemplo, à seguinte questão: "Quais são as disciplinas ministradas por determinado professor
no semestre corrente?". Ou também: "Quais disciplinas determinado professor ministrou no
semestre anterior?", além de outras.
Temos, ainda, uma classe chamada ItemLista conectada à classe ListaEspera por meio de
uma associação do tipo composição. Significa que a classe ListaEspera pode conter informações
sobre o número de uma lista, a quantidade de alunos inscritos nela e o nome da disciplina para
a qual a lista foi aberta. E em ItemLista podem constar informações relacionadas ao aluno que
tem interesse na matrícula na referida disciplina.
10. GLOSSÁRIO
O glossário é a relação dos termos relevantes do domínio do sistema. No nosso caso, os
termos relacionados ao domínio da universidade. Eles podem ser termos relacionados às classes do sistema, a palavras utilizadas pelos usuários, ou qualquer outro tipo de termo que esteja
relacionado ao domínio e ao qual se queira associar um tipo de definição.
Sugere-se que os termos relacionados apareçam em ordem alfabética, para facilitar a busca por seus significados.
O glossário pode ser atualizado constantemente, enquanto o sistema estiver em desenvolvimento. Conforme os termos vão surgindo, eles podem ser acrescentados.
Inicialmente, são estes os termos definidos para o glossário do Sistema de Controle de
Alunos de uma Universidade:
a) Aluno: pessoa que faz matrícula em determinado curso.
b) Coordenador: pessoa responsável pela coordenação de um curso. Cabe ao coordenador as tarefas de contratação de professores, abertura de turmas, manutenção de
grades de horário, compras de equipamentos para laboratórios, compra de livros técnicos e acompanhamento do andamento do curso.
c) Curso: instrumento para a formação profissional. Oferecido pela universidade, é composto por disciplinas inter-relacionadas, que devem ser cumpridas em determinado
tempo.
d) Secretaria Acadêmica: departamento da universidade responsável por manter as informações relacionadas aos alunos e professores atualizadas, providenciar e fornecer
documentos para alunos, manter os registros de notas e situação acadêmica de cada
aluno.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
213
e) Disciplina: componente da grade curricular de um curso. Mesmo que presente em
vários cursos, tem seu conteúdo específico a cada um. Pode ser ministrada por mais
de um professor do mesmo curso.
f) Disciplina Ofertada: trata-se das disciplinas que são oferecidas em determinado semestre.
g) Lista de Espera: lista na qual os alunos se inscrevem, interessados em uma disciplina
para a qual ainda não foi aberta turma, mas que pode vir a existir como turma, caso
haja um número mínimo de 30 alunos interessados.
h) Matrícula: corresponde à inscrição de um aluno em determinadas disciplinas oferecidas em um curso.
i) Ministrar: lecionar uma determinada disciplina.
j) Plano de Aula: relação das tarefas a serem cumpridas em cada aula de determinada
disciplina de um curso.
k) Plano de Ensino: plano elaborado para o cumprimento de tarefas relacionadas a uma
disciplina de um curso em particular.
l) Professor: pessoa responsável por ministrar aulas de determinadas disciplinas às turmas de um curso. Ele deve seguir o plano de aulas por ele mesmo elaborado e avaliar
o aluno no conteúdo ministrado.
m) Registro de Notas: corresponde ao boletim do aluno, com suas notas, faltas, média e
percentual de frequência.
n) Sala/Laboratório: local da universidade onde ocorrem as aulas teóricas e práticas de
uma disciplina.
o) Turma: representa um grupo de alunos que cursa determinada disciplina de um curso,
na mesma sala, mesmo dia e horário.
11. DOCUMENTAÇÃO DO MODELO DE INTERAÇÕES
A modelagem de interações tem um papel de extrema importância no sistema, pois ela
completa aquilo que falta no modelo de Casos de Uso e no modelo de classes.
O modelo de interações representa as mensagens trocadas entre os objetos para a execução dos cenários dos Casos de Uso que foram levantados para o sistema. Nesta fase há a consolidação do entendimento sobre o sistema, pois somente depois que os diagramas que compõem
este modelo são construídos para os cenários dos Casos de Uso, é que se tem clareza sobre as
responsabilidades que os objetos devem cumprir.
O modelo de interações destaca os diagramas de sequência e os diagramas de comunicação. Faremos, para dar continuidade ao projeto do nosso sistema, os diagramas de sequência,
pois estes são os mais utilizados.
Para a criação dos diagramas de sequência, devemos observar os seguintes passos:
a) Preparar pelo menos um cenário para cada Caso de Uso. Vamos considerar, para nosso
sistema, o fluxo principal de cada caso de uso descrito, pois estes foram considerados
os mais relevantes ao processo como um todo.
b) Lembrar que os diagramas de sequência mostram claramente a contribuição de cada
ator, e isso leva à compreensão sobre o comportamento dos objetos.
c) Dividir as interações complexas, de forma que, para cada interação desmembrada,
seja construído um diagrama de sequência.
d) Se for necessário para colaborar com a compreensão do processo, prepare um diagrama de sequência para cada condição de erro.
214
© Análise e Projeto de Sistemas
Os Casos de Uso descritos foram:
a) Matricular Aluno.
b) Lançar Notas e Faltas.
c) Atender Lista de Espera.
d) Visualizar Boletim.
e) Visualizar Andamento das Matrículas.
f) Abrir Turma.
Para cada caso de uso vamos extrair o fluxo principal dele, e o diagrama de sequência terá
esse fluxo como base. Veja o tutorial sobre a construção dos diagramas de sequência no Tópico
14 desta unidade.
O fluxo principal para o caso de uso Matricular Aluno é:
Matricular Aluno
a) O Aluno solicita realização de matrícula.
b) O Sistema apresenta a lista de disciplinas nas quais o Aluno pode se matricular (o Sistema não disponibiliza para o Aluno as disciplinas que são pré-requisitos para aquelas
que ele ainda não tenha cursado ou nas quais esteja reprovado).
c) O Aluno seleciona as disciplinas que deseja cursar.
d) Para cada disciplina escolhida, o Sistema apresenta as turmas que oferecem tal disciplina.
e) O Aluno escolhe a turma desejada.
f) Para a turma escolhida, o Sistema informa a sala/laboratório onde as aulas serão ministradas, assim como o nome do Professor e os dias e os horários das aulas. A sequência dos passos 4, 5 e 6 deve ser repetida para cada disciplina escolhida pelo Aluno.
g) O Sistema solicita a confirmação do Aluno para as turmas escolhidas.
h) O Aluno confirma suas escolhas.
i) O Sistema registra a matrícula do Aluno nas disciplinas escolhidas.
j) O Sistema encerra a operação.
Podemos identificar as seguintes classes envolvidas:
AlunoCurso
DisciplinaOfertada
Turma
Matricula
ItemMatricula
O diagrama de sequência para este cenário é:
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
215
Figura 3 Diagrama de Sequência para o fluxo principal do caso de uso Matricular Aluno.
Vamos elaborar o diagrama de sequência para o fluxo principal do caso de uso Lançar Notas e Faltas. O fluxo principal dele contém os seguintes passos:
Lançar Notas e Faltas
a) O Professor solicita o lançamento de notas.
b) O Sistema apresenta a lista de disciplinas relacionadas ao Professor.
c) O Professor escolhe a disciplina para a qual as notas e faltas serão lançadas.
d) Para a disciplina escolhida, o Sistema exibe as turmas.
e) O Professor escolhe a turma para a qual fará o lançamento das notas e faltas.
f) O Sistema exibe a lista com os nomes dos Alunos matriculados na turma.
g) Para cada Aluno, o Professor lança as notas e o número de faltas no período.
h) O Sistema solicita a confirmação dos dados pelo Professor.
i) O Professor confirma os dados.
j) Para cada Aluno, o Sistema calcula a média das notas e o percentual de frequência no
período.
k) O Sistema registra os resultados.
l) O Sistema encerra a operação.
As classes identificadas neste caso de uso são:
ProfessorDisc
DisciplinaOfertada
Turma
RegistroNotas
216
© Análise e Projeto de Sistemas
O diagrama de sequência para este cenário é:
Figura 4 Diagrama de Sequência para o fluxo principal do caso de uso Lançar Notas e Faltas.
12. DOCUMENTAÇÃO DO MODELO DE CLASSES DE PROJETO
Vimos no tópico 9 a documentação do modelo de classes de análise. Neste tópico vamos
ver o modelo criado na fase de análise ser transformado no modelo de classes de projeto. As
transformações e os refinamentos nas classes de análise imprimem mais rigor ao diagrama de
classes. Isso pode acontecer, por exemplo, pela definição dos tipos de atributos, além de novos
conceitos que podem surgir nesta fase e que se fazem necessários no diagrama.
Classes de fronteira servem para captar informações para o sistema e devolvê-las depois
de processadas, ou seja, são responsáveis pela comunicação com o ambiente do sistema. A elas,
portanto, não atribuímos responsabilidades relacionadas à lógica de negócio.
As classes de controle referem-se aos objetos da aplicação, e não do domínio do sistema,
e sua função é a de coordenar a interação entre os objetos. Podem ser mais bem observadas
nos diagramas de sequência (porém, não é necessário que elas apareçam nesses diagramas).
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
217
Normalmente são canais de comunicação entre os objetos das classes de fronteira e os objetos
das classes de entidade.
E, finalmente, temos as classes de entidade, nosso maior objetivo na obtenção do modelo
de classes de projeto. Elas representam os conceitos do domínio do sistema, representando as
informações que o sistema deve manipular e armazenar. São as classes do negócio. No momento das transformações, as classes de entidade normalmente permanecem, pois quase sempre
geram objetos que devem ser persistentes.
Este modelo está diretamente relacionado com o modelo de implementação. Portanto,
deve definir os atributos, operações e os parâmetros que serão utilizados na implementação.
Veja, no tópico 14, como adicionar atributos e operações nas classes.
13. DOCUMENTAÇÃO DO MODELO DE ATIVIDADES
Estudamos que o Diagrama de Atividades é um tipo especial de Diagrama de Estados. Ele
representa os estados de uma atividade. Os procedimentos que ocorrem quando um Caso de
Uso é realizado são divididos em atividades, e podem ser representados por um diagrama de
atividades. Este diagrama auxilia na compreensão do comportamento do sistema no decorrer
dos Casos de Uso.
Como o processo de matrícula é o mais importante no Sistema de Controle de Alunos de
uma Universidade, apresentamos o diagrama de atividades que o representa. Veja, no Tópico
14, o passo a passo para a construção deste diagrama.
Figura 5 Diagrama de Atividades – Matricular Aluno.
218
© Análise e Projeto de Sistemas
14. TUTORIAL – ASTAH COMMUNITY
Este tópico apresenta um tutorial sobre o software Astah Community. Vamos apresentar,
passo a passo, como você pode obtê-lo e como fazer para desenhar cada diagrama que utilizaremos no Sistema de Controle de Alunos de uma Universidade.
Acessando o Software Astah Community
No browser instalado em seu computador, digite o seguinte endereço: <http://astah.change-vision.com/en/product/astah-community.html>.
Surgirá a seguinte tela:
Figura 6 Tela de acesso ao software Astah Community.
Como você pode observar, há uma opção para você fazer o download da ferramenta (conforme destacado em vermelho), gratuitamente. Você deve clicar nessa opção e o software será
"baixado" em sua máquina.
Depois da instalação, você deve acessá-lo para iniciar seus trabalhos com a ferramenta.
Iniciando a utilização da ferramenta Astah Community
Abra a ferramenta, clicando sobre o ícone que apareceu em sua tela após a instalação, e
que permite que você inicie o uso da ferramenta:
Figura 7 Ícone para iniciar o uso do Astah
Community.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
219
Surge a seguinte tela:
Figura 8 Tela de abertura da ferramenta Astah Community.
Na barra de menus, clique sobre a opção File/New, ou então no botão Create a new file
(primeira opção à esquerda na barra de ferramentas). Surge a seguinte tela:
Figura 9 Tela de um novo projeto da ferramenta Astah Community.
220
© Análise e Projeto de Sistemas
Antes de iniciar os diagramas, você pode salvar o projeto em uma pasta na sua mídia.
Para isso, clique sobre o menu File/Save As.
Figura 10 Tela de um novo projeto da ferramenta Astah Community.
Depois, escolha o local onde vai gravar o projeto. Dê um nome a ele e pressione o botão
Save. Veja nossa sugestão:
Figura 11 Nomeando um novo projeto criado na ferramenta Astah Community.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
221
Observe, do lado esquerdo, assim também como na barra de títulos, que aparece agora o
nome do novo projeto.
Figura 12 Nome do novo projeto.
Diagrama de Casos de Uso
O primeiro diagrama a ser elaborado é o Diagrama de Casos de Uso. Na barra de menus,
selecione a opção Diagram/UseCase Diagram. Observe o menu com todos os nomes dos diagramas que podem ser elaborados com a ferramenta.
Figura 13 Menu com os nomes dos diagramas da UML.
222
© Análise e Projeto de Sistemas
Observe, na Figura 13, a área de trabalho na qual será desenhado o Diagrama de Casos de
Uso. Ela apresenta uma barra de ferramentas com todos os botões que representam os componentes deste diagrama. Vamos começar desenhando os atores que interagem diretamente com
o sistema.
De acordo com os Casos de Uso identificados, os seguintes atores vão interagir diretamente com o sistema:
a) Secretaria Acadêmica.
b) Coordenador.
c) Professor.
d) Aluno.
Para desenhar um ator, selecione o botão Actor na barra de ferramentas. Posicione o mouse na área de trabalho e clique sobre ela. Aparece o ícone com a representação do ator e o nome
sugerido para ele: Actor1. Se você quiser que este nome permaneça para este ator, o próximo
ator terá o mesmo nome na sequência 2, 3, e assim por diante. Normalmente, queremos que o
nome nos remeta à figura do ator, conforme ele aparece no sistema.
Portanto, mudaremos o nome dos atores do nosso diagrama. Para isso, basta você digitar
o novo nome, enquanto está no modo de edição (em azul). Caso ele tenha saído do modo de
edição, basta dar um clique duplo em cima do nome, que ele entra em modo de edição novamente. Ou, ainda, observe o lado esquerdo inferior na sua tela. Há um campo chamado Name.
Troque o nome do ator, sugerido pela ferramenta, para o nome desejado.
Assim desenharemos os quatro atores, e renomearemos todos eles. Veja como fica:
Figura 14 Atores do Sistema de Controle de Alunos de uma Universidade.
Observe que você pode ir desenhando e, a qualquer momento, mover os ícones de um
lugar para outro, com facilidade. Basta clicar sobre ele a arrastar para o local desejado.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
223
O próximo passo é desenhar os Casos de Uso. Para isso, selecione o botão UseCase. Proceda da mesma forma para nomear os Casos de Uso. Façamos um desenho para cada caso de
uso identificado para o sistema.
Você deve se observar que, embora tenhamos identificado vinte Casos de Uso, foram descritos
apenas os mais importantes. Porém, todos eles devem aparecer no diagrama de Casos de Uso.
São eles:
a) Cadastrar Turmas (Secretaria Acadêmica).
b) Abrir Turma (Coordenador).
c) Fechar Turma (Coordenador).
d) Inserir Informações sobre Aluno (Secretaria Acadêmica).
e) Pesquisar Informações sobre Aluno (Secretaria Acadêmica).
f) Atualizar Informações sobre Aluno (Secretaria Acadêmica).
g) Pesquisar Informações sobre Professor (Secretaria Acadêmica).
h) Pesquisar Informações sobre Coordenador (Secretaria Acadêmica).
i) Manter Informações sobre Disciplina (Secretaria Acadêmica).
j) Manter Informações sobre a Grade Curricular de Curso (Coordenador).
k) Manter Informações sobre Plano de Ensino (Professor).
l) Manter Informações sobre Plano de Aulas (Professor).
m) Manter Informações sobre Sala/Laboratório (Secretaria Acadêmica).
n) Matricular Aluno (Aluno).
o) Cancelar Matrícula (Aluno).
p) Trancar Matrícula (Aluno).
q) Lançar Notas e Faltas (Professor).
r) Visualizar Boletim (Aluno).
s) Visualizar Andamento das Matrículas (Coordenador).
t) Atender Lista de Espera (Coordenador).
Depois de desenhar os Casos de Uso, você deve associá-los aos atores que interagem diretamente com eles. A Figura 15 mostra parte do diagrama de Casos de Uso. Entretanto, você
pode vê-lo na íntegra, na Figura 1.
Figura 15 Tela com parte do Diagrama de Casos de Uso.
224
© Análise e Projeto de Sistemas
Diagrama de Classes
Dando continuidade ao projeto do Sistema de Controle de Alunos de uma Universidade,
vamos agora à fase da construção do modelo inicial de classes, ou seja, o modelo conceitual.
Selecione o menu Diagram/Class Diagram. Surge a seguinte tela:
Figura 16 Tela de abertura do Diagrama de Classes.
Começamos com o desenho da classe. Para isso, selecione o botão Class na barra de ferramentas. Clique sobre a área de trabalho. Surge o ícone que representa uma classe. É recomendável que o nome sugerido seja trocado por um que represente a classe desejada. Veja na
próxima figura.
Figura 17 Representação de uma classe.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
225
Desenhe todas as classes identificadas. O próximo passo é desenhar as conexões entre
elas. Observe, nos botões da barra de ferramentas, que existe um botão que representa uma
associação simples. Ao lado desse botão existe uma seta. Se você clicar nela, aparecerão os
demais botões relacionados aos outros tipos de associação (agregação e composição). Veja na
próxima figura.
2
5
3
4
1
Figura 18 Botões de relacionamentos.
1
Associações por agregação e composição.
2
Associação.
3
Generalização.
4
Dependência.
Note, também, que outro elemento utilizado foi a classe de associação. Para representá-la
você deve utilizar o botão indicado pelo número 5, conforme mostra a figura anterior.
5
Classe de associação.
Depois que as classes e seus relacionamentos estão representados, é necessário acrescentar as multiplicidades e os nomes dos relacionamentos. Para isso, posicione o mouse sobre a
linha que representa o relacionamento e clique com o botão direito.
Figura 19 Adicionando multiplicidades e nome aos relacionamentos.
226
© Análise e Projeto de Sistemas
Conforme mostra a Figura 19, aparece um menu. Para adicionar multiplicidades, basta
você posicionar o mouse em Multiplicity, e depois escolher uma das opções de multiplicidade
oferecidas. Para adicionar um nome ao relacionamento, posicione o mouse na primeira opção
do menu, Set Name, clique e escreva o nome que queira atribuir a ele.
Diagrama de Sequência
A próxima etapa consiste na elaboração dos diagramas de sequência. Vejamos a construção para o diagrama que corresponde ao fluxo principal do caso de uso Matricular Aluno.
Na barra de menus, selecione o menu Diagram/Sequence Diagram. Surgirá a seguinte tela:
Figura 20 Tela para construir o diagrama de sequência.
O próximo passo consiste em desenhar todas as classes envolvidas no processo. Para isso,
selecione o botão Lifeline. Elas devem ficar dispostas lado a lado, conforme mostra a Figura 21.
Observe qual é o ator que interage diretamente com o caso de uso. Neste caso, o ator é o
Aluno. Para representá-lo, selecione a seta ao lado do botão Lifeline. Escolha, agora, o ícone que
representa o ator, Lifeline(Actor).
Entre o ator e as classes, vamos inserir uma classe de fronteira, pela qual o ator insere as
informações ao sistema, e este devolve as mensagens. Para isso, utilize a mesma seta e escolha
o ícone Lifeline(Boundary). Como sugestão, a classe de fronteira pode ter seu nome iniciado pela
letra “I”, para indicar que se trata de uma classe de interface.
Para iniciar os fluxos de mensagens, observe a sequência de passos descrita no fluxo principal do Caso de Uso. A sequência deste fluxo está representada no diagrama. Neste diagrama
foram utilizadas as setas de mensagens síncronas e mensagens de retorno.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
227
Apresentamos o diagrama na ferramenta Astah. Você pode vê-lo na íntegra no Tópico 10.
Figura 21 Tela com visão parcial do diagrama de sequência (Matricular Aluno).
Observe que do lado esquerdo inferior da tela aparece uma guia de nome Base. Há dois
campos: Name, em que você pode nomear o diagrama em questão. Note que há um nome sugerido para ele. O segundo campo é o Argument. Trata-se do argumento que pode ser colocado no
nome do diagrama. Caso exista esse argumento, ele aparecerá dentro dos parênteses no nome
do diagrama.
Há, ainda, uma lista com opções que podem ser assinaladas ou não. Por exemplo, o primeiro campo permite que o número que representa o índice da mensagem enviada por um objeto a outro apareça ou não. No diagrama mostrado na figura anterior, perceba que os números
correspondentes aos índices das mensagens não aparecem. A opção está desabilitada.
Para cada objeto inserido no diagrama, quando você o seleciona, uma lista com as opções
de configuração para esse objeto se abre do lado esquerdo inferior da tela, e você pode alterar
as opções inicialmente sugeridas. A tela de opções para um objeto selecionado apenas é diferente da tela que aparece quando se trata do diagrama todo (explicada anteriormente).
Experimente selecionar uma classe apenas. Veja que aparece uma opção chamada Properties, que são as propriedades para o controle selecionado. Quando você clica nesta opção,
uma janela de propriedades é aberta, com várias guias. Uma atenção especial deve ser dada à
opção Stereotype. Ela permite que você crie um estereótipo para o objeto selecionado.
Adicionando atributos e operações às classes no diagrama de classes
Para refinar o modelo de classes, você deve observar as classes definidas no modelo de
análise. Aquelas que contêm objetos que são persistentes merecem atenção nesta fase. Adicionaremos os atributos e as operações a elas.
228
© Análise e Projeto de Sistemas
Para isso, selecione a classe para a qual deseja inserir os atributos. Observe o lado esquerdo inferior da tela. Veja que aparecem várias guias. Selecione a guia Attribute. Selecione o botão
Add, para adicionar os atributos.
No primeiro campo você deverá colocar o nome do atributo. No segundo campo você
escolherá, a partir de uma lista oferecida, o tipo do atributo. E, no quarto campo, você deverá
preencher a visibilidade. Veja na Figura 22.
Figura 22 Adicionando atributos à classe AlunoCurso.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
229
Depois de inserir os atributos, você deve inserir as operações. Escolha a guia Operation e,
depois, o botão Add. No primeiro campo você deverá escrever o nome da operação. No segundo
campo, deve ser escolhido o tipo de valor que será retornado pela função. E, no quarto campo,
você deve escolher a visibilidade.
Veja como fica o preenchimento:
Figura 23 Adicionando operações à classe AlunoCurso.
230
© Análise e Projeto de Sistemas
Diagrama de Atividades
Para elaborar o diagrama de atividades, na barra de menus escolha a opção Diagram/
Activity Diagram. Surge a seguinte tela:
Figura 24 Tela do diagrama de atividades.
Para iniciar o desenho do diagrama, na barra de ferramentas selecione o botão InitialNode. É o botão que mostra o estado inicial das atividades.
Em seguida, selecione o botão Action, para desenhar a representação de uma atividade.
Para conectar os símbolos do nó inicial com a atividade, selecione o botão ControlFlow/ObjectFlow. A cada nova atividade, repita o procedimento.
Para desenhar o símbolo que representa uma tomada de decisão, selecione o botão Decision Node & Merge Node. A barra de bifurcação é obtida selecionando-se o botão ForkNode, e
a barra de junção é obtida selecionando-se o botão JoinNode.
Centro Universitário Claretiano
© Estudo de Caso: Sistema de Controle de Alunos de Uma Universidade
231
Figura 25 Visão parcial do diagrama de atividades – Matricular Aluno.
15. QUESTÃO AUTOAVALIATIVA
Esta unidade é um pouco diferente das demais, uma vez que ela abrange tudo o que você
estudou sobre análise e projeto orientados a objetos. Contém um exemplo de um sistema em
que cada etapa foi desenvolvida com explicações e o uso de uma ferramenta de modelagem.
1) Para que você faça uma autoavaliação relacionada ao conteúdo da unidade, desenvolva, com base no sistema
utilizado como exemplo, a análise e o projeto de um sistema para controlar o tempo de permanência de um
hóspede em um hotel. O sistema deve abranger desde o momento em que o cliente faz sua reserva (por telefone, por exemplo), até o momento em que ele solicita o encerramento de sua conta. O sistema deve manter as
informações cadastrais e também as informações sobre a permanência do hóspede no hotel (gastos com diárias
e serviços). Não se esqueça de que o cliente pode, também, cancelar sua reserva antes de se hospedar.
16. CONSIDERAÇÕES
Esta unidade apresentou uma visão prática da modelagem de um sistema, por meio de
um estudo de caso sobre um Sistema de Controle de Alunos de uma Universidade, com foco no
processo de matrículas.
Você acompanhou o desenvolvimento dos principais diagramas com o auxílio da ferramenta aberta Astah Community.
232
© Análise e Projeto de Sistemas
Ficam aqui algumas sugestões para melhorar o seu estudo:
• Elaboramos dois diagramas de sequência. Procure construir outros, com base nos diversos cenários dos Casos de Uso descritos.
• Nosso objetivo aqui não é ensinar a implementar. Entretanto, você pode prosseguir
com o projeto arquitetural do software, e implementá-lo, utilizando os conhecimentos
adquiridos em outras disciplinas do seu curso. Para isso, reveja a Unidade 7 e busque
complementar seus estudos utilizando os livros indicados na bibliografia.
Chegamos ao final de mais uma disciplina e com este estudo você teve a oportunidade
de compreender que o desenvolvimento de projetos de sistemas de software não é uma tarefa
simples e, dessa forma, você pôde perceber que analisar e projetar sistemas requer muito conhecimento, bom senso, criatividade, organização e muita prática.
Nesta disciplina você estudou duas abordagens de desenvolvimento de software: a análise essencial e a orientação a objetos. Esta última é uma realidade cada vez mais presente nas
organizações e, caso você siga a trajetória do desenvolvimento, certamente será questionado
sobre essa abordagem.
As fases de análise e projeto de sistemas são as mais importantes dentro do ciclo de vida
de um sistema, pois elas constituem a base para a sua correta implementação. Qualquer erro
cometido aqui é refletido no sistema.
Portanto, certifique-se de ter compreendido bem o conteúdo estudado e exercite-se. Nossa sugestão para você é que pratique ao máximo as tarefas de análise e projeto de sistemas em
tarefas básicas do seu dia a dia.
17. REFERÊNCIAS BIBLIOGRÁFICAS
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007.
BLAHA, M.; RUMBAUGH, J. Modelagem e projetos baseados em objetos com UML 2. 2. ed. Rio de Janeiro: Elsevier, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. 3. reimpr. Rio de Janeiro: Elsevier, 2004.
Centro Universitário Claretiano