Para tanto, além da revisão da literatura, também foram utilizadas entrevistas com o cliente como fonte metodológica para verificar a viabilidade e necessidades do sistema proposto. O projeto de controle de frota ZBD, além de mostrar a pesquisa teórica realizada e o investimento em um sistema que de certa forma não existe, mostra todas as etapas do projeto encomendado pelo cliente para solucionar os problemas que realmente ocorrem, o que mostra um pouco da realidade dos especialistas em programação no mercado de trabalho atual.
1.2 - Justificativa
1.3 - Objetivo
2 - TRABALHOS RELACIONADOS
2.1 - Softwares Relacionados
2.2- Descrição dos sistemas
Por exemplo, como você pode ver na Figura 1, para abrir uma tela de cadastro é necessário selecionar o módulo à esquerda e depois procurar a opção de cadastro no menu na parte superior da tela. A Figura 9 mostra que a tela de agendamento também é simples e oferece diversas opções de agendamento, como agendamento de viagens, manutenções e suprimentos.
2.3 - Conclusão da pesquisa dos softwares
Porém, como todos os outros sistemas já relatados, o SGA também visa transportar um caráter mais comercial, incluindo dados de clientes, o que não corresponde à nossa realidade. Porém, em alguns pontos, como o fato de serem programas que não funcionam na rede, e a solicitação de veículos (atribuição) não existir, acabam fugindo dos requisitos do sistema proposto.
3 - REFERENCIAL TEÓRICO
3.1 – PROCESSO DE DESENVOLVIMENTO DO SOFTWARE: O CICLO DE VIDA DO SOFTWARE
Segundo Pressman, o projeto é “[..] um processo de múltiplas etapas que foca em quatro propriedades distintas do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface” (PRESSMAN, 1995, p.33). Segundo Pressman, “a manutenção de software aplica cada um dos estágios anteriores do ciclo de vida novamente a um programa existente, e não a um novo” (PRESSMAN, 1995, p.34).
3.2 – PADRÃO DE PROJETO
MVC (Model – View – Controller) é na verdade um padrão para organizar um projeto de software. Uma alteração em um objeto requer alterações em outros, e você não sabe quantos objetos precisam ser alterados.
3.3 - ORIENTAÇÃO A OBJETOS
O contraste entre orientação a processos e orientação a objetos pode ser resumido da seguinte forma: O processamento de dados convencional concentra-se nos tipos de processos que manipulam tipos de dados. A orientação a objetos concentra-se em tipos de objetos cuja estrutura de dados só pode ser manipulada com os métodos da classe de objeto. Em geral, em um sistema construído utilizando técnicas orientadas a objetos, “cada objeto realmente desempenha uma função específica independentemente de outros objetos.
Ele responde à mensagem sem saber por que a mensagem foi enviada ou quais serão as consequências de sua ação.” (MARTIN, 1995, p.38).
3.4 - LIGUAGEM DE PROGRAMAÇÃO
O PHP está focado em ser uma linguagem de script do lado do servidor, então você pode fazer tudo o que qualquer outro programa CGI pode fazer, como: coletar dados de formulários, gerar páginas com conteúdo dinâmico ou enviar e receber cookies. REFERÊNCIA PHP). A comunicação entre o usuário e o sistema PHP é feita através de HTML, porém os dados enviados ao sistema PHP são processados como em qualquer outra linguagem de programação, dando ao PHP uma grande gama de opções de sistema para desenvolver. JavaScript é que o JavaScript é executado no lado do cliente, enquanto no PHP a execução é no lado do servidor.
Dessa forma, todo o trabalho de verificação e conserto é feito pelo cliente, deixando o servidor “livre” para processar o próprio sistema.
3.5 - SISTEMA DE GERENCIAMENTO DE BANCO DE DADOS (SGBD)
Para Silberschatz “Um sistema gerenciador de banco de dados (SGBD) consiste em um conjunto de dados vinculados a um conjunto de programas para acessar esses dados” (SILBERSCHATZ, 1999, p.01). Além disso, um sistema de banco de dados deve garantir a segurança das informações armazenadas contra possíveis problemas no sistema, além de evitar tentativas de acesso não autorizado. SQL (Structured Query Language) é uma linguagem padrão para gerenciar o acesso a um banco de dados.
Ele “[..] é um servidor de banco de dados SQL (Structured Query Language) muito rápido, multitarefa e multiusuário” (MANUAL DE REFERÊNCIA MYSQL), podendo ser instalado nas diversas plataformas disponíveis no mercado atual (Windows, Linux , Mac OS).
3.6 – UML
Os diagramas de casos de uso descrevem as funções que cada pessoa que acessa o sistema (atores) pode ou não executar. Os diagramas de modelagem comportamental descrevem interações entre objetos que modelam o sistema ou mesmo o estado do objeto individual. Os diagramas de modelagem de comportamento mais importantes são os diagramas de sequência, que “[..] ilustram interações entre objetos em um determinado período de tempo” (SILVA, 2001, p.126).
Por fim, temos diagramas de arquitetura que descrevem as ações realizadas durante a fase de implementação do software.
3.7 – A arquitetura Cliente-Servidor
Os diagramas de componentes ilustram as dependências entre os componentes de software e os diagramas de instalação, diz Silva, ilustram. Uma grande vantagem da arquitetura cliente-servidor é a facilidade de atualizar ou alterar um módulo do sistema ou incluir arquivos mais atuais, pois isso é feito apenas no servidor e os clientes acessam tudo o que já está atualizado. É fácil adicionar um novo servidor e integrá-lo ao restante do sistema, além de atualizar os servidores de forma transparente, sem afetar outras partes do sistema.
3.8 – Testes de Software
METODOLOGIA
4.1- Aplicando o sistema às necessidades do cliente
É necessário extrair os requisitos que o sistema deve fazer das necessidades das partes interessadas para atender às necessidades da organização. As descrições de recursos e restrições são os requisitos do sistema, e o processo de descobrir, analisar, documentar e verificar esses recursos e restrições é chamado de engenharia de requisitos. Requisitos funcionais são declarações sobre funções que o sistema deve fornecer, como o sistema deve responder a entradas específicas e como deve se comportar em determinadas situações” (SOMMERVILLE, p83, 2003), em outras palavras, requisitos funcionais são aqueles que descrevem o comportamento de o sistema, o sistema, suas ações para cada entrada.
Requisitos não funcionais são aqueles que não estão diretamente relacionados às funções específicas fornecidas pelo sistema.
5 - DESCRIÇÃO DA PROPOSTA
5.1 – O que está sendo proposto
5.2 – Estudos de Viabilidade
Acelere o trabalho existente para facilitar o agendamento de motoristas e veículos e um controle mais ativo sobre as condições do veículo, fornecendo alertas sobre peças e datas para mudanças preventivas, como trocas de óleo. uma visão sistêmica da instituição, para que percebêssemos que era preciso algo para acelerar esse trabalho; os setores desta instituição estão bem distribuídos para que um setor não interaja com as necessidades do outro; por isso não pensamos que haveria necessidade de algo para gerenciar o controle do veículo, porque tudo funciona de forma não automatizada.” Para poder facilitar o meu trabalho, agilizar o planeamento com base de dados para ter acesso aos motoristas e veículos disponíveis e poder montar uma escala para realizar as missões solicitadas, a dificuldade que encontro é a necessidade de informações urgentes e ter que pesquisar nos arquivos.
O programa deverá ser escrito na linguagem PHP e no banco de dados MySQL, pois o sistema EsPCEx já possui um programa rodando na intranet, e neste caso este programa de gerenciamento de frota será incorporado ao já existente através de um link no qual o usuário irá ter a senha para que apenas os autorizados tenham acesso, ou seja, apenas os responsáveis pela Transportadora, enquanto as solicitações de veículos podem ser acessadas por todos da Guarnição."
5.3 – Levantamento dos requisitos
Registro de atribuições: O sistema deve armazenar todas as viagens concluídas, independentemente de terem sido realizadas dentro ou fora da unidade militar. Registrar Quilometragem: Ao final de uma missão, o sistema deve armazenar quantos quilômetros o veículo percorreu naquela missão. Registrar falhas durante a missão: Ao final da missão, o sistema deverá registrar todas as falhas que o veículo teve durante a missão.
Solicitação de veículo para missão via rede (intranet): O sistema deverá disponibilizar o recurso para solicitação de veículo para missão, para que não haja necessidade de preenchimento de formulários e realização de ligações para que o gerente da garagem não faça
5.4 – Análise dos requisitos
Um diagrama de classes representa todas as classes do sistema com seus métodos, atributos e relacionamentos entre eles. Após a emissão do RM, você ainda poderá alterar os dados caso ainda não tenha sido programado pelo administrador do sistema. Se o RM estiver no estado “Programando”, ele poderá ser excluído pelo usuário emissor, mas se já estiver “Programado”, somente o administrador do sistema poderá excluí-lo, conforme mostram os diagramas 11 e 12.
A última das principais funções do sistema é programar o RM e consequentemente gerar a missão que realizará o serviço solicitado.
5.5 – Codificação
As primeiras são as classes que modelam a realidade da vida militar quotidiana, classes mostradas no diagrama 7 do capítulo anterior. Os controlados são divididos entre o controlador principal (arquivo controller.php) que identifica a classe e o método a ser chamado, garantindo o polimorfismo, e os controladores que se referem a cada uma das classes principais e que trocam informações entre os dados inseridos pelo usuário e classes SQL. Desta forma, o sistema é dividido de acordo com o padrão MVC, explicado no Capítulo 4, onde as classes que modelam o sistema e as classes SQL representam a camada do modelo, as classes de controle representam a camada do controlador e os arquivos HTML da tela representam a camada do modelo. ver. baixo..
Para ilustrar o funcionamento do sistema, vamos considerar os passos para cadastramento de um novo soldado no sistema: Após o preenchimento dos dados do formulário e confirmação, o sistema “chama” o arquivo controller.php, que é o controlador principal do sistema, i que localiza o controlador militar e o método a ser executado (este método é definido no formulário, utilizando um campo oculto, no caso deste exemplo, o método insert).
5.6 – Testes
Existe uma classe SQL para cada uma das classes principais, e elas são responsáveis por executar métodos de persistência com o banco de dados, como insert, alter, delete, etc. O controlador cria uma instância da classe Militar e usa os métodos definidos para determinar os valores inseridos pelo usuário. O teste de caixa branca foi realizado durante o desenvolvimento do ZBD para verificar a estrutura do sistema.
O teste caixa preta foi realizado após o término da programação do primeiro modelo do sistema e buscou verificar o comportamento dos métodos (principalmente os métodos de persistência) em relação aos dados fornecidos pelo usuário.
5.7 – Manutenção
Outras simulações para verificar a operação dos métodos get e set, métodos específicos do controlador e métodos de persistência. Mensagem de erro ao listar RMs pendentes: No procedimento de listagem de RMs a serem agendados, o método listPending da classe RM organiza todos os RMs com status "a serem agendados" em um grupo e utiliza o comando return para retornar esses dados. Porém, quando não havia RMs com status “a ser programado”, o array não foi criado e o comando return tentou retornar uma variável que não foi criada.
Foi constatado que havia um erro de JavaScript na tela de atualização do RM que impedia o funcionamento da máscara do campo de horário, bem como o envio de dados inválidos ao servidor, impedindo que a atualização ocorresse.
6 - CONCLUSÕES
7 – PLANOS PARA O FUTURO: O que evoluir no software
ANEXOS
1 – Diagramas do sistema ZBD
Nos diagramas e 25 a exclusão é realizada inserindo o ID da classe que deseja excluir, ou seja, a classe do motorista, mecânico, soldado, veículo ou RM, os dados aparecerão, o chefe confirmará a exclusão. No diagrama 27, é inserido o número da missão, a missão é listada, dados como data de retorno, hora de retorno, quaisquer observações, se houver, e assim por diante. Nos diagramas 28 e 29, tanto para inserir o veículo quanto para inserir o soldado, basta inserir os dados que o sistema solicita e confirmar a inserção.
Para inserir um motorista, basta selecionar um soldado, o motorista é criado, são inseridas informações como carteira de motorista e disponibilidade, e esse soldado é inserido na opção motorista conforme mostrado no diagrama 32.
2 – imagens do sistema ZBD
As Figuras 23, 24 e 25 mostram o processo de outra importante função proposta pelo cliente, a saber, a geração de missão. A missão é gerada quando um RM é programado, portanto primeiro o gestor da oficina seleciona qual tipo de RM deseja reportar (Figura 23). O usuário então digita no campo indicado o número do RM que deseja programar e confirma, o que o leva à tela de programação (Figura 25).
Na tela de programação existem duas caixas de seleção (komboboxes) que se comportam da seguinte forma: Primeiramente deve-se selecionar o campo do veículo, por exemplo.
3 – A licença do software livre
Inclusion of a covered work in an aggregate does not cause this license to apply to the other parts of the aggregate. You do not need to accept this license to receive or run a copy of the Program. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version".
You should receive a copy of the GNU General Public License along with this program.
