Portifolio em grupo ads 4º semestre unopar 2015

SUMÁRIO

1 INTRODUÇÃO 3

2 OBJETIVO 4

3 DESENVOLVIMENTO..............................................................................................5

3.1 DIAGRAMAS DA UML..........................................................................................5

3.2 MODELO RELACIONAL NORMALIZADO - MRN................................................9

3.3 PROGRAMAÇÃO ORIENTADA A OBJETOS......................................................14

3.4 DESENVOLVIMENTO WEB................................................................................22

4 CONCLUSÃO.........................................................................................................24

5 REFERÊNCIAS.......................................................................................................25

1 INTRODUÇÃO

Com base em todo material disponibilizado e muita pesquisa, apresentaremos neste trabalho um levantamento dos diagramas mais utilizados na UML estes que são essenciais para uma boa documentação de sistemas. Será apresentado também sobre MRN (Modelo Relacional Normalizado) e DER com MRN aplicado. Em Seguida será elaborado implementação na linguagem C# de funcionários e veículos relacionados ao estudo de caso solicitado. Implementaremos também em PHP da reserva de veículo, da verificação da reserva e da devolução do veículo.

2 OBJETIVO

Este trabalho tem como objetivo familiarizar o leitor com os diagramas mais utilizados para a documentação de sistemas. O conteúdo utilizado para elaborar um banco de dados bem distribuído e orientado através da arquitetura de funcionamento de um SGBD e através da Programação orientada a objetos, como é feito a criação de classes e outros exemplos relacionados ao assunto. Serão exibido aqui implementações em C# e PHP do cadastro de veículos e funcionários o que foi pedido sobre o estudo de caso deixando o leitor familiarizado com o assunto.

3 DESENVOLVIMENTO

3.1 DIAGRAMAS DA UML

Devido ao aumento da complexidade dos projetos de software realizar um planejamento profundo do projeto é crucial. O cliente precisa entender o que o desenvolvedor esta fazendo e precisa ter condições de indicar alterações nas funcionalidades do projeto. Para isso é necessário um canal de comunicação onde a linguagem usada seja compreensível pela equipe de desenvolvimento e pelo cliente. A chave para este processo ser bem sucedido é organizar o processo de desenvolvimento de forma a envolver programadores, analistas e clientes no desenvolvimento do sistema usando uma linguagem que seja de fácil entendimento a todos.

Para isto é preciso adotar uma linguagem padrão que seja aceita e compreendida por toda a equipe de desenvolvimento e pelo cliente. A UML tem sido adotada como esta linguagem padrão. O objetivo dos diagramas é apresentar múltiplas visões do sistema sendo que este conjunto de múltiplas visões é chamado de modelo. Podemos dizer que um modelo UML pode ser visto como um conjunto de diagramas que podem ser examinados e modificados a fim de compreender e desenvolver um sistema de software. No nosso sistema de locação de veículos foram elaborados os seguintes diagramas. Diagrama de caso de uso diagrama de classe, diagrama de sequencia, diagrama de estado e diagrama de implantação.

• DIAGRAMA DE CASO DE USO (CONTROLE DE FROTA)

• DIAGRAMA DE CLASSE (CONTROLE DE FROTA)

• DIAGRAMA DE SEQUENCIA (CONTROLE DE FROTA)

• DIAGRAMA DE ESTADO (CONTROLE DE FROTA)

• DIAGRAMA DE IMPLANTAÇÃO (CONTROLE DE FROTA)

3.2 MODELO RELACIONAL NORMALIZADO - MRN.

Um diagrama entidade relacionamento que não está normalizado chamamos de modelo desnormalizado. Existem as seguintes formas normais: Primeira forma normal (1FN), Segunda forma normal (2FN), Terceira forma normal (3FN), Boyce codd e Quarta forma normal (4FN) seguindo essa sequência não podendo se pular uma forma normal.

Primeira forma normal - 1FN:

Precisamos identificar os atributos dentro de uma entidade que representem o armazenamento de um mesmo dado em locais diferentes. Podemos interpretar como atributos repetidos ou mesmo tabelas aninhadas ou que o atributo contem mais de uma ocorrência. Depois de identificados os atributos devem ser transferidos para uma outra entidade (entidade nova). Esta nova entidade deverá ter relacionamento com a outra de onde foi retirado os atributos, este relacionamento será forte pois a entidade nova precisará da chave primária. Na entidade nova,m a chave primária que veio da entidade forte se tornará uma chave estrangeira, porém fazendo parte da chave primária da nova entidade fraca. Inclusive acontece em alguns casos, um dos atributos retirados pode até fazer parte dessa chave primária tornando se uma chave primária composta.

Neste documento iremos exemplificar através do estudos de Caso Controle de Frota. Muitas empresas estão utilizando frotas próprias para agilizar o trabalho de seus funcionários. Essa é uma medida muito interessante que tem que ser bem gerenciada. Precisamos fazer o gerenciamento das pessoas que utilizam os veículos para não haver usos indevidos e dos veículos que necessitam manutenção, ver se ele está disponível ou não, enfim temos vários controles a fazer.

• Modelo