Você está na página 1de 25

CENTRO DE TECNOLOGIA

Engenharia de Computao
Engenharia de Software

Projeto AdmSchool

Autora:
Marilene Oliveira Lima

julho, 2016
Contedo
1 Sumrio Executivo 4
1.1 Viso geral e escopo do projeto . . . . . . . . . . . . . . . . . . . 4
1.1.1 Restries . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Critrios preliminares de aceitao . . . . . . . . . . . . . 4
1.2 Estudos preliminares sobre o domnio do negcio . . . . . . . . . 4
1.2.1 Atores Externos . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Atores Internos . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Caso de uso de negcio e delimitao do escopo . . . . . . . . . . 4
1.4 Fluxos dos processos a serem automatizados . . . . . . . . . . . . 5
1.4.1 Matricular . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Entregar boletim . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Pagar despesas . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.4 Lanar notas . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.5 Lanar frequncias . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Transio de estados de objetos destacados para o domnio . . . 9

2 Modelo funcional 10
2.1 Identicao dos atores . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Descrio dos casos de uso . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Casos de uso expandido . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1 Caso de uso matricular aluno . . . . . . . . . . . . . . . . 11
2.4.2 Caso de uso lancar notas . . . . . . . . . . . . . . . . . . 12
2.5 Casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1 Caso de uso matricular aluno . . . . . . . . . . . . . . . . 12
2.5.2 Caso de uso lancar notas . . . . . . . . . . . . . . . . . . 13
2.6 Requisitos No Funcionais . . . . . . . . . . . . . . . . . . . . . . 13
2.6.1 Conrmao da senha . . . . . . . . . . . . . . . . . . . . 13
2.6.2 Alocao de turma obrigatria . . . . . . . . . . . . . . . 13
2.7 Requisitos Suplementares . . . . . . . . . . . . . . . . . . . . . . 14
2.7.1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.2 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.3 Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . 14
2.7.4 Suportabilidade . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Modelos esttico 15
3.1 Diagrama de classes . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Matricular aluno . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Editar notas . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Editar frequncias . . . . . . . . . . . . . . . . . . . . . . 16
3.1.4 Consultar boletim . . . . . . . . . . . . . . . . . . . . . . 16
3.1.5 Lanar notas . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.6 Lanar frequncias . . . . . . . . . . . . . . . . . . . . . . 17
3.1.7 Pagar despesas . . . . . . . . . . . . . . . . . . . . . . . . 18

2
4 Modelo dinmico 19
4.1 Diagramas de sequncia . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Matricular aluno . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Editar notas . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3 Editar frequncias . . . . . . . . . . . . . . . . . . . . . . 20
4.1.4 Consultar boletim . . . . . . . . . . . . . . . . . . . . . . 21
4.1.5 Lanar notas . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.6 Lanar frequncias . . . . . . . . . . . . . . . . . . . . . . 23

5 Arquitetura 24
5.1 Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Diagrama de distribuio . . . . . . . . . . . . . . . . . . . . . . 25

3
1 Sumrio Executivo
1.1 Viso geral e escopo do projeto
O sistema AdmSchool uma ferramenta voltada para escolas. Esta ferra-
menta prope a digitalizao das informaes administrativas. Com a implanta-
o do sistema na rotina escolar possvel ter acesso a informaes do cadastro
pessoal do aluno/responsvel, pagamentos, notas e frequncia por meio deste
portal, substituindo o arquivo das informaes em papel. Assim, o sistema agi-
liza o acesso as informaes, diminui o uso de papel e economiza espao fsico
de armazenamento de arquivos.

1.1.1 Restries
O acesso ao sistema deve ser feito exclusivamente pela web.

1.1.2 Critrios preliminares de aceitao


O sistema deve aceitar at mil acessos simultneos para consulta sem
degradao do desempenho, devendo o tempo de resposta ser igual ou
inferior a 2s por operao.

O sistema deve armazenar informaes de pelo menos 3000 alunos.

1.2 Estudos preliminares sobre o domnio do negcio


1.2.1 Atores Externos
Responsvel

1.2.2 Atores Internos


Secretario(a)

Professor(a)

Tesoureiro(a)

1.3 Caso de uso de negcio e delimitao do escopo

4
Figura 1: Caso de uso de negcio

1.4 Fluxos dos processos a serem automatizados

1.4.1 Matricular

5
1.4.2 Entregar boletim

6
1.4.3 Pagar despesas

7
1.4.4 Lanar notas

8
1.4.5 Lanar frequncias

1.5 Transio de estados de objetos destacados para o do-


mnio

9
2 Modelo funcional
2.1 Identicao dos atores
Responsvel: Pessoa que se responsabiliza legalmente pela matrcula do
aluno.

Secretrio(a): Funcionrio responsvel pelas rotinas administrativas.

Professor(a): Funcionrio responsvel por lecionar.

Tesoureiro(a): Funcionrio responsvel pelo controle do nanceiro da es-


cola.

2.2 Descrio dos casos de uso

Tabela 1: Descrio e ordem de priopridade dos casos de uso


Caso de Uso Descrio Prioridade
Matricular aluno O responsvel entrar em interao com o(a) secretrio(a) e so- Alta
licitar matrcula. Neste momento o responsvel deve estar com
todos os documentos exigidos pela escola, para serem validados e
inseridos no sistema.
Consultar boletim O responsvel poder visualizar o boletim dos alunos dependentes Baixa
dele.
Lanar notas O professor poder lanar as notas dos alunos das turmas que ele Alta
leciona.
Lanar frequncias O professor poder lanar as frequncias dos alunos das turmas Alta
que ele leciona.
Editar notas O secretrio poder editar as notas dos alunos de todas as turmas. Mdia
Editar frequncias O secretrio poder editar as frequncias dos alunos de todas as Mdia
turmas.
Pagar despesas O responsvel poder pagar despesas online ou pessoalmente dos Baixa
alunos dependentes dele.

10
2.3 Diagramas de casos de uso

2.4 Casos de uso expandido


2.4.1 Caso de uso matricular aluno
Nome do caso de uso: Matricular aluno
Atores participantes: Inicializado por Secretrio
Fluxo de eventos:

1. O secretrio ativa a funo Nova Matrcula do seu terminal.

2. O AdmSchool apresenta um formulrio ao secretrio com as informaes


do aluno e do responsvel para serem preenchidas.

3. O secretrio completa o formulrio e submete o formulrio

4. O AdmSchool solicita arquivos digitalizados de documento comprovante


de residncia e de documentos ociais de identicao do responsvel e do
aluno.

5. O secretrio seleciona os documentos e os submete ao AdmSchool.

6. O AdmSchool conrma a submisso da nova matrcula pela senha da conta


so secretrio.

7. O secretrio digita sua senha.

8. O AdmSchool conrma que a nova matrcula foi submetida.

Condio de entrada: O secretrio deve estar logado no AdmSchool

11
Condies de sada: O secretrio deve ter concludo a submisso da nova ma-
trcula ou o secretrio deve cancelar a submisso da nova matrcula.

2.4.2 Caso de uso lancar notas


Nome do caso de uso: Lanar notas
Atores participantes: Inicializado por Professor
Fluxo de eventos:

1. O professor deve ativar a funo Lanar notas no seu terminal de traba-


lho.

2. O AdmSchool exibe as turmas que o professor leciona.

3. O professor seleciona uma turma.

4. O AdmSchool apresenta um formulrio com a quantidade de notas de


atividades a serem cadastradas, o bimestre da(s) atividade(s), o ttulo
da atividade, espao para anotaes sobre a atividade e peso da nota da
atividade na composio da nota nal.

5. O professor conclui o formulrio

6. O AdmSchool apresenta um formulrio com o nome e matrcula dos alunos


e espao para o preenchimento das notas a serem cadastradas.

7. O professor conclui o formulrio.

8. O AdmSchool solicita conrmao da submisso das notas pela senha do


login do usurio.

9. O professor digita a senha da sua conta.

10. O AdmSchool conrma o sucesso da submisso.

Condio de entrada: O professor deve estar logado no AdmSchool e lecionar


como professor titular em pelo menos uma turma.

Condies de sada: O professor conclui com sucesso a submisso das notas


ou o professor cancela a submisso ou o professor erra 3 vezes a senha da conta
na conrmao da submisso.

2.5 Casos de teste


2.5.1 Caso de uso matricular aluno
A seguir o caso de teste para o caso de uso citado:

12
Tabela 2: Caso de teste para o caso de uso matricular aluno
Resumo Ser feita a matrcula de um aluno ctcio para fazer a validao
do caso de uso matricular aluno
Pr-condio O secretrio deve estar logando
Entradas O secretrio deve ativar no seu terminal a funo matricular aluno
1. Ativar a funo matricular
2. Preencher os dados do responsvel.
Aes
3. Preencher os dados do aluno e aloc-lo em uma turma.
4. submeter matrcula.
1. O aluno deve aparecer na lista de alunos da turma que foi selecionada.
Resultados esperados 2.Caso o secretrio no o aloque em nenhuma turma a submisso da
matrcula no pode ser concluda.
Ps-condies O aluno deve estar cadastrado no banco de dados de alunos do
colgio, sendo possvel atribuir notas e frequncia ao aluno.

2.5.2 Caso de uso lancar notas


A seguir o caso de teste para o caso de uso citado:

Tabela 3: Caso de teste para caso de uso lanar notas


Resumo Ser lanada as notas de uma disciplina de uma turma ctcia
para fazer a validao do caso de uso lanar notas
Pr-condio O professor deve estar logando
Entradas O profesor deve selecionar uma disciplina que ele professor titu-
lar
1. Ativar a funo lanar notas
Aes 2. Preencher os campos de notas dos alunos desejados.
3. Submeter notas.
1. O secretrio e o professor devem conseguir visualizar as notas dos alunos.
Resultados esperados
2.O secretrio deve conseguir editar as notas lanadas.
Ps-condies As notas devem constar no banco de dados do sistema e deve ser
possvel ser acessada pelo professor, secretrio e responsvel,

2.6 Requisitos No Funcionais


2.6.1 Conrmao da senha
Nos casos de uso lanar notas e lanar frequncias o professor deve au-
tenticar sua senha para validar a conrmao da submisso dos dados.

Nos casos de usoedio de notas, edio de frequncia e matricular aluno


o secretrio deve autenticar a sua senha para validar a conrmao da
submisso das alteraes ou incluses de dados no sistema.

2.6.2 Alocao de turma obrigatria


No caso de uso matricular o sistema no pode permitir que o secretrio
matricule um aluno na escola sem aloc-lo em uma turma.

13
2.7 Requisitos Suplementares
2.7.1 Usabilidade
O tempo de aprendizagem mdio do usurio sistema deve ser igual ou
inferior a 10 minutos. Neste tempo o usurio deve ser capaz executar
todas as funcionalidades bsicas.

O sistema deve ter desing responsivo, ou seja, deve se adaptar a diferentes


dispositivos e resolues mantendo suas funcionalidades acessveis.

2.7.2 Desempenho
O tempo de resposta do sistema para qualquer operao deve ser igual ou
inferior a 5 segundos.

2.7.3 Dependabilidade
Os responsveis no podero ter acesso a nenhuma informao de outros
alunos alm dos que so seus dependentes.

Os professores s devem conseguir lanar notas de disciplinas que eles


sejam professor titular cadastrado.

2.7.4 Suportabilidade
O sistema deve suportar acesso multi-usurio.

O sistema deve suportar at 1000 acessos simultneos sem perder desem-


penho.

14
3 Modelos esttico
3.1 Diagrama de classes
A seguir os diagramas de classes referente a cada caso de uso do projeto com
os atributos mais relevantes para o entendimento do funcionamento do sistema:

3.1.1 Matricular aluno

3.1.2 Editar notas

15
3.1.3 Editar frequncias

3.1.4 Consultar boletim

16
3.1.5 Lanar notas

3.1.6 Lanar frequncias

17
3.1.7 Pagar despesas

18
4 Modelo dinmico
4.1 Diagramas de sequncia
4.1.1 Matricular aluno

19
4.1.2 Editar notas

4.1.3 Editar frequncias

20
4.1.4 Consultar boletim

21
4.1.5 Lanar notas

22
4.1.6 Lanar frequncias

23
5 Arquitetura
5.1 Diagrama de componentes
Estilo de decomposio escolhido: Decomposio por particionamento. Este
estilo foi escolhido devido a complexidade do projeto de associar hierarquica-
mente os componentes do sistema devido a forte independencia na relao de
algumas partes do sistema. Isto ocorreu devido a principal funo do sistema
ser digitalizar informaes e naturalmente no h muita interao nos setores
envolvidos.

24
5.2 Diagrama de distribuio

25

Você também pode gostar