Modelo Projeto Design de Software

Prévia do material em texto

1
2
NOME DO ALUNO
TÍTULO DO PROJETO
3
Documento apresentado ao Curso de
graduação de Bacharelado em Engenharia de
Software, ou Bacharelado em Sistemas de
Informação, ou Bacharelado em Ciência da
Computação, ou Gestão da Tecnologia da
Informação ou Análise e Desenvolvimento de
Sistemas da Universidade Católica de Brasília,
como requisito parcial para obtenção da
aprovação na disciplina de Design de
Software.
Orientador: Prof. Dr. Milton Pombo da Paz
Brasília
2021
SUMÁRIO
1 INTRODUÇÃO 5
1.1 USUÁRIOS DO PROJETO 5
2 OBJETIVOS 6
2.1 OBJETIVO GERAL 6
2.2 OBJETIVOS ESPECÍFICOS 6
3 ANÁLISE DE NEGÓCIO 7
3.1 REGRAS DE NEGÓCIO 7
4 ANÁLISE DE SISTEMAS 8
4.1 DESCRIÇÃO DAS CARACTERÍSTICAS DO SISTEMA 8
5 ANÁLISE DE REQUISITOS 9
4
5.1 REQUISITOS FUNCIONAIS 9
5.2 REQUISITOS NÃO-FUNCIONAIS 9
5.3 DIAGRAMA DE CASOS DE USO DA SOLUÇÃO 9
5.3.1 Descrição dos Cenários de Casos de Uso 9
6 DOCUMENTAÇÃO DE PROJETO 14
6.1 ARQUITETURA DE SOFTWARE 14
6.1.1 PADRÕES DE PROJETO 14
6.2 DIAGRAMAS DA UML 14
6.2.1 DIAGRAMA DE CLASSE 14
6.2.2 DIAGRAMA DE COMPONENTES 15
6.2.3 DIAGRAMA DE IMPLANTAÇÃO 15
6.2.4 DIAGRAMA DE ATIVIDADES 16
6.2.5 DIAGRAMA DE SEQUÊNCIA 16
6.2.6 DIAGRAMA DE CASOS DE USO 16
6.2.7 DIAGRAMA DE MÁQUINA DE ESTADO OU TRANSIÇÃO DE ESTADO 17
7 MODELAGEM DO BANCO DE DADOS 18
7.1 MODELO CONCEITUAL DE DADOS (MODELO ENTIDADE RELACIONAMENTO) 18
7.2 MODELO FÍSICO DE DADOS 19
7.3 SCHEMA DO BANCO DE DADOS (SCRIPT) 19
7.4 DICIONÁRIO DE DADOS 19
8 CONCLUSÃO 22
8.1 TRABALHOS FUTUROS 22
REFERÊNCIAS 23
5
1 INTRODUÇÃO
A computação e a TI é grande aliada de todas as áreas e organizações, os sistemas
simplificam e reduzem o trabalho dentro das burocracias que antes eram feitas a mão.
Neste trabalho podemos utilizar essa aliança ainda mais presente, no ramo da arquitetura
são gerados diversos relatórios e é sempre necessária a comunicação com o cliente em todas
as fases do projeto.
O trabalho consiste em sistematizar essa comunicação, evitando assim os encontros
presenciais e a ocupação na agenda telefônica dos arquitetos, ajuda também a deixar as
plantas sempre digitalizadas garantindo assim um simples acesso de ambas as partes em
qualquer lugar.
O projeto consiste em gerar a documentação do sistema, elaborar todos os seus diagramas
e encontrar todos os requisitos e informações do sistema, facilitando assim o trabalho dos
programadores.
1.1 USUÁRIOS DO PROJETO
Os usuários do sistema são arquitetos e sua clientela.
6
2 OBJETIVOS
Os objetivos são:
● Sistematizar a parte burocrática (emissão de relatórios e emissão de boletos).
● Limitar a comunicação, deixando os telefones livres para emergências.
● Geração simples de contratos.
2.1 OBJETIVO GERAL
O objetivo geral como já foi dito é facilitar o trabalho de arquitetos durante a criação e
execução de plantas e projetos.
2.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos consistem na construção de um chat personalizado e de uma
aba especial limitada a arquitetos para armazenamento de todas as plantas, separadas por data
de contratação.
3 ANÁLISE DE NEGÓCIO
Neste capítulo será descrito, através de diagramas e especificações, o processo do
negócio em que o software em questão será inserido, sendo estes o diagrama do modelo de
caso de uso de negócio, diagrama do modelo de classes do negócio, e, por fim, o diagrama de
atividades.
3.1 DIAGRAMA DE CASOS DE USO DE NEGÓCIO
O diagrama de casos de uso de negócio demonstra as principais funções que são
executadas por cada ator dentro do processo de desenvolvimento de software, sendo que o
diagrama abaixo foi desenvolvido baseado no processo unificado (RUP). Neste diagrama são
representadas as principais atividades desenvolvidas dentro de uma iteração do RUP, sendo
que o software resultado deste trabalho será baseado, especificamente, na etapa de
codificação.
A Figura 2 apresenta o Diagrama de Casos de Uso de Negócio com a visão de cada
ator do sistema, cliente, arquiteto, secretário e financeiro..
7
Figura 3.2 DIAGRAMAS DE CLASSE DO NEGÓCIO (MODELO DE DOMÍNIO)2 -
Diagrama de Caso de Uso de Negócio.
Fonte: Elaborado pelo autor.
A Figura 3 apresenta o Diagrama de Classe de Negócio, com a visão de cada ator do
sistema, cliente, arquiteto, secretário e financeiro.
Figura 3 - Diagrama de classe do Negócio
Fonte: Elaborado pelo autor.
8
3.3 DIAGRAMAS DE INTERAÇÃO DE OBJETOS DO NEGÓCIO
O Diagrama de Interação neste tópico, conforme Figura 4 mostra para cada cenário
descrito em um caso de uso, as interações entre os atores e as classes envolvidas.
Diagrama de sequência, UC01 - Controlar Gastos
Figura 4 - Diagrama de Sequência, UC01 - Cadastrar usuário.
Fonte: Elaborado pelo autor.
9
3.4 DIAGRAMA DE ATIVIDADES
O diagrama a seguir, conforme Figura 5, mostra o fluxo das atividades realizadas no
negócio do cliente.
3.5 REGRAS DE NEGÓCIO
São as regras que fazem o negócio existir.
Número Nome Descrição Setor
RN1 Preenchimento
Obrigatório
Nenhum dos campos de cadastro podem
estar em branco.
Gestão
RN2 Inclusão
de Relatórios
Apenas Arquitetos podem digitalizar e
salvar no sistema os relatórios de obra.
Gestão
RN3 Acesso
aos Relatórios
Arquitetos podem ter acesso a todos os
relatórios enviados e podem alterá-los,
clientes podem apenas visualizar os
relatórios gerados referentes a seu
projeto.
Segurança
RN4 Inclusão de Plantas Apenas Arquitetos e Secretários
pré-autorizados podem digitalizar e
salvar no sistema as plantas de obra.
Gestão
RN5 Acesso às plantas Arquitetos podem ter acesso a todas as
plantas cadastradas no sistema, mas
clientes só podem ter acesso a planta do
seu respectivo projeto.
Segurança
RN6 Acesso ao Histórico
de pagamento
Apenas pessoas do financeiro podem ter
acesso a relação de boletos pagos.
Financeiro
10
4 ANÁLISE DE SISTEMAS
Neste capítulo serão descritos os problemas que aplicação irá solucionar e as
funcionalidades que o software deverá atender.
4.1 DESCRIÇÃO DAS CARACTERÍSTICAS DO SISTEMA
O sistema a ser desenvolvido deverá conter diversas características para que as
necessidades de seus usuários sejam solucionadas. Dentre as principais características que o
software deverá atender estão: a facilidade de manipulação da aplicação (interface gráfica),
agilidade no processo de geração sendo que a aplicação irá disponibilizar uma geração padrão
ou uma geração customizada, abstração do processo de codificação de software, ou seja, o
usuário não precisará ter conhecimento avançados em codificação tendo apenas conhecimento
da estrutura de dados e das principais regras de negócio.
Outra característica que cerca o produto final do gerador de código é que seu resultado
seja uma aplicação funcional (CRUD) com as tabelas de domínio para que possa solucionar a
necessidade de demonstração de um produto funcional para o cliente, trazendo confiabilidade
e segurança para o mesmo.
O sistema deve gerar uma aba de chat, para que todas as dúvidas relacionadas ao
projeto sejam respondidas por lá liberando assim as ligações para de fato emergências.
Outra função do sistema é ter uma aba limitada aos arquitetos onde ficarão salvas todas
as plantas digitalizadas seguindo uma ordem de data de fechamento de contrato.
Também é necessário que o sistema tenha uma aba para o cliente conseguir baixar os
boletos e relatórios, os boletos serão encaminhados para um link onde serão gerados
corretamente e os relatórios serão postados pela staff todos os dias, informando
detalhadamente o status da obra e o prazo restante para entrega do projeto.
11
5 ANÁLISE DE REQUISITOS
Neste capítulo será detalhado todos os requisitos e funções do sistema.
5.1 REQUISITOS FUNCIONAIS
São os requisitos da solução sistêmica.
Número Requisitos Funcionais RN
RF1 Realizar Login Realizar login no sistema,
diferenciando assim os diferentes
usuários
RF2 Cadastrar usuário Realizar cadastro de usuários.
RF3 Acessar Boleto Acessar os boletos pendentes para
pagamento.
RF4 Acessar relatórios Abrir uma aba onde estarão
organizados por data os relatóriosda
obra.
RF5 Enviar relatório Função staff onde deve ser enviado
para a página do cliente o relatório
diário para o cliente.
RF6 Enviar planta Função staff onde deve ser enviada
para a página do cliente a planta do
projeto.
RF7 Chat Chat de comunicação entre clientes e
staff.
RF8 Visualizar Status projeto Uma informação alterada diariamente
informando o status do projeto.
RF9 Consultar planta Função do cliente, consiste em
consultar a planta do projeto.
RF10 Enviar boletos Função do financeiro, onde libera
para os clientes os boletos para
pagamento.
RF11 Acessar informações do cliente Função staff para consultar os dados
do cliente.
RF12 Atualizar status do projeto Função staff para atualizar com a fase
do projeto em ação e o tempo em dias
restante para a conclusão.
RF13 Gerar relatório financeiro Função do financeiro, gerar os
relatórios financeiros mensais.
RF14 Acessar relatórios financeiros Disponível apenas para o arquiteto,
visualizar os relatórios financeiros
mensais.
12
5.2 REQUISITOS NÃO-FUNCIONAIS
São os requisitos não-funcionais da solução sistêmica.
Número Requisitos Não-Funcionais
RNF1 O sistema deve ter uma interface interativa com o usuário.
RNF2 O sistema deve ser de fácil acesso.
RNF3 O sistema deve ter duas interfaces, uma para staff outra para clientes.
RNF4 O sistema deve ter versão IOS, Android e Desktop.
RNF5 O sistema deve utilizar o SQL como banco de dados.
RNF6 O sistema deve ser desenvolvido em Java.
RNF7 Realizar autenticação de Login e Senha.
RNF8 O sistema deve expirar sessão em 5 minutos de inatividade.
5.3 DIAGRAMA DE CASOS DE USO DA SOLUÇÃO
Nesta seção serão definidos os modelos de casos de uso. Primeiramente será mostrada
uma visão geral dos casos de uso que definem as funcionalidades do sistema, com seus
respectivos atores. Posteriormente será feita a descrição de cada caso de uso que deverá ser
implementado no sistema.
Figura 5 - Diagrama de Casos de Uso de Software.
Fonte: Elaborado pelo autor.
13
5.3.1 Descrição dos Cenários de Casos de Uso
Nesta seção serão descritos todos os casos de uso apresentados no diagrama de caso
uso de software. Esta descrição irá conter o nome do caso de uso, objetivo, atores,
pré-condições, fluxo principal, fluxos alternativos, fluxos de exceção, pós-condições e
características suplementares.
5.3.1.1 Descrição do caso de uso UC01 – Efetuar Login
A descrição detalhada do caso de uso é responsável por apresentar os fluxos principal,
alternativos e de exceção do caso de uso em questão, além de apresentar as pré-condições e
pós-condições que existem antes e após a execução do mesmo, respectivamente.
Histórico de Revisão
Nome Data Razão da mudança Versão
João
João
João
28/10/2020 Criação do documento
Revisão do documento
Ajustes no fluxo principal
1.0
1.1
1.2
ID do Caso de Uso: UC-01
Nome do Caso de
Uso:
Efetuar Login
Criado por: João Última
atualização:
Data da Criação: 28/09/2010 Data da última
atualização:
Ator: Arquiteto, Cliente, Secretário.
Descrição Permitir ao(s) ator(es) do sistema realizar qualquer procedimento
disponível para o seu perfil, após ser autenticado.
Pré-condições O usuário deverá estar cadastrado no banco de dados do sistema.
Pós-condições Usuário Logado
Prioridade Alta
Frequência de Uso Alta
Fluxo Principal P1. O caso de uso se inicia quando o usuário acessa o sistema por
meio da internet.
P2. O sistema disponibiliza uma tela com dois campos para serem
preenchidos com o usuário e a senha do ator. [E2].
P3. O ator preenche os campos disponibilizados na tela e
seleciona o botão de entrar no sistema [A1] [A2].
14
P4. O sistema procura o usuário na base de dados e, caso exista,
verifica se a senha informada é a mesma senha do usuário
encontrado [E1].
P5. O sistema autentica o usuário. [E2]
P6. O caso de uso se encerra.
Fluxo Alternativo A1. O ator seleciona a opção “Recuperar senha”
A1.1 O sistema redireciona o ator para uma nova tela de
recuperação de senha.
A1.2 O ator digita o seu e-mail e clica no botão “Obter nova senha
por e-mail.
A1.3 O sistema verifica existência do e-mail na base de dados
[E1].
A1.4 O sistema emite uma nova senha por e-mail, e retorna para a
tela de login .
A1.5 O sistema retorna para o passo P3.
A2 Sair
A2.1 O usuário fecha a tela do browser.
A2.3 Segue para o passo P6.
Exceções E1. O sistema não encontra nenhum usuário com os dados
informados.
E1.1 O sistema informa uma mensagem de erro(M001).
E1.2 Segue para o passo A1.1.
E2 O sistema não consegue redirecionar o ator para a tela
desejada.
E2.1 O sistema informa uma mensagem de erro(M004).
E2.2 Segue para o passo P6.
E3. O sistema não encontra o e-mail no banco de dados.
E3.1 O sistema informa uma mensagem de erro(M002).
E3.2 Segue para o passo A1.2.
Requerimentos
Especiais
Usuário deve ter privilégios de acesso a essas funções específicas
Suposições
Notas e casos As mensagens estão especificadas na Tabela Mensagens do
Sistema (anexo 01).
Anexo 01 – Mensagens do Sistema
Código da
mensagem
Mensagem
M001 “Usuário ou senha digitados está invalido! Tente novamente”
M002 “E-mail informado invalido, verifique a digitação do seu e-mail”
M003 “Erro ao redirecionar a página selecionada. Favor entrar em contato
com o administrador do sistema”
15
M004 “Erro inesperado. Favor entrar em contato com o administrador do
sistema”
5.3.1.1.1 Diagrama de classe de análise
Figura 1 - Diagrama de classe de análise – efetuar login.
Fonte: Elaboração própria, 2021.
16
5.3.1.1.2 Protótipo
A Figura 8 representa um protótipo de tela onde o usuário informa o CPF e senha que
devem estar previamente cadastrados:
O protótipo descrito abaixo é esboço da tela real do sistema. O protótipo abaixo
representa a tela de login.
Figura 2 - Tela de criação de novo projeto.
Fonte: Elaboração própria, 2021.
17
6 DOCUMENTAÇÃO DE PROJETO
O sucesso para a aplicação do processo com tecnologias orientadas a objetos está
ligado diretamente à arquitetura em camadas e principalmente às observações do mercado
atual.
Esta organização em camadas nos permitirá independências e tem como principais
objetivos: Atingir a eficiência; Escalabilidade; Reutilização e Facilidade em Manutenção.
6.1 ARQUITETURA DE SOFTWARE
6.1.1 PADRÕES DE PROJETO
O padrão utilizado na neste projeto será o MVC, acrônimo de Model-View-Controller,
que consiste na camada de modelo, que controla as interações entre a camada de visão, que é
a interface demonstrada ao usuário, e entre a camada de controle, que irá controlar a forma
como são feitas as inserções no banco de dados.
6.2 DIAGRAMAS DA UML
Figura 9 – Diagramas da UML.
18
6.2.1 DIAGRAMA DE CLASSE
Figura 10 – Diagrama de Classe.
Fonte: Elaborado pelo autor.
6.2.2 DIAGRAMA DE ATIVIDADES
Figura 11 - Diagrama de Atividades.
Fonte: Elaborado pelo autor.
19
6.2.3 DIAGRAMA DE SEQUÊNCIA
Figura 12 - Diagrama de Sequência.
Fonte: Elaborado pelo autor.
6.2.4 DIAGRAMA DE CASOS DE USO
20
Figura 13 - Diagrama de Casos de Uso.
Fonte: Elaborado pelo autor.
6.2.5 DIAGRAMA DE MÁQUINA DE ESTADO OU TRANSIÇÃO DE ESTADO
Figura 14 - Diagrama de Máquina de Estado ou Transição de Estado.
Fonte: Elaborado pelo autor.
21
Figura 16 - Diagrama de Máquina de Estado ou Transição de Estado.
Fonte: Elaborado pelo autor.
7 MODELAGEM DO BANCO DE DADOS
7.1 MODELO CONCEITUAL DE DADOS (MODELO ENTIDADE
RELACIONAMENTO)
Figura 8 - MER: Modelo de Entidade-Relacionamento.
Fonte: Elaboração própria, 2021.
22
7.2 MODELO FÍSICO DE DADOS
Figura 9 - MFD: Modelo Físico de Dados.
Fonte: Elaboração própria, 2021.
23
7.3 SCHEMA DO BANCO DE DADOS (SCRIPT)
Contém os comandos DDL de criação do Banco de Dados e seus objetos.
7.4 DICIONÁRIO DE DADOS
Contém características dos dados que serão utilizados no banco de dados do sistema
SIGESC.
24
ColumnName DataType PrimaryKey 
NotNul
l Flags
Defau
lt
Value
Comme
nt
AutoI
nc
id_enquete INTEGER PK NN UNSIGNED AI
USUARIO_id_usu
ario INTEGER PK NN
UNSIGNE
D 
enq_pergunta VARCHAR(500) 
enq_opcao_a VARCHAR(100)end_opcao_b VARCHAR(100) 
enq_opcao_c VARCHAR(100) 
enq_opcao_d VARCHAR(100) 
IndexName IndexType Columns
PRIMARY PRIMARY id_enquete
USUARIO_id_usuario
ENQUETE_FKIndex1 Index USUARIO_id_usuario
FORNECEDOR
ColumnName DataType PrimaryKey 
NotNull 
 Flags
Defaul
t Value
Commen
t
AutoIn
c
id_fornecedor INTEGER PK NN UNSIGNED AI
25
forn_nome VARCHAR(30) 
forn_tipo VARCHAR(20) 
for_tel_celular VARCHAR(10) 
for_tel_comerci
al
VARCHAR(10
) 
IndexName IndexType Columns
PRIMARY PRIMARY id_fornecedor
26
8 CONCLUSÃO
Neste trabalho, conseguimos atingir todos os objetivos tanto geral quanto específico e nossos
resultados saíram como planejado, foi um trabalho que nos fez adquirir novos conhecimentos e novas
experiências para o mercado de trabalho.
REFERÊNCIAS
PRESSMAN, Roger S.; MAXIM, Bruce R.. Engenharia de software: uma abordagem
profissional. 8 ed. Porto Alegre: AMGH, 2016.
LAUREANO, MARCOS A. P.; MORAES, PAULO E. S.. Segurança como estratégia de
gestão da informação. Revista Economia & Tecnologia – ISSN 1415-451X, Vol. 8 –
Fascículo 3 – P. 38-44. 2005.