Você está na página 1de 43

SUMRIO

INTRODUO.......................................................................................................3

OBJETIVO..............................................................................................................4

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 ABSTRAO............................8


3.1.1.2 GRFICO PROJETO DE ARQUITERURA......................................................8
3.1.2

EAP ESTRUTURA ANALTICA DO PROJETO.........................................9

3.1.3

CRONOGRAMA DAS ATIVIDADES E PESSOAS ENVOLVIDAS.............10

3.1.4

ARQUITETURA DE SISTEMAS DISTRIBUIDOS.......................................11

3.1.5

ARQUITETURA DE APLICAO...............................................................15

3.1.6

GERENCIAMENTO DE CONFIGURAES...............................................16

PROGRAMAO PARA WEB II..........................................................................18

4.1

PROGRAMAO PHP....................................................................................19

4.2

desenvolvimento em php site empresa veiculos.......................................20

PROJETO ORIENTADO A OBJETOS.................................................................31

5.1.1

CASO DE USO ORIENTADO A OBJEOTOS (UML)..................................32

5.1.1.2 CASO DE USO EMPRESA VEICULOS......................................................32


5.1.2

DIAGRAMA DE COMPONENTE ORIENTADO A OBJEOTOS (UML).......33

5.1.2.1 DIAGRAMA DE COMPONENTE EMPRESA VECULOS...........................33


5.1.3

DIAGRAMA DE PACOTE ORIENTADO A OBJEOTOS (UML)..................34

5.1.3.1 DIAGRAMA DE PACOTES EMPRESA VECULOS....................................34


5.1.4

DIAGRAMA DE CLASSE ORIENTADO A OBJEOTOS (UML)..................34

5.1.4.1 DIAGRAMA DE CLASSE EMPRESA VECULOS......................................36


5.1.5

MODELO LGICO EMPRESA VECULOS BRMODELO (UML)...............36

5.1.6

MODELO FSICO EMPRESA VECULOS BRMODELO (UML).................37

CONCLUSO......................................................................................................40

REFERNCIAS...........................................................................................................41

1 INTRODUO
Projetos esto presentes na vida de todos, tanto em situaes
profissionais quanto em pessoais, porm muitas vezes nem nos damos conta disso.
So tarefas simples como ir aos supermercados ou redigir algum novo documento
para o trabalho. So projetos que muitas pessoas realizam sem nem mesmo se dar
conta de que so realmente projetos. Porm os projetos podem tambm ser mais
complexos do que estes facilmente encontrados, em uma empresa da construo
civil, por exemplo, cada empreendimento e encarado tambm como um projeto.
No decorrer desta produo textual abordaremos as principais
caractersticas do nosso projeto, que por sua vez se refere a uma loja virtual para
revenda de veculos novos e usados, e um projeto baseado em cima de PMBoK,
digramas, facilidade de pesquisa, mapa do site, comunicao com MySQL etc.

2 OBJETIVO
Este projeto que apresentaremos, deve conter inicio meio e fim bem
definidos, no importando o tamanho ou as dificuldades do mesmo. Tarefas e atitude
devem ser pensadas, esculpidas, analisadas minuciosamente. Em um projeto
simples, como a construo de uma pgina WEB, podemos usar etapas bem
definidas e de fcil elaborao. Um ciclo de vida deve ser escolhido, pois
precisamos saber como iremos proceder no decorrer do projeto, por isso
escolhemos construir uma Estrutura Analtica de Projetos (EAP) do Ingls, 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 possvel sistema em uma
plataforma WEB que atenda as necessidades de uma empresa de venda de
automveis. Com os requisitos j levantados construiremos uma EAP para controlar
as aes 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 so
planejados e documentados os programas, software e tudo que envolvem a
tecnologia do sculo XXI, tendo acesso a um breve relato de como funciona. Devo
tambm salientar que aqui s uma pesquisa superficial e de pouca profundidade,
levando em considerao 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 informao, sendo assim necessrios termos dados
bem normalizados de boa qualidade e acima de tudo, bem protegidos.

3 DESENVOLVIMENTO
Desde os idos mais remotos da humanidade, mesmo nas
sociedades mais primitivas ou mesmo entre os animais, a busca pelo alvio da dor e
pela cura das doenas sempre foi tentada.
Entretanto, a histria demonstra que a sociedade, ao adquirir algum grau de
desenvolvimento, conhecendo melhor o organismo, suas enfermidades e
tratamentos, trata de normatizar a formao dos mdicos e disciplinar o
exerccio da Medicina (SOUZA, 2001, p. 39).

3.1 ENGENHARIA E PROJETO DE SOFTWARE


ENGENHARIA E PROJETO DE SOFTWARE tem como o PMBoK o
guia de boas prticas. Gerenciamento de Projetos so a aplicao de
conhecimentos, habilidades, ferramentas e tcnicas nas atividades do projeto a fim
de atender aos seus requisitos. Ele pode ser mais bem explicado atravs dos
processos que o compem, que podem ser reunidos em cinco grupos de processos:
Iniciao, Planejamento, Execuo, Controle e Encerramento e em nove reas
de conhecimento Gerenciamento da Integrao 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 Comunicao do Projeto, Gerenciamento
dos Riscos do Projeto e Gerenciamento de Aquisio 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 ento alcance dos requisitos
estabelecidos.
O guia PMBoK possui diversos processos, ferramentas e tcnicas
teis para a gerncia de qualquer projeto. O guia no determina como ser
gerenciado um projeto, ele apenas d boas prticas, deixando livre para o gerente
de projeto e a equipe escolherem aquilo que melhor se adapte ao seu projeto. Alm
disso, o PMBoK identifica um subconjunto do conjunto de conhecimentos em
gerenciamento de projetos. Ou seja, onde o mesmo possui informaes consensuais
que foram identificados por profissionais da rea e que ao ser usado nos projetos,

aumentam as chances de sucesso.


3.1.1 PROJETO DE ARQUITETURA
Como se pode perceber pela especificao de requisitos para o
sistema em questo, no h grandes restries de desempenho e disponibilidade,
ainda que algumas restries tenham sido explicitamente apontadas. Assim,
levando-se em considerao 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 tticas a serem aplicadas:

Usabilidade:
o Separar a interface do restante da aplicao.
o Prover ao usurio a capacidade de entrar com
comandados que permitam operar o sistema de modo
mais eficiente. Para tal, as interfaces do sistema
devem permitir, sempre que possvel, a entrada por
meio de seleo invs de digitao de campos.

Manutenabilidade:
o Coerncia semntica: a organizao do sistema
deve se dar de modo que as responsabilidades em
um mdulo trabalhem em conjunto sem depender
excessivamente de outros mdulos;
o Uso de interfaces com ocultao de informaes
especficas sobre a implementao dos mdulos;
o Uso de um intermedirio para isolar o mecanismo
de persistncia de dados;
o Uso de um intermedirio para tratar as requisies
de interface.

Segurana:
o Autenticar usurios usando login e senha;
o Limitar a exposio, disponibilizando pela internet
somente funcionalidades de consulta e cadastros
clientes.

o Manter uma trilha de auditoria para operaes de


atendimento ao cliente, sempre registrando o
atendente que efetuou a analise de crdito e a
venda.
Ainda que os demais atributos de qualidade no tenham sido
considerados como sendo condutores da arquitetura, algumas tticas foram
aplicadas visando garantir o nvel de atendimento requerido. A seguir, as tticas
consideradas so listadas:

Desempenho:
o Reduzir overhead computacional (processamento ou
armazenamento

em

excesso)

computacional

em

situaes que no comprometam a manutenabilidade.


o Estabelecer uma configurao de hardware mnima
para comportar o sistema.

Disponibilidade: uso de excees e transaes para


deteco, tratamento e preveno de falhas.

Portabilidade: uso da linguagem Java e de bibliotecas e


mecanismos de persistncia capazes de rodar nos sistemas
operacionais Windows e Linux.

Implementao: deve conter cdigo limpo

3.1.1.1 GRAFICO PROJETO DE ARQUITETURA ABSTRAO

3.1.1.2 GRFICO PROJETO DE ARQUITERURA

3.1.2 EAP ESTRUTURA ANALTICA DO PROJETO


Essa EAP apenas a primeira analise, com o decorrer do projeto ir
surgir novas ideais que sero acrescidas na mesma. Uma EAP deve ser simples e
ao mesmo tempo robusta, ou seja, que no 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 relatrios referentes a cada fase do processo de elaborao,
isso no futuro nos levar a repensar se devemos mudar a EAP, acrescentar,
modificar ou retirar alguns passos desnecessrios. Esses relatrios gerados, ou
documentao

de

elaborao

do

projeto,

facilitara

qualquer

empresa

de

desenvolvimento de software, na manuteno do programa, identificando e


corrigindo erros (Manuteno Corretiva), adaptando o software a outros ambientes
(Manuteno Adaptativa), atender pedidos de modificar funes existentes, incluir
novas funes e efetuar melhoramento (Manuteno Perfectiva), melhorar a
manutenabilidade ou confiabilidade futura e fornecer uma base melhor para futuros
melhoramentos (Manuteno Preventiva), sendo assim um sistema a prova do
tempo no se tornando um sistema Legado, ou obsoleto.
De acordo com as decises tomadas pelos gerentes de projetos, foi
decido usar para organizar projeto de arquitetura de software da empresa de
veculos, a organizao dos sistemas e seu planejamento de desenvolvimento
baseado ento no Guia de PMBoK, o gerenciamento em EAP Estrutura Analtica
de Projeto conforme grfico abaixo:

10

Esta figura e representa a estrutura analtica de projetos (EAP) Empresa de


Veculos.

3.2.3 CRONOGRAMA DAS ATIVIDADES E PESSOAS ENVOLVIDAS.


Cronograma uma maneira de colocar as etapas do projeto de
maneira cronolgica, 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 usurio receber seu produto fora de data. Entregar o que foi
prometido fora do tempo, s vezes at muito atrasado, constrangedor para os
responsveis pelo desenvolvimento do sistema.
De acordo com reunio 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 grfico
abaixo:

Esta figura representa o cronograma das atividades do nosso projeto Empresa de


Veculos.

3.1.3 ARQUITETURA DE SISTEMAS DISTRIBUIDOS


Um Sistema Distribudo aquele que as informaes em fase de
processamento so distribudas para vrios computadores, independentes que
aparecem para o usurio como um nico sistema, em vez de ficarem confinadas a
uma nica mquina (Sommerville 2003).
Nos Sistemas Distribudos o software de sistema executado em
um grupo de processadores distribudos cooperando para execuo de processos,
compartilhamento de recursos conectados por uma rede.

12

Caractersticas dos sistemas distribudos (Coulouris et al, 1994)

Compartilhamento de recursos: Inclui recursos de hardware e software.

Abertura:

Sistemas

podem

ser

ampliados

utilizando

recursos

no

proprietrios a eles.

Concorrncia: Vrios processos podem operar ao mesmo tempo em


diferentes computadores na rede.

Escalabilidade: So escalonveis que significa que a capacidade do sistema


pode ser aumentada por acrscimo de novos recursos.

Tolerncia a defeitos: Podem ser tolerantes a algumas falhas de hardware e


software.

Transparncia: Usurio no precisa saber da natureza distribuda do


sistema.

Vantagens dos sistemas distribudos (Coulouris et al, 1994)

Maior relao custo/benefcio;

Maior capacidade de processamento;

Maior domnio de aplicaes;

Maior confiabilidade;

Maior Disponibilidade;

Crescimento gradativo de sua capacidade de processamento.

Desvantagens dos sistemas distribudos (Coulouris et al, 1994)

Complexidade: So mais complexos que os centralizados. So mais difceis


de compreender e testar.

Proteo: O sistema pode ser acessado a partir de vrios computadores


diferentes, e o trfego na rede pode estar sujeito a interceptaes.

Gerenciamento (esforo): Os computadores podem ser de tipos diferentes e


podem operar em verses diferentes de SO. Defeitos em uma mquina
podem propagar a outras mquinas.

Imprevisibilidade: So imprevisveis em suas respostas. A resposta depende

13

da carga total do sistema, sua organizao e a carga de rede, e isso pode


mudar de uma hora para outra.
Existem dois tipos genricos de arquitetura de sistemas distribudos:
Arquitetura Cliente-Servidor: os clientes precisam estar informados sobre os
servios disponveis, mas geralmente no sabem da existncia de outros clientes.
Vrios processos de servios podem ser executados em um nico processador de
servio, portanto no h mapeamento entre processos e processadores de um
sistema. O projeto de sistemas cliente-servidor deve refletir a estrutura lgica da
aplicao que esta sendo desenvolvida. CORBA um padro criado pelo OMG
(Object

Management

Group)

para

permitir

interao

entre

aplicaes

heterogneas em ambientes tambm heterogneos, o que pode ser entendido como


permitir a interao entre as aplicaes desenvolvidas em diversas linguagens de
programao que esto sendo executadas em diferentes mquinas (tambm
heterogneas) conectadas a uma rede de dados.

Uma aplicao modelada como um conjunto de servios que so fornecidos por


servidores e um conjunto de clientes que utilizam esses servios. Clientes e
servidores so processos lgicos 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 aplicao organizada,
como um servidor e um conjunto de clientes. Podem utilizar um modelo clientemagro onde o cliente s responde pela camada de apresentao (pode apresentar
problemas de estabilidade e desempenho), ou um modelo cliente-gordo (pode
apresentar problemas de gerenciamento), onde o cliente implementa a lgica de
aplicao e as interaes com os usurios do sistema.

A figura apresentada acima representa uma arquitetura cliente servidor de duas


camadas.
Arquitetura de trs camadas: A camada de apresentao que se ocupa de
apresentar informaes aos usurios e todas as interaes com eles. A camada de
processamento de aplicaes que se ocupa de implementar a lgica da aplicao. A
camada de gerenciamento das operaes dos bancos de dados.

15

A figura apresentada acima ilustra a aquitetura fsica 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 reunio realizada com os gerentes de projetos ficou decido a
utilizao

da

Arquitetura

Sistemas

Distribudos

Cliente-Servidor,

conforme

apresentado acima com suas funcionalidades, vantagens e desvantagens.


Ser utilizado o MiddLeware ou mediador, no campo da computao distribuda,
um programa de computador que faz a mediao entre software e demais
aplicaes. utilizado para mover ou transportar informaes e dados entre
programas de diferentes protocolos de comunicao, plataformas e dependncias
do sistema operacional.
3.1.4 ARQUITETURA DE APLICAO
Arquitetura de aplicao.
Definimos

esse

responsabilidades do grupo so.

tipo

de

estrutura

por

que,

as

principais

16

Limitar as escolhas durante o desenvolvimento em escolher um


padro para a maneira de desenvolver aflies.
Definir/criar um frameworks para ser usado na aplicao indicar
pontos de maneira abrangentes.
Ter contato e conhecimento com as outras aplicao enxergar de
maneira mas abrangente.
Enxergar de maneira mas abrangente adotar um design mais com
componentes.
Ter contato e conhecimento com outras aplicaes na organizao
com essas estruturas . Abaixo podemos entender melhor nosso projeto.

Arquitetura de aplicao:

3.1.5 GERENCIAMENTO DE CONFIGURAES


Estado em que um sistema se encontra em um determinado
momento.
Lista de itens necessrios para reproduzir um sistema.
Configuraes podem ser produzidas para diferentes computadores,

17

para diferentes sistemas operacionais, incorporando funes especificas de clientes


exemplo abaixo na figura.

18

4 PROGRAMAO 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 construo e testes do software especfico para web,
com a finalidade de se obter um conjunto de programas, que satisfazem as funes
pretendidas, quer em termos de usabilidade dos usurios ou compatibilidade com
outros programas existentes. O desenvolvimento web pode variar desde simples
pginas estticas a aplicaes ricas, comrcios eletrnicos ou redes scias.
Codificao no cliente (Front-end)

CSS

HTML

XHTML

Javascript

AJAX

FLASH

MICROSOFT SILVERLIGHT

SWIPTY

SPDROPKIT

Codificao no servidor (Back-end)

PHP

ASP

.NET

NODES.JS (JAVASCRIPT)

PERL (VIA CGI, FASTCGI)

JAVA, J2EE,WEBOBJECTS

SSJS, APTANA JAXER, MOZILA RHINO

PYTHON, DJANGO

19

RUBY, RUBY ON RAILS

SMALLTALK SEASIDE

COLDFUSION

LOTUS DOMINO

WEBSPHERE
Bancos de dados

MYSQL

POSTGRESQL

SQLITE

MICROSOFT SQL SERVER

FIREBIRD

APACHE DERBY

ORACLE

DB2
reas interdisciplinares

DESIGN GRFICO, WEB DESIGN

ARQUITETURA DA INFORMAO

USABILIDADE, ACESSIBILIDADE

4.1 PROGRAMAO PHP

PHP (um acrnimo recursivo para PHP: Hypertext Preprocessor,


originalmente Personal Home Page) uma linguagem interpretada livre, usada
originalmente apenas para o desenvolvimento de aplicaes presentes e atuantes
no lado do servidor, capazes de gerar contedo dinmico na world wide web. [2]
Figura entre as primeiras linguagem passveis de insero em documentos HTML,
dispensando em muitos casos o uso de arquivos externos para eventuais
processamentos de dados. O cdigo interpretado no lado do servidor pelo mdulo
PHP, que tambm gera a pgina web a ser visualizada no lado do cliente. A
linguagem evoluiu, passou a oferecer funcionalidades em linha de comando, e, alm

20

disso, ganhou caractersticas adicionais, que possibilitaram usos adicionais do PHP,


no relacionados a web sites. possvel instalar o PHP na maioria dos sistemas
operacionais, gratuitamente. Concorrente direto da tecnologia ASP pertencente
Microsoft, o PHP utilizado em aplicaes como o MediaWiki, Facebook, Drupal,
Joomia, WordPress, Magento e o Oscommerce.
Criado por Rasmus Lerdorf em 1995, o PHP tem a produo de sua implementao
principal, referncia formal da linguagem, manda por uma organizao chamada The
PHP Group. PHP software livre, licenciado sob a PHP License, uma licena
incompatvel com a GNU General Public License (GPL) devido a restries no uso
do termo PHP.

4.2 DESENVOLVIMENTO EM PHP SITE EMPRESA VEICULOS


Tela 1 Cdigo Cadastro Login no Site.

21

Tela 2 Cdigo Cadastro Login no Site.

Tela 3 Pgina Cadastro Login.

Os cdigos acima representa a rea de cadastro do site, aonde o usurio ira se

22

cadastrar para poder acessar certas reas do site.

Tela 1 Cdigo Atendimento Cliente no Site

Tela 2 Cdigo Atendimento Cliente no Site

23

Tela 3 Pagina Web Atendimento Cliente.

Os cdigos acima so da rea de atendimento que o cliente vai ter no site para
esclarecimento das dvidas e perguntas para melhor entendimento do cliente. Todos
estes cdigos so da pgina de atendimento.
Tela 1 Cdigo Gerenciamento do Site.

24

Tela 2 Cdigo Gerenciamento do Site.

Tela 3 Cdigo Gerenciamento do Site.

25

Tela 4 Cdigo Gerenciamento do Site.

Tela 5 Cdigo Gerenciamento do Site.

26

Tela 6 Cdigo Gerenciamento do Site.

Tela 7 Cdigo Gerenciamento do Site.

27

Tela 8 Pgina Gerenciamento do Site.

Tela 9 Pgina Gerenciamento do Site

28

Tela 10 Pgina Gerenciamento do Site

Tela 11 Cdigo Gerenciamento do Site

29

Os cdigos 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 tambm pode modificar qualquer coisa pela sua rea de
gerenciamento e todas as alteraes feitas por ele tambm ser modificada no
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 modificao ser feita no banco tambm.
Tela 1 Cdigo rea de descrio do Veculo no Site.

30

Tela 2 Cdigo rea de descrio do Veculo no Site.

Tela 3 Cdigo rea de descrio do Veculo no Site.

31

Tela 4 Pgina Web rea de descrio do veculo.

Os cdigos acima representam a rea de detalhes e todas as caractersticas do


veculo para o cliente analisar.

32

5 PROJETO ORIENTADO A OBJETOS


A

abordagem

orientada

objetos

possibilita

uma

melhor

organizao, versatilidade e reutilizao do cdigo fonte, o que facilita atualizaes e


melhorias nos programas, sendo assim caracterizada pelo uso de classes e objetos,
e de outros conceitos.

Classes: So espcies de montadores de objetos, que define suas


caractersticas como, quais funes so 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 mtodos e dos atributos que possui.

Encapsulamento: o ato de esconder do usurio os processos internos de


um objeto.

Herana (e Polimorfismo) uma caracterstica que permite a determinada


classe herdar as caractersticas de outra classe. Ou seja, classe descendente
adquiriu todos os mtodos e atributos da classe pai.

Mtodos:
- So as funes que objeto pode realizar.
Atributo:
- tudo que um objeto possui como varivel.
UML Linguagem de Modelagem Unificada
Definio:
- uma linguagem grfica para visualizar, especificar, contruir e documenta os
artefatos de um sistema computacional orientado a objetos.
Vantagens:
- Desenvolvimento de programas de forma rpida, eficiente efetiva;
- Revela a estrutura desejada e o comportamento do sistema;
- Permite a visualizao e controle da arquitetura do sistema;
- Melhor entendimento do sistema que est sendo construindo e gerenciamento de
riscos

33

.
5.1.1 CASO DE USO ORIENTADO A OBJEOTOS (UML)
De acordo com a UML, deve-se ter uma viso de casos de uso,
expondo as exigncias do sistema; uma viso de projeto, capturando o vocabulrio
do espao do problema e do espao da soluo; uma viso do processo, modelando
a distribuio dos processos e linhas do sistema; uma viso de implementao,
dirigindo-se realizao fsica do sistema; e uma viso de distribuio, focando na
edio da engenharia de sistema.
Cada uma dessas vises pode ter aspectos estruturais, assim como
comportamentais. Juntas essas vises representam as plantas dos sistemas
computacionais.

3.2.1.2 CASO DE USO EMPRESA VEICULOS

34

5.1.2 DIAGRAMA DE COMPONENTE ORIENTADO A OBJEOTOS (UML)


Este diagrama mostra de forma simplificada e organizada qual o
trajeto e as peas que compem o cdigo fonte, inclusive as comunicaes 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 caractersticas e valores dos
veculos ele precisa preencher um formulrio de cadastramento que estar em outra
pgina, s assim poder ter acesso ao menu completo oferecidas pelo site. O site
faz a busca no banco de dados buscando as informaes do veculo, retornando se
a mesmo esta disponvel ou no para efetuar o pedido.
O gerente ou funcionrio poder solicitar ao banco de dados
relatrios detalhado dos clientes, vendas ou veculos, e as quantidades de acesso
ao site etc.
3.2.1.3 DIAGRAMA DE COMPONENTE EMPRESA VECULOS

35

5.1.3 DIAGRAMA DE PACOTE ORIENTADO A OBJEOTOS (UML)


Com base do relatrio relacionado ao projeto estruturado, fizemos o
diagrama de pacotes dividido mostrando as dependncias 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 atravs de uma
relao de dependncia. Um diagrama de pacotes pode ser usado em qualquer fase
do processo de modelagem do software visando a organizar os modelos.

3.2.1.4 DIAGRAMA DE PACOTES EMPRESA VECULOS

36

5.1.4 DIAGRAMA DE CLASSE ORIENTADO A OBJEOTOS (UML)


Em programao, um diagrama de classes uma representao da
estrutura e relaes das classes que servem de modelo para objetos. uma
modelagem muito til para o desenvolvimento de sistemas, pois define todas as
classes que o sistema necessita possuir e a base para a construo dos
diagramas de comunicao, sequncia e estados.
CONCEITOS.:

Classe: Elemento abstrato que representa um conjunto de objetos.

Atributo: Define a caracterstica de classe como:


o Visibilidade:

Pblica: +

Privada: -

Protegida: #

Pacote: ~

Operao: Funo requerida a um objeto abstrato.

Associao: Relacionamento entre classes.

37

5.1.4.1 DIAGRAMA DE CLASSE EMPRESA VECULOS

5.1.5 MODELO LGICO EMPRESA VECULOS BRMODELO (UML)


Modelo lgico j leva em conta algumas limitaes e implementa
recursos como adequao de padro e nomenclatura, define as chaves primrias e
estrangeiras, normalizao, integridade referencial, entre outras.

38

5.1.6 MODELO FSICO EMPRESA VECULOS BRMODELO (UML)


No modelo fsico fazemos a modelagem fsica do modelo de banco
de dados. Neste caso leva-se em conta as limitaes impostas pelo SGBD escolhido
e deve ser criado sempre com base nos exemplos de modelagem de dados
produzidos no item anterior, modelo lgico.

-- Gerao de Modelo fsico


-- Sql ANSI 2003 - brModelo.

CREATE TABLE Cliente (


id_cliente Texto(1) PRIMARY KEY,
nome Texto(1),
sexo Texto(1),

39

bairro Texto(1),
telefone Texto(1),
email Texto(1),
data_nascimento Texto(1),
endereo 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 Concessionria (
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),
endereo 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
Concessionria
(concessionaria)
)
CREATE TABLE Cadastro (

40

id_cliente Texto(1),
concessionaria Texto(1),
FOREIGN KEY(id_cliente) REFERENCES Cliente (id_cliente),
FOREIGN
KEY(concessionaria)
REFERENCES
Concessionria
(concessionaria)
)
ALTER TABLE Concessionria ADD FOREIGN KEY(id_funcionario)
REFERENCES Funcionario (id_funcionario)

41

6 CONCLUSO
Este trabalho foi proveitoso no sentido de conhecer mais as
ferramentas para desenvolvimento de software, projetos e artquiteturas, e o uso de
frameworks, a persistncia de dados. Enfim, foi um apanhado de como criterioso e
analtico a confeco de um bom software onde entendi que para ser criado um bom
software tem que ser bem planejado e estruturado para se tornar eficaz.

42

REFERNCIAS

TANAKA, Simone Sawasaki. nalise de sistemas I: sistemas/ Simone Sawasaki Tanaka:


So Paulo: Person Prentice Hall, 2009.
FURLAN, Jos Davi. Modelagem de objetos travs da UML. So Paulo: Makron Books,
1998.
NISCHIMURA, Roberto Yukio
Banco de dados II: sistemas/ Roberto Yukio Nishimura. So Paulo: Person Prentice all,
2009.
SOLER,Luciano
Desenvolvimento de aplicao Web/Luciano Soler, Everson Matias de Moraes.So Paulo:
Pearson Education do Brasil, 2010.
DEITEL, Paul J.; Deitel, Harvey M.
Ajax, rich internet applications e desenvolvimento Web para programadores.
So Paulo: Person Prentice Hall, 2009. (Srie do Programador).
REIS, Jos Lus. O marketing personalizado e as tecnologias de Informao. Lisboa: Centro
Atlntico, 2000.
Perini,Luiz Cludio. Engenharia de software:sistemasII / Luis Cludio Perini, Marco Ikuro
Hisatomi,Wagner Luiz Berto.So Paulo :Person Prentice Hall,2009.
Silva,Flvio de Almeida e desenvolvimento orientado a objetos II: sistemas IV /Flvio de
Almeida e Silva.- So Paulo: Person Prentice Hall,2009.
Freitas, Veronice Programao Web II / Veronice Freitas. So Paulo: Person Education do
Brasil, 2013.
AAKER, David Austin. Criando e administrando marcas de sucesso. So Paulo: Futura,
1996.
Martins, Jos Carlos Cordeiro. Tcnicas para gerenciamento de projetos de software. Rio de
Janeiro: Brasport, 2007.
LEE, Richard C.; TEPFENHART, William M. UML e C++: guia prtico de desenvolvimento a
objeto. So Paulo: Makron Books, 2001.

Você também pode gostar