SISTEMA DE ENSINO PRESENCIAL CONECTADO ANALISE E DESENVOLVIMENTO DE SISTEMAS NOME

ATIVIDADE INTERDISCIPLINAR:
INDIVIDUAL

Londrina 2011

NOME

ATIVIDADE INTERDISCIPLINAR
INDIVIDUAL

Trabalho apresentado ao Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Universidade Norte do Paran - UNOPAR Orientador. Prof. Polyanna P. Gomes Fabris Lus Cludio Perini Roberto Yukio Nishimura Anderson Gonalves

Londrina 2011

SUMRIO 1 INTRODUO...........................................................................................................3 2 DESENVOLVIMENTO...............................................................................................4 3 CONCLUSO...........................................................................................................17 REFERNCIAS..........................................................................................................19

1 INTRODUO Ser Abordada neste trabalho atravs de conhecimento, a documentao de cadastro de usurio da biblioteca. Considerando a tcnica de Modelagem Entidade Relacionamento, ser explicado o que so Entidades e Tabelas, Relacionamentos e Cardinalidade, Atributos, Administrador de dados, modelo conceitual de dados, modelo lgico de dados, modelo fsico de dados. Logo aps ser escolhido um tipo de projeto, onde sero relacionados quais principais componentes utilizados bem como sua funcionalidade em uso com o Visual Studio e linguagem C# (Sharp). Abordaremos tambm os tipos de Modelos geis e Modelos Evolucionrios, identificando cinco modelos de cada tipo, citando as caractersticas marcantes de cada modelo e comentando o seu ciclo de vida. Temas de suma importncia vistos neste segundo semestre e que nos exigiu muito estudo e prtica.

2 DESENVOLVIMENTO

2.1 DOCUMENTAO DE CASO DE USO

Considere um Caso de Uso Controlar Usurio, cujo objetivo cadastrar o usurio da biblioteca. Partindo desse cenrio, elabore a documentao de Caso de Uso. 2.1.1 Casos de Uso O Caso de Uso iniciado e tem como objetivo cadastrar usurio da biblioteca. 2.1.2 Descrio Fazer cadastro do usurio no sistema atravs dos campos a serem preenchidos para que o usurio tenha acesso aos livros da biblioteca. 2.1.3 Ator Atendente. 2.1.4 FLUXO PRINCIPAL 1- Cadastrar o usurio da biblioteca, clicando na opo Cadastro de Usurio no menu principal da biblioteca. 2- Sistema abre nova janela com formulrio de cadastro, composto por campos para preenchimentos de dados pessoais e uma lista de palavras para seleo de rea de interesse. 3- Preencher os dados no formulrio e clica no boto Salvar. 4- Sistema verifica preenchimentos de dados obrigatrios e cadastra

as informaes na base de dados. 6- Sistema exibe tela de confirmao de cadastro. 2.1.5 FLUXOS ALTERATIVOS No passo 2, se o usurio no fornecer algum dado de preenchimento obrigatrio, o sistema exibe uma mensagem O campo obrigatrio e retornar para o passo 1. 2.1.6 PONTOS DE EXTENSO Consultar perfil do usurio e buscar documento no acervo. 2.1.7 CASOS DE USO INCLUDOS Caso de uso Criar perfil inicial do usurio. 2.1.8 PR CONDIO necessrio que o usurio chegue at o atendente solicitando seu cadastro para uso da biblioteca. Para que o cadastro de usurio seja efetuado com sucesso necessrio que o passo 2 sejam preenchidos corretamente todos os espaos em brancos obrigatrios. 2.2 MODELAGEM ENTIDADE RELACIONAMENTO Considerando a tcnica de Modelagem Entidade Relacionamento, explique com suas palavras o que so Entidades e Tabelas, Relacionamentos e Cardinalidade, Atributos e seus tipos, Administrador de dados, modelo conceitual de dados, modelo lgico de dados e modelo fsico de dados. 2.2.1 ENTIDADES

So substantivos, coisas ou objetos do mundo real que possuem caractersticas prprias e que se relacionam entre si, podendo ser representados por objetos concretos e palpveis (pessoa, automvel, livro, animal) ou por objeto abstrato (departamento, conta corrente, emprstimo, endereo). A entidade pode ser representada graficamente atravs de um retngulo internamente nomeado no singular. 2.2.2 RELACIONAMENTOS um conjunto de associaes entre os elementos que tambm tm relevncia quando associados entre sim, e que pode ser encontrada numa descrio textual na lngua portuguesa geralmente como verbos. Podemos completar a definio de relacionamento como o fato, o acontecimento que liga duas entidades, duas coisas ou objetos existentes no mundo real. O relacionamento pode ser binrio ou ternrio e representado atravs de um losango internamente nomeado e ligado a entidades atravs de linhas. 2.2.3 CARDINALIDADE a quantidade de ocorrncia de entidades que podem estar associadas a uma ocorrncia da entidade que se quer analisar. Cardinalidade a regra de negcio entre as entidades envolvidas no relacionamento, o nmero (mnimo e mximo) de ocorrncias de uma entidade relacionada outra. Cardinalidade Mnima Refere-se ao mnimo de ocorrncias de uma entidade em relao outra, possui dois tipos. Opcional (0): Uma ocorrncia de uma entidade no se relaciona com no mnimo nenhuma ocorrncia de outra entidade. Obrigatria (1): Uma ocorrncia de uma entidade se relaciona com no mnimo uma ocorrncia de outra entidade. Cardinalidade Mxima Refere-se ao mximo de ocorrncias de uma entidade em relao outra, possui trs tipos. Um para Um (1:1): Quando uma entidade A se relaciona com no mximo uma entidade B, e vice-versa.

Um para Muitos (1:n): Quando a ocorrncia de uma entidade se relaciona com no mximo muitas ocorrncias de outra. Porm a ocorrncia de outra entidade se relaciona com no mximo uma ocorrncia da primeira. Muitos para Muitos (n:n): Quando a ocorrncia de uma entidade se relaciona com no mximo muitas ocorrncia de outra e viceversa. 2.2.4 ATRIBUTOS So as caractersticas, propriedades ou dados relevantes que sero armazenados sobre cada entidade. O atributo pode ser representado graficamente atravs de uma elipse internamente nomeada, para cada atributo existe um conjunto de valores possveis, e esse conjunto denominado de domnio. Os atributos podem ter diversas classificaes dependendo do seu tipo, como por exemplo: Atributo Simples no so divididos em outras partes. Atributos Compostos podem ser divididos em partes. Atributos Multivalorados conjunto de valores para uma nica instncia da entidade, e representado atravs de uma elipse internamente nomeada com linha dupla. Atributos Derivado atributo cujo valor derivado de outros atributos, e representado atravs de uma elipse internamente nomeada e com a linha tracejada. Atributos Determinantes o atributos que destaca, separa uma ocorrncia de outra ocorrncia da entidade, e representado atravs do sublinha mento do nome do atributo. 2.2.5 ADMINISTRADOR DE DADOS mais conhecido como AD. tarefa que fica geralmente para o gerente de projeto, em alguns casos ela repassada ao coordenador de equipe ou ento a um grupo de analista, mas sob a superviso de um gerente. responsvel pelo projeto lgico do banco de dados (pelo conceitual tambm, pela interface entre analistas de sistemas e analistas de suporte e pelo gerenciamento do dicionrio de dados).

2.2.6 MODELO CONEITUAL DE DADOS Descreve a estrutura de um banco de dados de maneira independente de um SGBD particular e sem levar em conta as caractersticas fsicas dos dados a serem armazenados, podendo ser chamado de modelo de dados abstrato. Esse modelo permite ainda, descrever e representar sob a viso da realidade do ambiente a ser informatizado, sem um compromisso muito forte com regras ou modelos, apenas com a viso das entidades e dos relacionamentos que compem o cenrio. No modelo conceitual a anlise iniciada sobre o ponto de vista do usurio, o principal cliente para o sistema de banco de dados que ser desenvolvido. 2.2.7 MODELOS LGICO DE DADOS Descreve as estruturas que estaro contidas no banco de dados (as entidades), de acordo com as possibilidades permitidas pela abordagem, mas sem considerar nenhuma caracterstica de um SGBD ou atributo, neste modelo e onde comeamos a organizar melhor os dados que sero armazenados, identificamos os tipos dos atributos e algumas regras vazias que podem ser implementadas dentro do prprio banco de dados. Nesta fase e recomendado que sejam aplicadas as formas normais atravs do Modelo Relaciona Normalizado evitando maiores problemas na fase do modelo fsico. 2.2.8 MODELO FSICO DE DADOS Neste modelo a preocupao j fica mais direcionada s caractersticas de armazenamento fsico de banco de dados. Leva em considerao limites imposto pelo SGBD (Sistema Gerenciador de Banco de Dados) e pelos requisitos no funcionais dos programas que acessam os dados. 2.3 DESENVOLVIMENTOS DE PROJETO

2.4 MODELOS DE PROCESSOS DE SOFTWARE Faa uma pesquisa bibliogrfica onde voc dever levantar informaes sobre MODELOS GEIS e MODELOS EVOLUCIONARIOS, onde devera identificar pelo menos 05 (cinco) modelos de cada tipo. Aps identificar os modelos voc deve colocar as caractersticas marcantes de cada modelo, CITAR e EXPLICAR o seu CICLO DE VIDA, comentando as atividades de cada fase do ciclo. 2.4.1 MODELOS GEIS Mtodos geis uma coleo de metodologias baseada na prtica para modelagem efetiva de sistemas baseados em software. As metodologias geis aplicam uma coleo de prticas, guiadas por princpios e valores que podem ser aplicados por profissionais de software no dia a dia. 2.4.2 EXTREME PROGRAMMING (XP) Caractersticas, metodologia criada para produzir o software que a cliente precisa quando ele necessrio. XP encoraja os desenvolvedores a atender as requisies de mudanas dos requisitos do software. Alguns princpios traduzem o esprito da metodologia e deve ser rigorosamente seguidos e planejados, simplicidade, comunicao, feedback, coragem. Etapas As prticas so um conjunto de atividades que devero ser seguidas pelas equipes que desejam utilizar a XP. Os valores apresentados anteriormente somados a estas prticas formam um conjunto entrelaado de boas atitudes. Aplicaes Projetos cujos requisitos so vagos e mudam com frequncia, desenvolvimento de sistemas orientados a objeto desenvolvimento incrementais (ou iterativo), onde o sistema comea a ser implementado logo no incio do projeto e vai ganhando novas funcionalidades ao longo do tempo. Vantagens/Desvantagens - A XP trabalha com uma viso diferente do modelo tradicional em relao ao cliente. Ele sugere que o cliente esteja no dia-a-dia do projeto, acompanhando os passos dos desenvolvedores.

10

2.4.3 SCRUM Caractersticas - O SCRUM um modelo de desenvolvimento gil de software que fornece mtodos para se definir o planejamento, os principais papis de pessoas e a forma de trabalho do time. A ideia do SCRUM justamente definir papis bem especficos para as pessoas envolvidas no projeto. Etapas O produto definido: quais so os seus requisitos? O que realmente o cliente quer? O responsvel por esta tarefa o que chamamos de Proprietrio do Produto. O Proprietrio do Produto define quais so as funcionalidades do programa, criando assim o que chamamos de Product Backlog. Com as prioridades definidas, uma pessoa definida para ser o ScrumMaster, uma espcie de coordenador do projeto. O ScrumMaster, junto com o Proprietrio do Produto e o Time de desenvolvimento definem o que chamamos de Sprints. Cada Sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada perodo tenham um produto apresentvel para o cliente. Os Sprints vo sendo feitos at o Product Backlog acabar e o Proprietrio do Produto definir que o projeto est pronto. Aplicaes desenvolvimento de um sistema web de streaming de vdeo para a Internet. 2.4.4 PRAXIS Caractersticas O PRAXIS (Processo para Aplicativos extensveis e Interativos) um processo de desenvolvimento de software, que so responsabilidade de membros especficos do projeto. Ele tem enfoque educacional, com o objetivo de dar suporte ao treinamento em Engenharia de Software. Etapas O Praxis, que j est em sua segunda verso, possui um ciclo de vida composto por fases, dividida em iteraes. Cada iterao produz um conjunto precisamente definido de documentos, modelos e relatrios, que so os artefatos do processo:

11

Documentos so os artefatos produzidos por ferramentas de processamento de texto ou hipertexto, para fins de documentao dos principais aspectos de engenharia de um projeto, incluindo aspectos selecionados dos modelos e aspectos no modelveis. So, tipicamente, os artefatos entregues aos clientes. Modelos so os artefatos de uma ferramenta tcnica especfica (tais como planilhas, ferramentas de modelagem orientada a objetos e de desenvolvimento), produzido e usado nas atividades de um dos fluxos do processo. Relatrios so artefatos que relatam as concluses de determinadas atividades do projeto. Na construo desses artefatos, o usurio do processo guiado por padres e auxiliado pelos gabaritos de documentos e por exemplos, constantes do material de apoio. Aplicaes Para uso dos modelos de anlise e desenho, indispensvel o uso da ferramenta IBM Rational Rose, verso 2003 ou superior; Para edio do cdigo-fonte recomendado o ambiente de desenvolvimento Borland JBuilder, pelo menos no nvel Foundation e na verso X, mas o cdigo pode ser facilmente transportado para qualquer outro ambiente de desenvolvimento Java; Para uso das baterias de testes, a plataforma Junit, verso 3.8.1 ou superior; Para edio da maioria dos anexos, as ferramentas Microsoft Word e Excel, verso 2003 ou superior; Para visualizao da maioria dos anexos, os respectivos visualizadores distribudos pela Microsoft so suficientes; Para uso do cadastro dos requisitos, recomendado o uso da ferramenta IBM Rational RequisitePro, verso 2003 ou superior; Para edio dos prottipos, qualquer ferramenta capaz de editar HTML, embora a Microsoft Visio tenha sido usada no prottipo de desenho. Vantagens/Desvantagens Os padres do PRAXIS esto em conformidade com os padres de engenharia de software do IEEE, os mais abrangentes e respeitados da rea. O PRAXIS inclui um conjunto de conceitos, tcnicas, fluxos de trabalho e sub processos que cobrem todos os aspectos dos projetos tpicos de software e so baseados em mtodos de aceitao consagrados pela indstria de software. 2.4.5 CRYSTAL (CLEAR)

12

Caractersticas - uma metodologia direcionada a projetos pequenos, com equipes de at seis desenvolvedores. Assim como com SCRUM, o membro da equipe tem especialidades distintas. Existe uma forte nfase na comunicao entre os membros do grupo. Etapas - Toda a especificao e projeto so feitos informalmente, utilizando quadros publicamente visveis. Os requisitos so elaborados utilizando casos de uso, um conceito similar s estrias de usurio em XP, onde so enunciados os requisitos como tarefas e um processo para sua execuo. Aplicaes - Grande parte da metodologia pouco definida, e segundo o autor, isto proposital; a ideia de Crystal/Clear permitir que cada organizao, programe as atividades que parecem adequadas, fornecendo um mnimo de suporte til do ponto de vista de comunicao e documentos. Vantagens/Desvantagens - As entregas das novas verses de software so feitos em incrementos regulares de um ms, e existem alguns subprodutos do processo que so responsabilidade de membros especficos do projeto. 2.4.6 FEATURE DRIVEN DEVELOPMENT Desenvolvimento orientado a funcionalidades Stephen Palmer & John Felsing 2002. Caractersticas - Mtodo gil e adaptativo; Foco nas fases de desenho e construo Interage com outras metodologias, No exige nenhum processo especfico de modelagem, Possui desenvolvimento iterativo, Enfatiza aspectos de qualidade durante o processo e inclui entregas frequentes e tangveis, Suporta desenvolvimento gil com rpidas adaptaes s mudanas de requisitos e necessidades do mercado. Etapas - Consiste de cinco processos principais: Desenvolver um modelo compreensvel (Develop anoverall model), Construir uma lista de funcionalidades (Build a features list), Planejar por funcionalidade (Plan By Feature), Projetar por funcionalidade (Design by feature), Construir por funcionalidade (Build by feature) Aplicaes - Boas Prticas, Modelagem de objetos de domnio (Domain Object Modeling), Explorao e explicao do problema do domnio, resultam em um arcabouo, Desenvolver por funcionalidade (Developing by feature),

13

desenvolvimento e acompanhamento do progresso atravs de da lista de funcionalidades. Antes de prosseguirmos, e para aqueles que esto mais presos ao sistema de numerao decimal (0 a 9), informamos que a nica diferena entre estes dois sistemas o nmero de dgitos que os compem. 2.5 MODELOS EVOLUCIONARIOS O modelo evolucionrio tem como base ideia de desenvolver uma implementao inicial, e interagir ativamente com o cliente de modo a fazer seu aprimoramento por meio de muitas verses at que um sistema adequado tenha sido desenvolvido. 2.5.1 CLSSICO OU CASCATA Este modelo foi idealizado em 1970 por Royce, e tem como caracterstica principal a sequencialidade das atividades. Etapas Baseado em projetos de engenharia clssicos (modelo de engenharia convencional) requer abordagem sistemtica e sequencial. E suas fases so Engenharia de Sistema, Anlise, Projeto, Codificao, Teste, Manuteno. Aplicaes Na primeira fase, a definio de todos os requisitos necessrios para o sistema proposto, na segunda fase Anlise coletado os requisitos para a funcionalidade, desempenho e interfaces e tambm documentado sinto junto com o cliente. Na face de Projeto, tem a finalidade de detalhamento tcnico. A codificao a fase que resulta os programas construdos, conforme documentao na fase de projeto. Comea a fase de teste, so realizadas atividades para descobrir possveis erros no sistema. Na ultima fase, est previsto mudanas no software aps a entrega ao cliente, ests mudanas provocadas por adaptao ao meio externo ou novas funcionalidades. Vantagens/Desvantagens - Os projetos reais no seguem um fluxo sequencial, dificuldade de mudanas depois de iniciado, dificuldade de declarao de todas as exigncias do cliente. 2.5.2 RATIONAL UNIFIED PROCESS

14

O RUP, abreviao de Rational Unified Process (ou Processo Unificado Racional), um processo proprietrio de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora uma abreviao de IBM Rational Unified Process. O RUP usa a abordagem da orientao a objetos em sua concepo e projetado e documentado utilizando a notao UML (Unified Modeling Language) para ilustrar os processos em ao. um processo considerado pesado e preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes projetos, porm o fato de ser amplamente customizvel torna possvel que seja adaptado para projetos de qualquer escala. As fases indicam a nfase que dada no projeto em um dado instante. O RUP divide o projeto em quatro fases diferentes: Fase de Concepo - A fase de concepo contm os workflows necessrios para que as partes interessadas concordem com os objetivos, arquitetura e o planejamento do projeto. Fase de Elaborao - A fase de elaborao ser apenas para o projeto do sistema, buscando complementar o levantamento / documentao dos casos de uso. Fase de Construo - Na fase de construo, comea o desenvolvimento fsico do software, produo de cdigos, testes alfa e beta. Fase de Transio - Nesta fase ocorre a entrega do software, realizado o plano de implantao e entrega, acompanhamento e qualidade do software. 2.5.2 INCREMENTAL Caractersticas - Combina elementos do modelo sequencial linear com a filosofia interativa da prototipagem. Cada sequncia linear produz um incremento. Etapas Exploratria, o objetivo trabalhar com o cliente a partir de uma primeira especificao at atingir o produto final.

15

Aplicaes Para sistemas pequenos a mdios; Para partes de grandes sistemas, por exemplo, para a interface com o utilizador; Para sistemas com curto tempo de vida. Por exemplo: Se fssemos desenvolver um site, no primeiro incremento teramos as funcionalidades sobre a empresa, contato e produtos. Em um segundo incrementos teriam acesso restrito para clientes, newsletter, enquete e assim se seguiria durante todo o processo de desenvolvimento. Quando este modelo usado, o primeiro incremento tido como o ncleo do sistema. Ele usado pelo cliente e ento necessrio fazer um plano para o prximo incremento como resultado do uso/avaliao. Vantagens/Desvantagens - O plano visa melhorar o ncleo e adicionar novas funcionalidades, que por sua vez sero testadas e alteradas para adequarem s solicitaes do cliente e assim por diante. A grande diferena do modelo incremental que a cada incremento o cliente j possui um modelo utilizvel e aprovado. Porm resulta em alguns problemas como falta de visibilidade do processo, resulta muitas vezes em sistema mal estruturados e pode necessitar do uso de linguagens de desenvolvimento rpido. 2.5.3 ESPIRAL Caractersticas: - Foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento, a anlise de riscos que falta a esses paradigmas. Tambm mescla o modelo sequencial linear com o da prototipagem. Oferece potencial para desenvolvimento rpido de verses incrementais do software. Nos primeiros incrementos podem ser usados papel ou prottipo. So utilizadas as seguintes tarefas: Comunicao com o cliente, Planejamento: tarefa necessria para definir recursos, prazos e outras informaes relacionadas ao projeto. Etapas Elaborar objetivos, restries e alternativas para entidades de software. Avaliar alternativas com relao aos objetivos e restries, e identificar as principais fontes de riscos. Elaborar a definio das entidades de software em um projeto. Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco. Aplicaes Planejamento: define recursos, referencias de tempo

16

e outras informaes do projeto. Anlise de risco: levantamento de riscos tcnicos e de gerenciamento. Engenharia: Constri uma ou mais representaes da aplicao. Construo e release: constri, testa, instala e do suporte ao usurio (documentao e treinamento). Avaliao do cliente, obter feedback com base na representao do software criado durante a fase de engenharia e implementado na fase de construo. Vantagens/Desvantagens Atualmente a abordagem mais realstica, desenvolvedor e cliente tm a capacidade de entender e reagir aos riscos em cada etapa exige experincia na determinao de riscos e disso depende o sucesso do projeto. 2.5.4 MONTAGEM DE COMPONENTES Caractersticas Incorpora as caractersticas de tecnologias orientadas a objetos no modelo espiral, a atividade de engenharia comea com a identificao de classes candidatas, se a classe existe ela ser reutilizada se a classe no existe, ela ser desenvolvida nos moldes do paradigma de Orientao a Objeto. Etapas Processo baseado na reutilizao sistemtica de componentes; Anlise de requisitos; Anlise de componentes; Modificao dos requisitos; Desenho do sistema; Desenvolvimento e integrao; Validao. Vantagens/Desvantagens Reduz quantidade de cdigo a desenvolver, conduz a um processo mais rpido, reduz custo de desenvolvimento. Requisitos podem no ser cumpridos exatamente, a evoluo do sistema pode no estar totalmente sob controle visto que os componentes podem ser desenvolvidos por terceiros.

17

3 CONCLUSO Como vimos, este trabalho resultado de um estudo que exigiu muita anlise e reflexo. Pode-se concluir que, a informatizao de fato um dos principais responsveis se no o principal, pelo o desenvolvimento da sociedade, tanto sociolgico, empresarial, cultural, etc. Atravs do estudo de um Caso de Uso, temos a oportunidade de visualizar graficamente elementos do mundo real, observando a documentao necessria para compreenso do trabalho a ser realizado. A utilizao do modelo Entidade Relacionamento de suma importncia para representao grfica daquilo que queremos representar facilitando a compreenso daqueles envolvidos na construo do projeto. Os modelos geis e Evolucionrios que so apresentados nesse trabalho mostram a necessidade em eleger modelo de ciclo de vida, pois influenciaria de forma significativa no desenvolvimento de um produto, onde o objetivo principal um resultado que demonstre qualidade, tanto no andamento, e principalmente no seu resultado final.

18

REFERNCIAS http://pt.wikipedia.org/wiki/Administrador_de_banco_de_dad os http://www.infoescola.com/profissoes/administrador-debanco-de-dados/ http://www.macoratti.net/cbmd1.htm http://www.luis.blog.br/relacionamento-entre-entidades-tipose-cardinalidade.aspx http://www.sqlmagazine.com.br/Colunistas/Reinaldo/05_Mod elagem_P2.asp http://www.devmedia.com.br/ http://www.luis.blog.br/modelagem-conceitual-modeloconceitual-de-dados.aspx http://www.luis.blog.br/modelagem-de-dados-modeloconceitual-modelo-logico-e-fisico.aspx http://pt.scribd.com/doc/6584442/Modelagem-Conceitual-deDados http://www.luis.blog.br/modelagem-de-dados-modeloconceitual-modelo-logico-e-fisico.aspx http://pt.wikipedia.org/wiki/Modelagem_de_dados http://www.devmedia.com.br/post-368-Por-que-construir-umModelo-de-Dados-Logico-Parte-I.html http://pt.wikipedia.org/wiki/Modelagem_de_dados http://www.luis.blog.br/modelagem-de-dados-modeloconceitual-modelo-logico-e-fisico.aspx http://www.macoratti.net/vbn_bas1.htm http://msdn.microsoft.com/pt-br/vbasic/ms789117 http://msdn.microsoft.com/pt-br/library/dd30h2yb.aspx http://www.macoratti.net/vbnet_4.htm http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Seis_Disciplinas_ de_Engenharia

19

REFERNCIAS MARTINS, Paulo Roberto; PAIANO, Valessa C. Linguagens e Tcnicas de programao I. Ed. So Paulo: Pearson Education do Brasil, 2009. ARAMAN, Eliane Maria de Oliveira; CAZETTA, Jenai Oliveira. Fundamentos de lgica e matemtica discreta. Ed. So Paulo: Pearson Education do Brasil, 2009. ABNT NBR 6023 AGO. 2002 Informao e Documentao Referncia Elaborao.