Palmas 2012
ADSON JOSÉ HONORI DE MELO GERISVALDO DA COSTA MACEDO MÁRIO CÉSAR CARNEIRO FRANCO
MAURO MARTINS LEAL
SISTEMA DE ENSINO PRESENCIAL CONECTADO ANÁLISE DE DESENVOLVIMENTO DE SISTEMAS
PORTFÓLIO DE GRUPO 3º SEMESTRE Diagrama de atividades, modelagem de dados e programação orientada a objetos na linha de frente da construção de sistemas informatizados.
Palmas 2012
PORTFÓLIO DE GRUPO 3º SEMESTRE Diagrama de atividades, modelagem de dados e programação orientada a objetos na linha de frente da construção de sistemas informatizados.
Trabalho apresentado às disciplinas Algoritmos e Estruturas de Dados, Análise de Sistemas, Seminário III, Desenvolvimento Orientado a Objetos I e Banco de Dados II da Universidade Norte do Paraná - UNOPAR Prof(s). : Marcio Roberto Roberto Y. Nishimura Polyanna Gomes Merris Mozer
ADSON JOSÉ HONORI DE MELO GERISVALDO DA COSTA MACEDO MÁRIO CÉSAR CARNEIRO FRANCO
MAURO MARTINS LEAL
SUMÁRIO
1 INTRODUÇÃO .....................................................................................................3
2 DESENVOLVIMENTO .........................................................................................4
2.1 UML – DIAGRAMA DE ATIVIDADES...............................................................4
2.1.1 CENÁRIO ATUAL .........................................................................................4
2.1.1.1 GERENCIAR DEVOLUÇÃO......................................................................4
2.1.1.2 GERENCIAR EMPRÉSTIMOS..................................................................5
2.1.1.3 MANTER LIVROS .....................................................................................6
2.1.1.4 MANTER USUÁRIOS................................................................................7
2.1.2 NOVO CENÁRIO ..........................................................................................7
2.2 MODELO CONCEITUAL COM MRN APLICADO...........................................10
2.3 MAPEAMENTO OBJETO RELACIONAL .......................................................11
2.4 LISTA ORDENADA ........................................................................................16
3 CONCLUSÃO ....................................................................................................18
REFERÊNCIAS.........................................................................................................19
3
1 INTRODUÇÃO
O analista de sistemas deve garantir o alinhamento entre tecnologia
e estratégias organizacionais, os projetos de software devem conhecer o cenário
organizacional em um nível suficiente, a ponto de avaliar e sugerir melhorias, ou
mesmo reengenharia nos processos de negócio.
Este trabalho mostrará na prática a importância das técnicas e
conceitos da UML, através do diagrama de atividades, bem como a modelagem de
dados na utilização dos consagrados bancos de dados relacionais juntamente com a
programação orientada a objetos, viabilizando o sucesso dos sistemas no que tange
o alinhamento dos objetivos aos processos das organizações.
4
2 DESENVOLVIMENTO
2.1 UML – DIAGRAMA DE ATIVIDADES
O diagrama de atividades, geralmente é apresentado como parte da
descrição funcional de um sistema, devido ao fato de especificar processos lógicos
(atividades do sistema e dos fluxos de dados ou decisões). Nele são apresentadas
as relações entre cada atividade de um determinado processo, em que podem ser
vistas as relações de dependência entre essas atividades, e quem são os
responsáveis pelas suas execuções.
2.1.1 CENÁRIO ATUAL
Respeitando ao máximo o texto da proposta e abstraindo algumas
situações do cenário atual da empresa sobre sua rotina de trabalho, estipulamos
que o cliente chega à loja e vai até as prateleiras, escolhe o exemplar que deseja e
leva até o atendente para efetivar a locação. Ou então, se a intenção é devolver o(s)
livro(s) na sua totalidade, solicita ao funcionário a baixa do empréstimo.
2.1.1.1 GERENCIAR DEVOLUÇÃO
Figura 1 – diagrama de atividades (gerenciar devolução total)
5
2.1.1.2 GERENCIAR EMPRÉSTIMOS
Figura 2 – diagrama de atividades (gerenciar empréstimos)
6
2.1.1.3 MANTER LIVROS
Figura 3 – diagrama de atividades (manter livros)
7
2.1.1.4 MANTER USUÁRIOS
Figura 4 – diagrama de atividades (manter usuários)
2.1.2 NOVO CENÁRIO
Para o novo cenário com as alterações significativas no processo de
devolução fracionada e no de empréstimos, faremos também mudanças no fluxo de
trabalho, abstrairemos que agora o cliente não tem mais acesso às prateleiras, e o
funcionário deverá consultar o sistema a procura dos exemplares disponíveis, para
somente então, buscar o livro.
Daremos ênfase aos dois processos que sofreram alterações
significativas: empréstimo e devolução.
Empréstimo: o funcionário autenticado e pertencente ao
departamento de locações consulta se o cliente é cadastrado. Não há mais a
condição de pendência, ou seja, havendo ou não empréstimos em aberto, é
permitido realizar um novo sem que o último tenha sido finalizado. A multa ou
relocação será tratada no processo de devolução, uma vez que no antigo processo o
8
cliente pagava na hora de efetivar o empréstimo e não há na proposta inicial alusão
a multas ou relocações automáticas. O funcionário consulta o livro solicitado pelo
cliente, podendo fazê-lo pelo título ou autor. O sistema checa a disponibilidade e
exibe os resultados. Informar a data do empréstimo. O sistema realiza o empréstimo
e emite o comprovante.
Figura 5 – diagrama de atividades (gerenciar empréstimo - reformulado)
Devolução: funcionário autenticado e do departamento de locações
consulta o sistema e exibe o empréstimo. Deverá selecionar os exemplares e o
sistema calculará e exibirá o valor a pagar incluindo possíveis atrasos. O funcionário
receberá o valor e o sistema encerrará o empréstimo se for entregue todos os
exemplares ou dará baixa nos itens de empréstimo.
9
Figura 6 – diagrama de atividades (gerenciar devolução - reformulado)
10
2.2 MODELO CONCEITUAL COM MRN APLICADO
O modelo relacional foi inventado pelo Dr. Codd e
subsequentemente mantido e aprimorado por Chris Date e Hugh Darwen como um
modelo geral de dados.
A normalização de dados é uma série de passos que se segue no
projeto de um banco de dados que permite um armazenamento consistente e um
eficiente acesso aos dados em um banco de dados relacional. Esses passos
reduzem a redundância de dados e as chances dos dados se tornarem
inconsistentes.
Procuramos obedecer e respeitar todas as regras de negócios
impostas na proposta, entretanto, depois de uma minuciosa análise em grupo,
assumimos algumas adaptações visando melhorar a utilização do software pelo
usuário e nos preocupando em não “engessá-lo” na modelagem.
Por exemplo, quanto ao cadastro de autores, a regra de negócio diz
que um livro deve ter 1 ou vários autores. Significa dizer, que ao se cadastrar um
autor, obrigatoriamente, devemos relacioná-lo a um livro pelo menos.
Imaginemos que um funcionário comprou 200 livros de uma grande
livraria e deseja cadastrá-los antes mesmo de recebê-los. Para isso, solicitou a outro
funcionário que fosse lançando os nomes dos autores para depois agilizar o trabalho
de cadastro dos livros. Pela regra original isso não seria possível!
Portanto, na nossa concepção de modelagem, deixamos em aberto
esta possibilidade colocando a cardinalidade de (0,n) na entidade AUTOR, ou seja,
pode-se cadastrar N autores e depois na tela de cadastro de livros ligamos livro a
autor(es). Essa adaptação não fere a regra de negócios, pois ainda sim, um livro não
pode ser incluído sem um autor.
Utilizamos o mesmo raciocínio na entidade LIVROS em relação à
entidade EXEMPLAR.
11
Figura 7 – modelo conceitual do sistema com alterações
2.3 MAPEAMENTO OBJETO RELACIONAL
Técnica de desenvolvimento utilizada para reduzir a impedância da
programação orientada aos objetos utilizando bancos de dados relacionais. As
tabelas do banco de dados são representadas através de classes e os registros de
cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os
comandos em linguagem SQL; ele irá usar uma interface de programação simples
que faz todo o trabalho de persistência.
A seguir, relacionamos as classes e seus respectivos códigos
gerados a partir de nosso DER.
12
Classe Pessoa =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classe_Pessoa { private int codigo; private string nome; private DateTime dat_nasc; public int Codigo { get { return codigo; } set { codigo = value; } } public string Nome { get { return nome.Trim().ToUpper(); } set { if ((value.Length > 70) || (value.Length < 5)) throw new Exception("o tamanho para este campo é de 5 a 70 caracteres."); else nome = value; } } public DateTime Dat_nasc { get { return dat_nasc; } set { dat_nasc = value; } } } // fecha classe Pessoa } Classe Funcionario =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeFuncionario: classe_Pessoa { private int func_codigo; public int Func_codigo { get { return func_codigo; } set { func_codigo = value; } } } }
13
Classe Cliente =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeCliente : classe_Pessoa { private int cli_codigo; public int CLi_codigo { get { return cli_codigo; } set { cli_codigo = value; } } } } Classe Autor =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeAutor: classe_Pessoa { private int aut_codigo; public int Aut_codigo { get { return aut_codigo; } set { aut_codigo = value; } } } } Classe Livro =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classe_Livro { private int liv_codigo; private string liv_titulo; public int Liv_codigo { get { return liv_codigo; } set { liv_codigo = value; } } public string Liv_titulo { get
14
{ return liv_titulo.Trim().ToUpper(); } set { if (value.Length > 60) throw new Exception("Tamanho do nome inválido."); else liv_titulo = value; } } // fecha public Liv_Codigo } // fecha classe livro } Classe Exemplar =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classe_Exemplar { private int exem_codigo; private string exem_status; public int Exem_codigo { get { return exem_codigo; } set { exem_codigo = value; } } public string Exem_status { get { return exem_status; } set { if (value.Length > 10) throw new Exception("o Status deve ter no máximo 10 caracters."); else exem_status = value; } } } // fecha classe exemplar } Classe Classificação =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeClassificacao {
15
private int cla_codigo; private double cla_valor; private string cla_tipo; public int Cla_codigo { get { return cla_codigo; } set { cla_codigo = value; } } public Double Cla_valor { get { return cla_valor; } set { if ((cla_valor.GetType() == typeof(Double))) { cla_valor = value; } else cla_valor = 0; } } public string Cla_tipo { get { return cla_tipo; } set { if ((value != "diamante") || (value != "ouro") ||(value != "prata") ||(value != "bronze") ) throw new Exception("erro no tipo da classificação"); else cla_tipo = value; } } } } Classe Classificação =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeDepartamento { private int dep_codigo; private string dep_nome; public int Dep_codigo { get { return dep_codigo;} set { dep_codigo = value; } } public string Dep_nome { get { return dep_nome; } set { if (dep_nome.Length > 20)
16
throw new Exception("Excedeu o limite de caracteres. Tamanho máximo é de 20"); else dep_nome = value; } } } } Classe Emprestimo =========================================== using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class classeEmprestimo { private int emp_codigo; private DateTime emp_datalocacao; private DateTime emp_datadevolucao; public int Emp_codigo { get { return emp_codigo; } set { emp_codigo = value; } }
public DateTime Emp_datalocacao { get { return emp_datalocacao; } set { emp_datalocacao = value; } }
public DateTime Emp_datadevolucao { get { return emp_datadevolucao.AddDays(5); } set { emp_datadevolucao = value; } } } }
2.4 LISTA ORDENADA
Uma lista é a coleção de elementos de mesmo tipo, dispostos
linearmente, que podem ou não seguir uma organização.
O código abaixo escrito em C# solicita do usuário o tamanho da lista
e depois ordena pela data de devolução do filme.
17
using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace Unopar { class Program { static void Main(string[] args) { Console.Write("Quantos registros deseja inserir? "); int qtd = Int32.Parse(Console.ReadLine()); int i = 0; string[] cliente = new string[qtd]; DateTime[] dataEmprestimo = new DateTime[qtd]; while (i < qtd) { Console.Write("\nDigite o nome do usuario que fez a locação: "); cliente[i] = Console.ReadLine().ToUpper().Trim(); Console.Write("Data de locação (dd/mm/aaaa): "); dataEmprestimo[i] = DateTime.Parse(Console.ReadLine()); i++; } Console.WriteLine("\n\n==========================================="); int q = (cliente.Length) - 1; while (q >= 0) { DateTime dataDevolucao = dataEmprestimo[q].AddDays(5); Console.WriteLine("Cliente: \t" + cliente[q] + "\nData Empr: \t" + dataEmprestimo[q] + "\nData Devol: \t" + dataDevolucao + "\n"); q--; } Console.WriteLine("==========================================="); Console.ReadKey(); } } }
18
3 CONCLUSÃO
O processo de modelagem do banco de dados merece destaque em
nossa avaliação, pois exercemos a essência de nossa profissão: a análise. Foram
bastante interessantes as discussões, reuniões e ponderações, à medida que o
modelo tomava forma. Ficou latente, que em projetos de sistemas, várias cabeças
pensantes trabalhando em colaboração são uma ótima receita para construção de
soluções eficazes e consistentes.
Concluímos nosso trabalho com a certeza do dever cumprido.
Estamos convictos da importância de conhecermos bem os diversos benefícios
trazidos pela correta aplicabilidade das ferramentas UML, bem como o domínio dos
conceitos de banco de dados relacionais casados ao paradigma de orientação a
objetos. A programação da FILA nos proporcionou a prática de programação, tão
importante na concretização dos sistemas modelados e pensados.
19
REFERÊNCIAS
ASCENSIO, Ana Fernanda Gomes. Estrutura de Dados: algoritmos, análise da complexidade e implementações em Java e C/C++. São Paulo: Pearson Prentice Hall, 2010.
NISHIMURA, Roberto Yukio. Banco de Dados II: sistemas. São Paulo: Pearson Prentice Hall, 2009. WIKIPEDIA: http://pt.wikipedia.org/wiki/Mapeamento_objeto-relacional Orientador Pedro Pedreira: https://sites.google.com/site/orientadorpedropereira/Home/fundamentos-de-orientacao-a-objetos-e-uml/diagramas-de-classes