Porto Alegre do Norte-MT 2015
BENONE TIMO NETO
DESENVOLVIMENTO DE SISTEMAS II
SISTEMA DE ENSINO PRESENCIAL CONECTADO Análise e Desenvolvimento de Sistemas
Porto Alegre do Norte-MT 2015
s
Trabalho de Analise e desenvolvimento de sistemas, apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de, Análise Orientada a Objetos II, Banco de Dados II, Programação Orientada a Objetos e Programação Web I.
Prof.ª Luis Claudio Perini Prof.ª Roberto Y. Nishmura Prof.ª Márcio Roberto Chiaveli Prof.ª Veronice de Freitas Adriane Ap. Loper
BENONE TIMO NETO
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................... 3
2 OBJETIVO......................................... .......................................................................4 3 DESENVOLVIMENTO.............................................................................................5
3.1 Analise Orientada a Objeto II.................. .................................................................5
3.1.1 UMl..................................................................................................................5
3.1.2 Diagrama de Caso de Uso............................ .................................................7
3.1.3 Diagrama de Classes.......................... ............................................................8
3.1.4 Diagrama de objetos................................ ......................................................9
3.1.5 Diagrama de Colaboração...................... ......................................................10
3.1.6 Diagrama de Sequência........................ ........................................................11
3.2 Banco de DadosII............................... .....................................................................12 3.2.1- Modelo Relacional Normalizado-MRN........... ...............................................12
3.3 Programação Orientada a Objetos............... .........................................................15 3.4 Programação Web I.............................. ...................................................................17 4 CONCLUSÃO........................................ .................................................................21 REFERÊNCIAS BIBLIOGRÁFICAS......................... .......................................................22
3
1 INTRODUÇÃO
Abordaremos os seguintes assuntos contexto abaixo, banco de
dados, programação orientado a objeto, programação web I, e análise orientada a
objeto onde falaremos sobre as suas aplicações e seu mecanismo de funcionamento
e buscando saber as diferença entre eles e exemplos para que o leitor fique mais
familiarizado com o conteúdo do trabalho.
.
4
2 OBJETIVO
Tenho como objetivo me especializar de maneira que venho a
conseguir suprir o mercado com minha especialização oferecendo uma melhor
maneira para desenvolver software de boa qualidade. Visando atender o mercado
de software e possibilitando melhor desempenho e automação nas empresas onde o
projeto for desenvolvido.
5
3 DESENVOLVIMENTO
3.1 ANÁLISE ORIENTADA A OBJETOS II
3.1.1 UML
A UML (Unified Modeling Language), que significa Linguagem Unificada de
Modelagem é uma linguagem padrão para modelagem orientada a objetos. Ela
surgiu da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE
(Jacobson). Esta linguagem de modelagem não proprietária de terceira geração, não
é um método de desenvolvimento. Têm como papel auxiliar a visualizar o desenho e
a comunicação entre objetos. Ela permite que desenvolvedores visualizem os
produtos de seu trabalho em diagramas padronizados, e é muito usada para criar
modelos de sistemas de software.
Além de fornecer a tecnologia necessária para apoiar a prática de
engenharia de software orientada a objetos, a UML poderá ser a linguagem de
modelagem padrão para modelar sistemas concorrentes e distribuídos. Utiliza-se de
um conjunto de técnicas de notação gráfica para criar modelos visuais de software
de sistemas intensivos, combinando as melhores técnicas de modelagem de dados,
negócios, objetos e componentes. É uma linguagem de modelagem única, comum e
amplamente utilizável.
Embora com a UML seja possível representar o software através de
modelos orientados a objetos, ela não demonstra que tipo de trabalho deve ser feito,
ou seja, não possui um processo que define como o trabalho tem que ser
desenvolvido. O objetivo então é descrever "o que fazer", "como fazer", "quando
fazer" e "porque deve ser feito". É necessária a elaboração completa de um
dicionário de dados, para descrever todas as entidades envolvidas, refinando, com
isso, os requisitos funcionais do software.
Os Diagramas da UML estão divididos em Estruturais e
Comportamentais.
6
Diagramas Estruturais
De Classe: Este diagrama é fundamental e o mais utilizado na UML
e serve de apoio aos outros diagramas. O Diagrama de Classe mostra o conjunto de
classes com seus atributos e métodos e os relacionamentos entre classes.
De Objeto: O diagrama de objeto esta relacionado com o diagrama
de classes e, é praticamente um complemento dele. Fornece uma visão dos valores
armazenados pelos objetos de um Diagrama de Classe em um determinado
momento da execução do processo do software.
De Componentes: Está associado à linguagem de programação e
tem por finalidade indicar os componentes do software e seus relacionamentos.
De implantação: Determina as necessidades de hardware e
características físicas do Sistema.
De Pacotes: Representa os subsistemas englobados de forma a
determinar partes que o compõem.
De Estrutura: Descreve a estrutura interna de um classificador.
Diagramas Comportamentais
De Caso de Uso (Use Case): Geral e informal para fases de
levantamento e análise de Requisitos do Sistema.
De Máquina de Estados: Procura acompanhar as mudanças sofridas
por um objeto dentro de um processo.
De Atividades: Descreve os passos a serem percorridos para a
conclusão de uma atividade.
De Interação: Dividem-se em:
De Sequência: Descreve a ordem temporal em que as mensagens
são trocadas entre os objetos.
Geral interação: Variação dos diagramas de atividades que fornece
visão geral dentro do sistema ou processo do negócio.
De comunicação: Associado ao diagrama de Seqüência,
complementando-o e concentrando-se em como os objetos estão vinculados.
De tempo: Descreve a mudança de estado ou condição de uma instância de uma
classe ou seu papel durante o tempo.
7
Segue abaixo alguns exemplos de UML e seu diagramas.
DIAGRAMAS MAIS ULTILIZADOS NA UML
Esse subtitulo tem como função ser um guia rápido de consulta aos
principais diagramas da UML.
3.1.2 Diagrama de Caso de Uso
Representa o conjunto de comportamentos de alto nível que o
sistema deve executar para um determinado ator. É o diagrama mais simples, e não
há necessidade de grandes detalhamentos.
A figura acima ilustra um caso de uso geral, mas é recomendado
que eles sejam desenvolvidos para cada cenário. As setas de includes e extends,
8
indicam, respectivamente, obrigatoriedade e opção de se realizar determinada ação.
3.1.3 Diagrama de Classes
Representa uma coleção de classes e seus inter-relacionamentos.
Para que serve o diagrama de classe?
O diagrama de classes serve para demonstrar de uma forma visual
as classes e seus relacionamentos.
O diagrama de classes, é o mais importante de todos os diagramas
da UML, pois quando se tem uma visão de todas asclasses (principalmente da
camada de negócio) o programador já sabe que classe criar e qual se relacionam
com qual.
O diagrama de classe é bastante parecido com o MR (Modelo
Entidade Relacionamento), pois na maioria das vezes as classes correspondem às
tabelas. Mas atenção nem toda tabela é classe.
Figura de diagrama de classes.
9
3.1.4 Diagrama de objetos
Representa um retrato, em tempo de execução, dos objetos do
software e seus inter-relacionamentos. O diagrama de objetos é uma variação do
diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama
de objetos mostra os objetos que foram instanciados das classes. O diagrama de
objetos é como se fosse o perfil do sistema em um certo momento de sua execução.
A mesma notação do diagrama de classes é utilizada com duas
exceções: os objetos são escritos com seus nomes sublinhados e todas as
instâncias num relacionamento são mostradas. Os diagramas de objetos não são tão
importantes como os diagramas de classes, mas eles são muito úteis para
exemplificar diagramas complexos de classes ajudando muito em sua compreensão.
Diagramas de objetos também são usados como parte dos diagramas de
10
colaboração (passou a se chamar comunicação na uml 2.0), onde a colaboração
dinâmica entre os objetos do sistema são mostrados.
Figura de diagrama de objeto
3.1.5 Diagrama de Colaboração
Representa uma coleção de objetos que trabalham em conjunto para atender
algum comportamento do sistema.
A grande diferença entre um diagrama de colaboração e um de
sequência consiste no fato de que o tempo não é mais representado por linhas
verticais, mas sim através de uma numeração, que pode ser de duas formas:
Simples (1,2,3,...)
Composta (1.1, 1.2, 1.2.1, ...)
Um objeto é representado como um retângulo, contendo no seu
interior um rótulo, que informa o nome do objeto e o nome da classe, separados por
dois pontos. Detalhe: ambos podem ser omitidos.
11
3.1.6 Diagrama de Sequência
Representa uma perspectiva, orientada por tempo, da colaboração entre os
objetos. Descreve a ordem temporal em que as mensagens são trocadas entre os objetos.
Esses são alguns exemplos.
12
3.2 BANCO DE DADOS II
3.2.1- Modelo Relacional Normalizado-MRN
O que é o Modelo Relacional Normalizado –MRN?•
Para que serve?
Qual a funcionalidade do MRN?
Quais são os objetivos?
Quais são os ganhos ao fazer a normalização do Banco de
Dados? O modelo relacional Normalizado é um modelo de dados, adequado a ser o
modelo subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que
se baseia no princípio em que todos os dados estão guardados em tabelas (ou,
matematicamente falando, relações). Toda sua definição é teórica e baseada na
lógica de predicados e na teoria dos conjuntos .O conceito foi criado por Edgar Frank
Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared
Data Banks". Na verdade, o modelo relacional foi o primeiro modelo de dados
descrito teoricamente, os bancos de dados já existentes passaram então a ser
conhecidos como (modelo hierárquico ,modelo em rede ou Codasyl e modelo de
listas invertidas).O MRN apareceu devido às seguintes necessidades: aumentar a
independência dos dados nos sistemas operacionais de banco de dados; prover um
conjunto de funções apoiadas em álgebra relacional para armazenamento e
recuperação dedados; permitir processamento AD HOC(Em engenharia de software,
a expressão ad hoc é utilizada para designar ciclos completos de construção de
softwares que não foram devidamente projetado em razão da necessidade de
atender a uma demanda específica do usuário, ligada a prazo, qualidade ou custo).
O modelo relacional revelou-se ser o mais flexível e adequados ao solucionar os
vários problemas que se colocam no nível de concepção e implementação da Base
de Dados. A estrutura fundamental do modelo relacional é a relação (tabela). Uma
relação e construída por um ou mais atributos (campos) que traduzem o tipo
dedados a armazenar. Cada instancia do esquema (linha) e chamada de tupla
(registro). O modelo relaciona não tem caminhos pré-definidos para se fazer acesso
aos dados como nos modelos que o procedem. O modelo relacional implementa
13
estruturas de dados organizados em relações. Porém, para trabalhar com essas
tabelas, algumas restrições precisam ser impostas para evitar aspectos indesejáveis,
como: repetição de informação, incapacidade de representar parte da informação e
perda de informação. Essas restrições são: Integridade referencial, chaves e
integridades de junções de relações.
Tabela de Modelo Relacional normalizado – Cliente Conta corrente
O Modelo Entidade Relacionamento é a base para a criação de um banco dedados.
Para realizarmos um projeto de banco de dados, podemos dividi-lo em três partes:
inicialmente o modelo conceitual, depois o modelo lógico, e finalmente o modelo
físico. Realizar os três modelos é de extrema importância para que o analista
desistem as compreenda a base de dados que ele vai criar. O administrador de
banco de dados (DBA) e o administrador de dados(AD) consegue separar muito bem
esses três modelos
O primeiro passo e fazer o modelo conceitual; depois que ele já
estiver completo podemos transformá-lo em um modelo lógico, em que a estrutura
fica mais evidente para os analistas de sistemas e programadores. Uma vez definido
qual o SGBD a se utilizado, podemos passar esse modelo lógico para o físico. Com
o modelo físico concluído, já e possível escrever os comandos necessários para a
criação do esquema no banco de dados. Hoje em dia existem ferramentas CASE
que auxiliam o dia a dia dos analistas, DBAs e ADs.
MODELO RELACIONAL NORMALIZADO – MRN Num projeto de
banco de dados é necessário identificar os dados e fazer com que estes
representem eficientemente o mundo real. Os SGDB – Sistemas Gerenciadores de
Bancos de Dados ou SGBDR – Sistemas Gerenciadores de Bancos de Dados
Relacionais são baseados no Modelo Relacional de Dados, que tem o princípio de
que todos os dados são guardados em tabelas. Conceito criado por Edgar Frank
Codd em 1970. Foi o primeiro modelo de dados descrito teoricamente. O Modelo
Entidade Relacionamento apresenta algumas situações de difícil implementação
prática. Para resolver isso, Codd propôs um processo de Normalização de Dados
(ou normalização de tabelas) que aplica uma série de regras às tabelas de um banco
de dados, para verificar se estas estão corretamente projetadas. O objetivo da
normalização é evitar problemas provocados por falhas no projeto do banco de
dados, eliminando redundâncias e evitando problemas com inserção, eliminação e
atualização de dados. Com a normalização bem sucedida, o espaço de
14
armazenamento de dados diminui, as tabelas podem ser atualizadas com maior
eficiência. Normalmente após a aplicação das Regras de Normalização, algumas
tabelas acabam sendo divididas em duas ou mais tabelas. Esse processo causa a
simplificação dos atributos de uma tabela, contribuindo significativamente para a
estabilidade do modelo de dados, reduzindo-se consideravelmente as necessidades
de manutenção. Inicialmente Codd estabeleceu três Formas Normais, chamando-as
de Primeira, Segunda e Terceira Formas Normais. Uma definição mais forte da
Terceira Forma Normal foi depois proposta por Boyce e Codd, chamada Forma
Normal Boyce-Codd. Depois uma Quarta e uma Quinta Formas Normais foram
propostas, baseadas nos conceitos de dependências multivaloradas e de junção,
respectivamente: • Primeira Forma Normal, ou 1FN • Segunda Forma Normal, ou
2FN • Terceira Forma Normal, ou 3FN • Forma Normal Boyce-Codd, ou FNBC ou
BCNF • Quarta Forma Normal, ou 4FN
5. 4 • Quinta Forma Normal, ou 5FN Cada uma das formas normais
representa uma condição mais forte que a anterior na lista, mas para a maioria dos
efeitos práticos, considera-se que as bases de dados estão normalizadas se
aderirem à Terceira Forma Normal. “Outro ponto a notar é que os projetistas de um
banco de dados não precisam normalizar até a forma normalmente mais alta
possível. As relações podem permanecer em um estado de normalização mais
baixo, como 2FN, por razões de desempenho.” (ELMASRI; NAVATHE, 2005 apud
NISHIMURA, 2009, p. 81). O processo é sequencial, iniciando pela 1FN. Não é
possível “pular” uma forma normal, assim como não é possível fazer uma forma
normal errada e passar para a próxima. Se uma tabela obedece às regras de uma
forma normal, esta obedece igualmente às regras das formas normais anteriores.
Uma tabela está na Primeira Forma Normal quando seus atributos não contêm
grupos de Repetição, ou também, a 1FN requer que todos os valores de colunas em
uma tabela sejam atômicos (indivisíveis). É necessário identificar atributos que
representam o armazenamento de um mesmo dado em locais diferentes; atributos
repetidos; atributos com mais de uma ocorrência. Uma “regra de ouro” para a 1FN é
não misturar assuntos em uma mesma tabela (BATTISTI, 2004).
Exemplo de MRN
15
Código_cliente Nome Telefone Rua Bairro Cep
C0000001 Benone
Timo
6684255512 Rua das
palmeira
36
Jardim do
endem
78652000
C0000002 Pedro
Canabrava
6599999516 Rua 100
Nº 100
Vale dos
esquecidos
75642001
Exemplo de DER aplicando o MRN.
3.3 PROGRAMAÇÃO ORIENTADA A OBJETOS
O c# (CSharp) é uma linguagem de programação voltada ao
desenvolvimento de sistemas orientados a objetos, porém aceita a programação
estruturada e imperativa como as utilizada em C, Pascal, entre outras. A linguagem
faz parte da plataforma .NET da Microsoft e seu mentor foi Anders Hejlsberg, o qual
hoje é Distinguished Engineer na empresa. Ele também é o arquiteto de algumas
linguagens da Borland, por exemplo Turbo Pascal e Delphi. Durante o
16
desenvolvimento da .NET, algumas bibliotecas de classes – class libraries’ foram
elaboradas utilizando um compilador/linguagem chamada Simple Managed C
(SMC),contudo, em 1999, Anders e sua equipe de desenvolvimento resolveram dar
o nome de COOL. Este nome não predominou, pois em 2000 na Profissional
Developer Conference (PDC) foi apresentada a .NET e a linguagem teve seu nome
mudado e apresentado como C#
Exemplo de um programa para imprimir um mensagem na tela:
1 // exemplo de simples programa em c#
2
3 using system; // diretiva using com espaço de nomes system.
4
5 class progMensagem // início do programa
6 { // inicio do corpo da classe (progMensagem)
7 static void Main (string [ ] args) //Métodos de execução com
parametro args.
8 { //início do corpo do método Main
9 // chamada para a Classe Console e Método de escrita
10 console.Writeline ( “primeiro programa: imprimindo mensagem na
tela”)
11 } // fim da método main
12 } // fim da classe (programa)
Neste exemplo foi colocado em cada linha de comando um
mensagem de identificação para cada linha de código.
Um programa consiste de pelo menos uma classe definida pelo
programador. Isto significa que a pessoa que está desenvolvendo o programa deve
dar um nome para tal classe e este nome deve ser precedido pela palavra-chave
class. As palavras-chaves também chamadas de palavras reservadas, são de uso
da linguagem, não se pode criação de atributos, nomes de classes etc. com o
mesmo nome. Por exemplo, não se pode criar um atributo com o nome de console,
pois ela é uma palavra reservada e uma classe também.
17
3.4 PROGRAMAÇÃO WEB I
Um ponto importante: aplicativos web são executados através de um
browser. Diferente de um aplicativo desktop que tem sempre um arquivo executável
(o .exe para Windows Users), os aplicativos web são uma coleção de páginas HTML
interligadas entre si. Sim, como se fosse um site. Códigos PHP são interpretados por
um servidor que converte tudo em HTML e envia esse “resultado” para o browser.
Exemplos de aplicativos web:
Facebook (sim, o Facebook é um site, mas sites que utilizam
linguagem de programação web como o PHP são aplicativos)
Gmail
BaseCamp
Qualquer aplicativo que é executado através de um browser
Através da imagem acima, pode ficar um pouco mais fácil de
entender qual o papel do servidor PHP.
Primeiramente vamos nos localizar. Nós somos o usuário que está
utilizando um aplicativo web qualquer desenvolvido em PHP através do browser.
Ao digitar o endereço do site ou do aplicativo, uma requisição HTTP
18
é feita pelo browser ao servidor web (lembre-se do http:// no início de cada URL)
solicitando que aquela página seja exibida ao usuário.
O servidor web é onde está instalado o interpretador PHP (servidor
PHP). Esse servidor é responsável por “traduzir” ou interpretar o código da página
solicitada que está em PHP para HTML.
O servidor PHP pode acessar banco de dados, ler arquivos, enviar
emails e efetuar diversas outras tarefas competentes às linguagens de programação
web para concluir a tradução do código em HTML.
O servidor PHP converte o código em HTML.
O servidor web envia o código HTML para o usuário que o solicitou.
E agora, ficou mais simples? Espero que sim…
Bom, aproveitando o gancho, agora vemos a necessidade de ter um servidor PHP
para interpretar os códigos e retornar HTML para o browser, certo? De acordo com a
imagem, é bem visível que para isso é preciso ter dois computadores, um para fazer
o papel de servidor e o outro onde o usuário utiliza o aplicativo. Mas graças a um
endereço de IP especial (127.0.0.1 ou o localhost) é possível ter o servidor PHP
instalado no mesmo computador em que o usuário está acessando a aplicação web.
Esse “localhost” refere-se ao próprio computador.
Quando você digita no browser, por exemplo, o endereço
http://www.facebook.com.br, o seu browser envia uma requisição para o servidor
onde o site Facebook está hospedado. Esse servidor pode estar localizado
fisicamente em qualquer lugar do mundo!
Caso você digitou no seu browser localhost, provavelmente uma
mensagem de erro surgiu: Página não encontrada ou algo assim. Mas não se
preocupe, para que o servidor funcione no seu computador, primeiro é necessário
instalá-lo. :)
Instalando o servidor PHP
Para transformar o nosso computador em um servidor web com
interpretador PHP é preciso instalar dois programas:
Apache – software que vai transformar o seu computador em um
19
servidor web. É dele a capacidade de fazer o seu computador atender requisições
HTTP.
PHP – software responsável por interpretar códigos PHP e converter
em HTML. Funciona junto ao Apache que recebe as requisições HTTP e envia os
códigos para o interpretador PHP que converte em HTML. Daí o Apache retorna o
código HTML para o usuário.
Para se ter um servidor web completo, e bem configurado, a tarefa
costuma ser um pouco árdua, mesmo para usuários do Windows.
Exemplificando.
O localhost que acabamos de acessar no browser nada mais é do
que o servidor PHP sendo executado a partir de uma pasta criada após a instalação
do XAMPP, conhecida como Document Root, ou raiz de documentos. Ou seja, todo
e qualquer arquivo a ser criado com código em PHP deverá ser gravado no
document root para que possa ser acessado através do localhost.
O endereço do document root varia de acordo com o sistema
operacional utilizado:
Windows: c:\var\www
20
Linux: /opt/lampp/htdocs
Simplificando, se existir o arquivo c:\var\www\olamundo.php ele será
acessível através do endereço http://localhost/olamundo.php e assim por diante,
como mostra a lista abaixo:
c:\var\www\exercicio\index.php = http://localhost/exercicio/index.php
c:\var\www\cadastro-de-telefones\telefones.php =
http://localhost/cadastro-de-telefones/telefones.php
O mesmo vale para o Linux:
/opt/lampp/htdocs/olamundo.php = http://localhost/olamundo.php
/opt/lampp/htdocs/exercicio/index.php =
http://localhost/exercicio/index.php
/opt/lampp/htdocs/cadastro-de-telefones/telefones.php =
http://localhost/cadastro-de-telefones/telefones.php
Tux LinuxUsuários do Linux terão um trabalhinho a mais, pra variar.
Será necessário dar permissão de escrita na pasta /opt/lampp/htdocs antes de
gravar arquivos ou criar qualquer pasta lá dentro. Para isso, acesse o terminal e
digite:
sudo chmod -R 777 /opt/lampp/htdocs
Com esse comando, a pasta htdocs terá permissão de escrita e todo
o conteúdo dela também, incluindo as subpastas.
Vamos então criar nosso primeiro arquivo PHP. Abra o seu editor de
texto favorito (Bloco de Notas, Gedit, vi, vim, Sublime, etc) e digite o seguinte código:
<?php
echo "Jesus te Ama";
?>
O comando echo diz ao PHP para imprimir na tela o que estiver
depois dele. Nesse caso, será impresso Jesus te Ama sem as aspas. A função das
aspas é informar ao PHP que o que está entre elas é uma string, ou seja, uma
variável do tipo texto, e deve ser impressa exatamente como foi escrita. Ah, e todas
as linhas de comando em PHP sempre terminam com ponto-e-vírgula.
21
O verbo “imprimir” utilizado aqui não diz respeito à ação de imprimir
algo no papel através de uma impressora, mas de exibir o resultado na tela, ou seja,
imprimir o resultado na tela.
Salve o arquivo com o nome de jesusteama.php dentro do seu
document root (c:\var\www no Windows e /opt/lampp/htdocs no Linux).
Agora acesse o arquivo através do seu navegador favorito entrando
no endereço http://localhost/jesusteama.php.
CONCLUSÃO
Os tratamentos que no decorrer desse trabalho foram apresentados
tiveram grande importância, porque entendermos melhor todos os procedimentos
realizados ao longo da atividade. Trazendo a nós a visão de qual tratamento é mais
adequado para o caso, e os benefícios que cada um nos proporciona.
Após concluir a atividade tem-se uma visão mais abrangente
adquirida das nossas fontes e pesquisas sobre os assuntos exigidos pelos
professores.
22
Este trabalho foi muito importante para o meu conhecimento,
compreensão, e o aprofundamento dos temas estudados, uma vez que permitiram
conhecer melhor Linguagens de Programação e programação orientada a objeto, ter
noções de Banco de Dados, programação web, o trabalho me deixou muito
familiarizado com o conteúdo.
Referencias
http://www.profissionaisti.com.br/2011/07/os-principais-diagramas-da-uml-resumo-rapido/
http://www.infoescola.com/engenharia-de-software/uml/
https://pt.wikipedia.org/wiki/Diagrama_de_objetos
https://www.youtube.com/watch?v=942MNuJnzl
https://www.youtube.com/watch?v=eiBbG9bVljs
Banco de dados II: sistemas/ Roberto Yukio Nishimura. -São Paulo: Person Prentice Hall, 2009
23
http://www.delphi.ufba.br/aspNetCsharp/apostilas/apostilas.html
http://www.cpdee.ufmg.br/~jramirez/disciplinas/cdtn/programa.pdf
http://www.fredericomarinho.com/introducao-ao-desenvolvimento-web-com-php-aula-1-preparando-o-ambiente-para-iniciar-a-programacao/
http://www.ebah.com.br/content/ABAAAfdpYAG/linguagem-programacao-web