SISTEMA SISTEMA DE ENSINO ENS INO PRESENCIAL CONECTADO CURSO SUPERIOR DE TECNOLOGIA ANÁLISE E DESENVOLVIMENTO DESENVOLVIMENTO DE SISTEMAS ANTONIO DE PAULA VIEIRA SOBRINHO, SOB RINHO, DIEGO D IEGO TERTO SILVA, S ILVA, ERICK LEONARDO WEIL, FELIPE SMOLAK DA SILVA, JUSCELINO MACIEL MUNIZ, MOISÉIS BATISTA FARIAS, ROBISON FERREIRA DOS SANTOS.
PRODU PRODUÇ Ç O TEXTUA TEXTUAL L INTERD INTERDISC ISCIPL IPLINA INAR R EM GRUPO GRUPO DE DE ANÁLISE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS. 5º SEMESTRE – ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
Vilhena 2016
ANTONIO DE PAULA VIEIRA SOBRINHO, SOB RINHO, DIEGO D IEGO TERTO SILVA, S ILVA, ERICK LEONARDO WEIL, FELIPE SMOLAK DA SILVA, JUSCELINO MACIEL MUNIZ, MOISÉIS BATISTA FARIAS, ROBISON FERREIRA DOS SANTOS.
PRODU PRODUÇ Ç O TEXTUA TEXTUAL L INTERD INTERDISC ISCIPL IPLINA INAR R EM GRUPO GRUPO DE DE ANÁLISE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS. 5º SEMESTRE – ANALISE E DESENVOLVIMENTO DE SISTEMAS
‘
Trabalho de produção textual interdisciplinar em grupo apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral na disciplina de Engenharia e Projeto de Software, Projeto Orientado a Objetos, Programação Para Web II, Seminários. Orientador: Prof. Cristiane Regina Yamaguti Mashuda, Paulo Henrique Terra, Anderson Emidio de Macedo Goncalves, Iolanda Claudia Sanches Catarino e Marco Ikuro Hisatomi.
Vilhena 2016
ANTONIO DE PAULA VIEIRA SOBRINHO, SOB RINHO, DIEGO D IEGO TERTO SILVA, S ILVA, ERICK LEONARDO WEIL, FELIPE SMOLAK DA SILVA, JUSCELINO MACIEL MUNIZ, MOISÉIS BATISTA FARIAS, ROBISON FERREIRA DOS SANTOS.
PRODU PRODUÇ Ç O TEXTUA TEXTUAL L INTERD INTERDISC ISCIPL IPLINA INAR R EM GRUPO GRUPO DE DE ANÁLISE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS. 5º SEMESTRE – ANALISE E DESENVOLVIMENTO DE SISTEMAS
‘
Trabalho de produção textual interdisciplinar em grupo apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral na disciplina de Engenharia e Projeto de Software, Projeto Orientado a Objetos, Programação Para Web II, Seminários. Orientador: Prof. Cristiane Regina Yamaguti Mashuda, Paulo Henrique Terra, Anderson Emidio de Macedo Goncalves, Iolanda Claudia Sanches Catarino e Marco Ikuro Hisatomi.
Vilhena 2016
SUMÁRIO
1
INTRODUÇÃO .............................................................................................. 3
2
OBJETIVO .................................................................................................... 4
3
DESENVOLVIMENTO................................................................................... 5
3.1
ENGENHARIA E PROJETO DE SOFTWARE .......................... ............ .......................... .................... ........ 5
3.1.1
PROJETO DE ARQUITETURA .................................................................... 6
3.1.1.1 GRAFICO PROJETO DE ARQUITETURA ABSTRAÇÃO ........................... ............. .............. 8 3.1.1.2 GRÁFICO PROJETO DE ARQUITERURA.................... ARQUITERURA................................. .......................... .................. ..... 8 3.1.2
EAP – ESTRUTURA ANALÍTICA DO PROJETO .......................... ............. .......................... ............... 9
3.1.3
CRONOGRAMA DAS ATIVIDADES E PESSOAS PESS OAS ENVOLVIDAS. ........... 10
3.1.4
ARQUITETURA DE SISTEMAS DISTRIBUIDOS DIST RIBUIDOS .......................... ............. ......................... ............ 11
3.1.5
ARQUITETURA DE APLICAÇÃO ........................... ............. .......................... .......................... ....................... ......... 15
3.1.6
GERENCIAMENTO DE CONFIGURAÇÕES.............................. CONFIGURAÇÕES................. .......................... ................ ... 16
4
PROGRAMAÇÃO PARA WEB II .............................................................. 18
4.1
PROGRAMAÇÃO PROGRAMAÇÃO PHP......................... ............ .......................... .......................... .......................... .......................... ............... 19
4.2
DESENVOLVIMENTO EM PHP SITE EMPRESA VEICULOS ...................... ............ .......... 20
5
PROJETO ORIENTADO A OBJETOS .......................... ............. .......................... .......................... ................ ... 31
5.1.1
CASO DE USO ORIENTADO A OBJETOS OBJET OS (UML) ........................... ............. ....................... ......... 32
5.1.1.2 CASO DE USO EMPRESA VEICULOS .......................... ............. .......................... .......................... ............... 32 5.1.2
DIAGRAMA DE COMPONENTE ORIENTADO A OBJETOS (UML)......... 33
5.1.2.1 DIAGRAMA DE COMPONENTE EMPRESA VEÍCULOS ......................... ............ ............... 33 5.1.3
DIAGRAMA DE PACOTE P ACOTE ORIENTADO A OBJETOS O BJETOS (UML) ( UML) ................... 34
5.1.3.1 DIAGRAMA DE PACOTES P ACOTES EMPRESA VEÍCULOS ............................... .................. ................ ... 34 5.1.4
DIAGRAMA DE CLASSE ORIENTADO OR IENTADO A OBJETOS (UML).................... ............. ....... 34
5.1.4.1 DIAGRAMA DE CLASSE CL ASSE EMPRESA VEÍCULOS .................................. ..................... ................ ... 36 5.1.5
MODELO LÓGICO EMPRESA VEÍCULOS BRMODELO (UML) .............. .. ............ 36
5.1.6
MODELO FÍSICO EMPRESA VEÍCULOS VE ÍCULOS BRMODELO (UML).............. (UML). ................ ... 37
6
CONCLUSÃO ............................................................................................. 40 REFERÊNCIAS......................... ............ .......................... .......................... .......................... .......................... .......................... ............... 41
3
1 INTRODUÇÃO Projetos estão presentes na vida de todos, tanto em situações profissionais quanto em pessoais, porém muitas vezes nem nos damos conta disso. São tarefas simples como ir aos supermercados ou redigir algum novo documento para o trabalho. São projetos que muitas pessoas realizam sem nem mesmo se dar conta de que são realmente projetos. Porém os projetos podem também ser mais complexos do que estes facilmente encontrados, em uma empresa da construção civil, por exemplo, cada empreendimento e encarado também como um projeto. No decorrer desta produção textual abordaremos as principais características do nosso projeto, que por sua vez se refere a uma loja virtual para revenda de veículos novos e usados, e um projeto baseado em cima de PMBoK, digramas, facilidade de pesquisa, mapa do site, comunicação com MySQL etc.
4
2 OBJETIVO Este projeto que apresentaremos, deve conter inicio meio e fim bem definidos, não importando o tamanho ou as dificuldades do mesmo. Tarefas e atitude devem ser pensadas, esculpidas, analisadas minuciosamente. Em um projeto simples, como a construção de uma página WEB, podemos usar etapas bem definidas e de fácil elaboração. Um ciclo de vida deve ser escolhido, pois precisamos saber como iremos proceder no decorrer do projeto, por isso escolhemos construir uma Estrutura Analítica de Projetos (EAP) do Inglês, Work Breakdown Structure (WBS), no intuito de analisar o que será feito em cada etapa do nosso ciclo de vida, mas, no entanto com tudo isso, é cobrado um Cronograma das atividades a serem realizadas, pois os clientes precisam de datas definidas. O objetivo deste projeto é pesquisar e analisar um possível sistema em uma plataforma WEB que atenda as necessidades de uma empresa de venda de automóveis. Com os requisitos já levantados construiremos uma EAP para controlar as ações dos integrantes do projeto. Ao final deste projeto quero deixar o leitor ou a quem de alguma forma tenha interesse no conhecimento de como normalmente são planejados e documentados os programas, software e tudo que envolvem a tecnologia do século XXI, tendo acesso a um breve relato de como funciona. Devo também salientar que aqui é só uma pesquisa superficial e de pouca profundidade, levando em consideração de todo o contexto que envolve a complexibilidade dos programadores, analistas e desenvolvedores modernos. Defendendo a tese de que o bem maior da humanidade é a informação, sendo assim necessários termos dados bem normalizados de boa qualidade e acima de tudo, bem protegidos.
5
3 DESENVOLVIMENTO Desde os idos mais remotos da humanidade, mesmo nas sociedades mais primitivas ou mesmo entre os animais, a busca pelo alívio da dor e pela cura das doenças sempre foi tentada. Entretanto, a história demonstra que a sociedade, ao adquirir algum grau de desenvolvimento, conhecendo melhor o mundo e suas ciências tecnológicas, passou a buscar meios cada vez, mas eficaz de se chegar a excelência humana.
3.1 ENGENHARIA E PROJETO DE SOFTWARE ENGENHARIA E PROJETO DE SOFTWARE tem como o PMBoK o guia de boas práticas. Gerenciamento de Projetos são a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto a fim de atender aos seus requisitos. Ele pode ser mais bem explicado através dos processos que o compõem, que podem ser reunidos em cinco grupos de processos: –
Iniciação, Planejamento, Execução, Controle e Encerramento
de conhecimento
–
–
e em nove Áreas
Gerenciamento da Integração do Projeto, Gerenciamento do
Escopo do Projeto, Gerenciamento do Tempo do Projeto, Gerenciamento dos Custos do Projeto, Gerenciamento da Qualidade do Projeto, Gerenciamento dos Recursos Humanos do Projeto, Gerenciamento da Comunicação do Projeto, Gerenciamento dos Riscos do Projeto e Gerenciamento de Aquisição do Projeto. A equipe do projeto gerencia os trabalhos envolvidos nele, que geralmente envolvem: - Balanceamento de demandas conflitantes do escopo, tempo, custo, risco e qualidade do projeto, obtendo-se então alcance dos requisitos estabelecidos. O guia PMBoK possui diversos processos, ferramentas e técnicas úteis para a gerência de qualquer projeto. O guia não determina como será gerenciado um projeto, ele apenas dá boas práticas, deixando livre para o gerente de projeto e a equipe escolherem aquilo que melhor se adapte ao seu projeto. Além disso, o PMBoK identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos. Ou seja, onde o mesmo possui informações consensuais que foram identificados por profissionais da área e que ao ser usado nos projetos,
6
aumentam as chances de sucesso.
3.1.1 PROJETO DE ARQUITETURA Como se pode perceber pela especificação de requisitos para o sistema em questão, não há grandes restrições de desempenho e disponibilidade, ainda que algumas restrições tenham sido explicitamente apontadas. Assim, levando-se em consideração os requisitos para o sistema proposto, foram considerados como os principais atributos de qualidade a serem incorporados ao sistema os seguintes, apresentados juntamente com as táticas a serem aplicadas:
Usabilidade: o
Separar a interface do restante da aplicação.
Prover ao usuário a capacidade de entrar com
o
comandados que permitam operar o sistema de modo mais eficiente. Para tal, as interfaces do sistema devem permitir, sempre que possível, a entrada por meio de seleção invés de digitação de campos.
Manutenabilidade: o
Coerência semântica: a organização do sistema deve se dar de modo que as responsabilidades em um módulo trabalhem em conjunto sem depender excessivamente de outros módulos;
o
Uso de interfaces com ocultação de informações específicas sobre a implementação dos módulos;
o
Uso de um intermediário para isolar o mecanismo de persistência de dados;
o
Uso de um intermediário para tratar as requisições de interface.
Segurança: o
Autenticar usuários usando login e senha;
o
Limitar a exposição, disponibilizando pela internet somente funcionalidades de consulta e cadastros clientes.
o
Manter uma trilha de auditoria para operações de
7
atendimento ao cliente, sempre registrando o atendente que efetuou a analise de crédito e a venda. Ainda que os demais atributos de qualidade não tenham sido considerados como sendo condutores da arquitetura, algumas táticas foram aplicadas visando garantir o nível de atendimento requerido. A seguir, as táticas consideradas são listadas:
Desempenho: o
Reduzir overhead computacional (processamento ou armazenamento em excesso) computacional em situações que não comprometam a manutenabilidade.
o
Estabelecer uma configuração de hardware mínima para comportar o sistema.
Disponibilidade: uso de exceções e transações para detecção, tratamento e prevenção de falhas.
Portabilidade: uso da linguagem Java e de bibliotecas e mecanismos de persistência capazes de rodar nos sistemas operacionais Windows e Linux.
Implementação: deve conter código limpo
8
3.1.1.1 GRAFICO PROJETO DE ARQUITETURA ABSTRAÇÃO
3.1.1.2 GRÁFICO PROJETO DE ARQUITERURA
9
3.1.2 EAP – ESTRUTURA ANALÍTICA DO PROJETO Essa EAP é apenas a primeira analise, com o decorrer do projeto irá surgir novas ideais que serão acrescidas na mesma. Uma EAP deve ser simples e ao mesmo tempo robusta, ou seja, que não seja grande e nem complexa demais para confundir os envolvidos no projeto, mas que seja preciso o suficiente para capturar todas as etapas que devem ser cumpridas. Depois de concluirmos o projeto, teremos os relatórios referentes a cada fase do processo de elaboração, isso no futuro nos levará a repensar se devemos mudar a EAP, acrescentar, modificar ou retirar alguns passos desnecessários. Esses relatórios gerados, ou documentação de elaboração do projeto, facilitara qualquer empresa de desenvolvimento de software, na manutenção do programa, identificando e corrigindo erros (Manutenção Corretiva), adaptando o software a outros ambientes (Manutenção Adaptativa), atender pedidos de modificar funções existentes, incluir novas funções e efetuar melhoramento (Manutenção Perfectiva), melhorar a manutenabilidade ou confiabilidade futura e fornecer uma base melhor para futuros melhoramentos (Manutenção Preventiva), sendo assim um sistema a prova do tempo não se tornando um sistema Legado, ou obsoleto. De acordo com as decisões tomadas pelos gerentes de projetos, foi decido usar para organizar projeto de arquitetura de software da empresa de veículos, a organização dos sistemas e seu planejamento de desenvolvimento baseado então no Guia de PMBoK, o gerenciamento em EAP – Estrutura Analítica de Projeto conforme gráfico abaixo:
10
Esta figura e representa a estrutura analítica de projetos (EAP) Empresa de Veículos.
3.1.3 CRONOGRAMA DAS ATIVIDADES E PESSOAS ENVOLVIDAS. Cronograma é uma maneira de colocar as etapas do projeto de maneira cronológica, ou seja, de uma forma que podemos segui-las, obedecendo às datas especificas para cumpri-las. A vantagem de um cronograma é o fato do gerente de projeto poder manter a palavra com seus clientes, afinal a coisa mais perturbadora para um usuário é receber seu produto fora de data. Entregar o que foi prometido fora do tempo, às vezes até muito atrasado, é constrangedor para os responsáveis pelo desenvolvimento do sistema. De acordo com reunião realizada com os gerentes de projetos e os
11
envolvidos no desenvolvimento, decidimos utilizar como Cronograma das atividades para desenvolvimento do projeto a ferramenta Gantt Project, conforme gráfico abaixo:
Esta figura representa o cronograma das atividades do nosso projeto Empresa de Veículos.
3.1.4 ARQUITETURA DE SISTEMAS DISTRIBUIDOS Um Sistema Distribuído é aquele que as informações em fase de processamento são distribuídas para vários computadores, independentes que aparecem para o usuário como um único sistema, em vez de ficarem confinadas a uma única máquina (Sommerville 2003). Nos Sistemas Distribuídos o software de sistema é executado em um grupo de processadores distribuídos cooperando para execução de processos, compartilhamento de recursos conectados por uma rede.
12
Características dos sistemas distribuídos (Coulouris et al, 1994)
Compartilhamento de recursos: Inclui recursos de hardware e
software.
Abertura: Sistemas podem ser ampliados utilizando recursos não proprietários a eles.
Concorrência: Vários processos podem operar ao mesmo tempo em diferentes computadores na rede.
Escalabilidade: São escalonáveis que significa que a capacidade do sistema pode ser aumentada por acréscimo de novos recursos.
Tolerância a defeitos: Podem ser tolerantes a algumas falhas de hardware e software.
Transparência: Usuário não precisa saber da natureza distribuída do sistema.
Vantagens dos sistemas distribuídos (Coulouris et al, 1994)
Maior relação custo/benefício;
Maior capacidade de processamento;
Maior domínio de aplicações;
Maior confiabilidade;
Maior Disponibilidade;
Crescimento gradativo de sua capacidade de processamento.
Desvantagens dos sistemas distribuídos (Coulouris et al, 1994)
Complexidade: São mais complexos que os centralizados. São mais difíceis de compreender e testar.
Proteção: O sistema pode ser acessado a partir de vários computadores diferentes, e o tráfego na rede pode estar sujeito a interceptações.
Gerenciamento (esforço): Os computadores podem ser de tipos diferentes e podem operar em versões diferentes de SO. Defeitos em uma máquina podem propagar a outras máquinas.
13
Imprevisibilidade: São imprevisíveis em suas respostas. A resposta depende da carga total do sistema, sua organização e a carga de rede, e isso pode mudar de uma hora para outra.
Existem dois tipos genéricos de arquitetura de sistemas distribuídos:
Arquitetura Cliente-Servidor: os clientes precisam estar informados sobre os serviços disponíveis, mas geralmente não sabem da existência de outros clientes. Vários processos de serviços podem ser executados em um único processador de serviço, portanto não há mapeamento entre processos e processadores de um sistema. O projeto de sistemas cliente-servidor deve refletir a estrutura lógica da aplicação que esta sendo desenvolvida. CORBA é um padrão criado pelo OMG (Object Management Group) para permitir a interação entre aplicações heterogêneas em ambientes também heterogêneos, o que pode ser entendido como permitir a interação entre as aplicações desenvolvidas em diversas linguagens de programação que estão sendo executadas em diferentes máquinas (também heterogêneas) conectadas a uma rede de dados.
Uma aplicação é modelada como um conjunto de serviços que são fornecidos por servidores e um conjunto de clientes que utilizam esses serviços. Clientes e servidores são processos lógicos diferentes conforme ilustra a figura acima.
14
Arquitetura de duas camadas: A arquitetura cliente-servidor mais simples é chamada de arquitetura de duas camadas em que uma aplicação é organizada, como um servidor e um conjunto de clientes. Podem utilizar um modelo clientemagro onde o cliente só responde pela camada de apresentação (pode apresentar problemas de estabilidade e desempenho), ou um modelo cliente-gordo (pode apresentar problemas de gerenciamento), onde o cliente implementa a lógica de aplicação e as interações com os usuários do si stema.
A figura apresentada acima representa uma arquitetura cliente servidor de duas camadas.
Arquitetura de três camadas: A camada de apresentação que se ocupa de apresentar informações aos usuários e todas as interações com eles. A camada de processamento de aplicações que se ocupa de implementar a lógica da aplicação. A camada de gerenciamento das operações dos bancos de dados.
15
A figura apresentada acima ilustra a aquitetura física de um sistema com quatro computadores clientes e dois computadores servidores, e o respectivo banco de dados. Eles podem executar os processos cliente e servidor mostrados anteriormente. Em reunião realizada com os gerentes de projetos ficou decido a utilização da Arquitetura Sistemas Distribuídos Cliente-Servidor, conforme apresentado acima com suas funcionalidades, vantagens e desvantagens. Será utilizado o MiddLeware ou mediador, no campo da computação distribuída, é um programa de computador que faz a mediação entre software e demais aplicações. É utilizado para mover ou transportar informações e dados entre programas de diferentes protocolos de comunicação, plataformas e dependências do sistema operacional.
3.1.5 ARQUITETURA DE APLICAÇÃO Arquitetura de aplicação. Definimos esse tipo de estrutura por que, as principais responsabilidades do grupo são.
16
Limitar as escolhas durante o desenvolvimento em escolher um padrão para a maneira de desenvolver aflições. Definir/criar um frameworks para ser usado na aplicação indicar pontos de maneira abrangentes. Ter contato e conhecimento com as outras aplicação enxergar de maneira mas abrangente. Enxergar de maneira mas abrangente adotar um design mais com componentes. Ter contato e conhecimento com outras aplicações na organização com essas estruturas . Abaixo podemos entender melhor nosso projeto.
Arquitetura de aplicação:
3.1.6 GERENCIAMENTO DE CONFIGURAÇÕES Estado em que um sistema se encontra em um determinado momento. Lista de itens necessários para reproduzir um sistema.
17
Configurações podem ser produzidas para diferentes computadores, para diferentes sistemas operacionais, incorporando funções especificas de clientes exemplo abaixo na figura.
18
4 PROGRAMAÇÃO PARA WEB II Desenvolvimento web é o termo utilizado para descrever o desenvolvimento de sites, na internet ou na intranet. Este é o profissional que trabalha desenvolvendo websites, podendo ser um Web Designer (Desenvolvedor do Layout), ou Web Developer (Desenvolvedor de Sistemas). O desenvolvimento refere-se a um processo de construção e testes do software específico para web, com a finalidade de se obter um conjunto de programas, que satisfazem as funções pretendidas, quer em termos de usabilidade dos usuários ou compatibilidade com outros programas existentes. O desenvolvimento web pode variar desde simples páginas estáticas a aplicações ricas, comércios eletrônicos ou redes sócias.
Codificação no cliente (Front-end)
CSS
HTML
XHTML
Javascript
AJAX
FLASH
MICROSOFT SILVERLIGHT
SWIPTY
SPDROPKIT
Codificação no servidor (Back-end)
PHP
ASP
.NET
NODES.JS (JAVASCRIPT)
PERL (VIA CGI, FASTCGI)
JAVA, J2EE,WEBOBJECTS
SSJS, APTANA JAXER, MOZILA RHINO
PYTHON, DJANGO
RUBY, RUBY ON RAILS
SMALLTALK SEASIDE
19
COLDFUSION
LOTUS DOMINO
WEBSPHERE
Bancos de dados
MYSQL
POSTGRESQL
SQLITE
MICROSOFT SQL SERVER
FIREBIRD
APACHE DERBY
ORACLE
DB2
Áreas interdisciplinares
DESIGN GRÁFICO, WEB DESIGN
ARQUITETURA DA INFORMAÇÃO
USABILIDADE, ACESSIBILIDADE
4.1 PROGRAMAÇÃO PHP
PH P
originalmente
(um acrônimo recursivo para “ P HP:
P ersonal H ome P age)
H ypertext P reprocessor”,
é uma linguagem interpretada livre, usada
originalmente apenas para o desenvolvimento de aplicações presentes e atuantes no lado do servidor, capazes de gerar conteúdo dinâmico na world wide web. [2] Figura entre as primeiras linguagem passíveis de inserção em documentos HTML, dispensando em muitos casos o uso de arquivos externos para eventuais processamentos de dados. O código é interpretado no lado do servidor pelo módulo PHP, que também gera a página web a ser visualizada no lado do cliente. A linguagem evoluiu, passou a oferecer funcionalidades em linha de comando, e, além disso, ganhou características adicionais, que possibilitaram usos adicionais do PHP, não relacionados a web sites. É possível instalar o PHP na maioria dos sistemas operacionais, gratuitamente. Concorrente direto da tecnologia ASP pertencente à
20
Microsoft, o PHP é utilizado em aplicações como o MediaWiki, Facebook, Drupal, Joomia, WordPress, Magento e o Oscommerce. Criado por Rasmus Lerdorf em 1995, o PHP tem a produção de sua implementação principal, referência formal da linguagem, manda por uma organização chamada The PHP Group. PHP é software livre, licenciado sob a PHP License, uma licença incompatível com a GNU General Public License (GPL) devido a restrições no uso do termo PHP.
4.2 DESENVOLVIMENTO EM PHP SITE EMPRESA VEICULOS Tela 1 Código Cadastro Login no Site.
21
Tela 2 Código Cadastro Login no Site.
Tela 3 Página Cadastro Login.
Os códigos acima representa a área de cadastro do site, aonde o usuário ira se cadastrar para poder acessar certas áreas do site.
22
Tela 1 Código Atendimento Cliente no Site
Tela 2 Código Atendimento Cliente no Site
23
Tela 3 Pagina Web Atendimento Cliente.
Os códigos acima são da área de atendimento que o cliente vai ter no site para esclarecimento das dúvidas e perguntas para melhor entendimento do cliente. T odos estes códigos são da página de atendimento. Tela 1 Código Gerenciamento do Site.
24
Tela 2 Código Gerenciamento do Site.
Tela 3 Código Gerenciamento do Site.
25
Tela 4 Código Gerenciamento do Site.
Tela 5 Código Gerenciamento do Site.
26
Tela 6 Código Gerenciamento do Site.
Tela 7 Código Gerenciamento do Site.
27
Tela 8 Página Gerenciamento do Site.
Tela 9 Página Gerenciamento do Site
28
Tela 10 Página Gerenciamento do Site
Tela 11 Código Gerenciamento do Site
Os códigos acima representa toda a área de gerenciamento do site onde o gerente poderá ver tudo o que acontece no site, as mensagens que o cliente envia, os pedidos dos carros, ele também pode modificar qualquer coisa pela sua área de gerenciamento e todas as alterações feitas por ele também será modificada no
29
banco de dados, assim facilitando para funcionar tirando o problema dele mexer no banco de dados e der algum erro por que se ele modificar um carro na área dele essa modificação será feita no banco também. Tela 1 Código Área de descrição do Veículo no Site.
Tela 2 Código Área de descrição do Veículo no Site.
30
Tela 3 Código Área de descrição do Veículo no Site.
Tela 4 Página Web Área de descrição do veículo.
Os códigos acima representam a área de detalhes e todas as características do veículo para o cliente analisar.
31
5 PROJETO ORIENTADO A OBJETOS A abordagem orientada a objetos possibilita uma melhor organização, versatilidade e reutilização do código fonte, o que facilita atualizações e melhorias nos programas, sendo assim caracterizada pelo uso de classes e objetos, e de outros conceitos. Classes: São espécies de montadores de objetos, que define suas
características como, quais funções são capazes de realizar e quais os atributos que o objeto possui. Objeto: é uma instancia gerada a partir de uma classe. Um objeto é
identificado a partir dos métodos e dos atributos que possui. Encapsulamento: é o ato de esconder do usuário os processos
internos de um objeto. Herança (e Polimorfismo) é uma característica que permite a
determinada classe herdar as características de outra classe. Ou seja, classe descendente adquiriu todos os métodos e atributos da classe pai.
Métodos: - São as funções que objeto pode realizar.
Atributo: - É tudo que um objeto possui como variável.
UML – Linguagem de Modelagem Unificada Definição: - É uma linguagem gráfica para visualizar, especificar, contruir e documenta os artefatos de um sistema computacional orientado a objetos.
Vantagens: - Desenvolvimento de programas de forma rápida, eficiente efetiva; - Revela a estrutura desejada e o comportamento do sistema; - Permite a visualização e controle da arquitetura do sistema; - Melhor entendimento do sistema que está sendo construindo e gerenciamento de riscos .
32
5.1.1 CASO DE USO ORIENTADO A OBJEOTOS (UML) De acordo com a UML, deve-se ter uma visão de casos de uso, expondo as exigências do sistema; uma visão de projeto, capturando o vocabulário do espaço do problema e do espaço da solução; uma visão do processo, modelando a distribuição dos processos e linhas do sistema; uma visão de implementação, dirigindo-se à realização física do sistema; e uma visão de distribuição, focando na edição da engenharia de sistema. Cada uma dessas visões pode ter aspectos estruturais, assim como comportamentais. Juntas essas visões representam as plantas dos sistemas computacionais.
5.1.1.2 CASO DE USO EMPRESA VEICULOS
33
5.1.2 DIAGRAMA DE COMPONENTE ORIENTADO A OBJEOTOS (UML) Este diagrama mostra de forma simplificada e organizada qual o trajeto e as peças que compõem o código fonte, inclusive as comunicações entre todos os componentes assim passamos a entender melhor os processos e quando eles acontecem. A primeira interface refere-se a parte visual em que o cliente passa a acessar o site. Se o mesmo quiser ter acesso às características e valores dos veículos ele precisa preencher um formulário de cadastramento que estará em outra página, só assim poderá ter acesso ao menu completo oferecidas pelo site. O site faz a busca no banco de dados buscando as informações do veículo, retornando se a mesmo esta disponível ou não para efetuar o pedido. O gerente ou funcionário poderá solicitar ao banco de dados relatórios detalhado dos clientes, vendas ou veículos, e as quantidades de acesso ao site etc.
5.1.2.1 DIAGRAMA DE COMPONENTE EMPRESA VEÍCULOS
34
5.1.3 DIAGRAMA DE PACOTE ORIENTADO A OBJEOTOS (UML) Com base do relatório relacionado ao projeto estruturado, fizemos o diagrama de pacotes dividido mostrando as dependências entre eles. Este diagrama é muito útil para ilustrar a arquitetura de um sistema mostrando o agrupamento de suas classes. Os pacotes se relacionam com outros pacotes através de uma relação de dependência. Um diagrama de pacotes pode ser usado em qualquer fase do processo de modelagem do software visando a organizar os modelos.
5.1.3.1 DIAGRAMA DE PACOTES EMPRESA VEÍCULOS
5.1.4 DIAGRAMA DE CLASSE ORIENTADO A OBJEOTOS (UML) Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. É uma
35
modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.
CONCEITOS.:
Classe: Elemento abstrato que representa um conjunto de objetos.
Atributo: Define a característica de classe como: o
Visibilidade:
Pública: +
Privada: -
Protegida: #
Pacote: ~
Operação: Função requerida a um objeto abstrato.
Associação: Relacionamento entre classes.
36
5.1.4.1 DIAGRAMA DE CLASSE EMPRESA VEÍCULOS
5.1.5 MODELO LÓGICO EMPRESA VEÍCULOS BRMODELO (UML) Modelo lógico já leva em conta algumas limitações e implementa recursos como adequação de padrão e nomenclatura, define as chaves primárias e estrangeiras, normalização, integridade referencial, entre outras.
37
5.1.6 MODELO FÍSICO EMPRESA VEÍCULOS BRMODELO (UML) No modelo físico fazemos a modelagem física do modelo de banco de dados. Neste caso leva-se em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no item anterior, modelo lógico.
-- Geração de Modelo físico -- Sql ANSI 2003 - brModelo.
CREATE TABLE Cliente ( id_cliente Texto(1) PRIMARY KEY , nome Texto(1) , sexo Texto(1) ,
38
bairro Texto(1) , telefone Texto(1) , email Texto(1) , data_nascimento Texto(1) , endereço Texto(1) , cidade Texto(1) , estado Texto(1) , cpf Texto(1) ) CREATE TABLE Estoque ( Valor Texto(1) , ano Texto(1) , cor Texto(1) , modelo Texto(1) , marca Texto(1) , automovel Texto(1) , id_estoque Texto(1) PRIMARY KEY ) CREATE TABLE Concessionária ( data_pedido Texto(1) , concessionaria Texto(1) PRIMARY KEY , id_funcionario Texto(1) ) CREATE TABLE Funcionario ( estado Texto(1) , cidade Texto(1) , bairro Texto(1) , id_funcionario Texto(1) PRIMARY KEY , nome Texto(1) , cpf Texto(1) , sexo Texto(1) , telefone Texto(1) , cargo Texto(1) , salario Texto(1) , endereço Texto(1) , data_nascimento Texto(1) ) CREATE TABLE Tem ( id_estoque Texto(1) , concessionaria Texto(1) , FOREIGN KEY (id_estoque) REFERENCES Estoque (id_estoque), FOREIGN KEY (concessionaria) REFERENCES Concessionária (concessionaria) )
39
CREATE TABLE Cadastro ( id_cliente Texto(1) , concessionaria Texto(1) , FOREIGN KEY (id_cliente) REFERENCES Cliente (id_cliente), FOREIGN KEY (concessionaria) REFERENCES Concessionária (concessionaria) ) ALTER TABLE Concessionária ADD FOREIGN REFERENCES Funcionario (id_funcionario)
KEY (id_funcionario)
40
6 CONCLUSÃO Este trabalho foi proveitoso no sentido de conhecer mais as ferramentas para desenvolvimento de software, projetos e artquiteturas, e o uso de frameworks, a persistência de dados. Enfim, foi um apanhado de como é criterioso e analítico a confecção de um bom software onde entendi que para ser criado um bom software tem que ser bem planejado e estruturado para se tornar eficaz.
