Pt - Ads - Sem 3 - Atividade Individual

Prévia do material em texto

�PAGE �
LISTA DE FIGURAS
8Figura 1 – Esquema de Funcionamento de uma Fila - FIFO	�
9Figura 2 – Esquema de funcionamento de uma Pilha - FILO	�
10Figura 3 – Alocação Simplesmente Encadeada	�
10Figura 4 – Alocação Duplamente Encadeada	�
13Figura 5 - Ex: 01 - Fases de Análise e Projeto	�
14Figura 6 - Ex: 02 - Fases de Análise e Projeto	�
�SUMÁRIO
31	INTRODUÇÃO	�
42	OBJETIVO	�
53	DESENVOLVIMENTO	�
53.1	BANCO DE DADOS - PROPRIEDADES ACID	�
53.1.1	PROPRIEDADE A: ATOMICIDADE	�
53.1.2	PROPRIEDADE C: CONSISTÊNCIA	�
63.1.3	PROPRIEDADE I: ISOLAMENTO	�
63.1.4	PROPRIEDADE D: DURABILIDADE	�
73.2	SISTEMAS OPERACIONAIS NOS QUAIS A LOCADORA PODE SER DESENVOLVIDA	�
73.3	ESTRUTURA DE DADOS	�
83.3.1	FILA - FIFO (FIRST IN FIRST OUT)	�
83.3.2	PILHA - FILO (FIRST IN LAST OUT)	�
93.4	VANTAGEM QUE ALOCAÇÃO DUPLAMENTE ENCADEADA TEM SOBRE ALOCAÇÃO SIMPLESMENTE ENCADEADA	�
103.4.1	ALOCAÇÃO SIMPLESMENTE ENCADEADA	�
103.4.2	ALOCAÇÃO DUPLAMENTE ENCADEADAS	�
103.5	DIAGRAMAS	�
113.6	VANTAGENS QUE OS DIAGRAMAS DE CASO DE USO E DE CLASSES PODEM TRAZER PARA UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE	�
113.7	FINALIDADE DO DIAGRAMA DE CASO DE USO	�
123.8	FINALIDADE DO DIAGRAMA DE CLASSES	�
123.9	QUEM UTILIZA ESSE DIAGRAMA?	�
133.10	FASE DE ANÁLISE	�
133.11	FASE DE PROJETO	�
143.12	HUMANIZAÇÃO NO AMBIENTE DE TRABALHO	�
153.13	ÉTICA NO AMBIENTE DE TRABALHO	�
174	CONCLUSÃO	�
18REFERÊNCIAS	�
��
INTRODUÇÃO
O desenvolvimento de um projeto de software exige vários planejamentos, análises, modelagem do banco de dados, sistemas operacionais suportados, implementações de estruturas de dados, uso de técnicas de programação, etc.
Através do empenho de Jacobson, Booch e Rumbaugh, surgiu a Linguagem de Modelagem Unificada, a UML.
A importância da linguagem de modelagem UML dentro do desenvolvimento de um sistema é indiscutível.
“A modelagem é a parte central de todas as atividades que levam à implantação de um bom sistema”.
Somente com o auxílio da modelagem podemos visualizar e controlar o desenvolvimento de sistemas de maneira eficaz, identificando e gerenciando riscos, estipulando e cumprindo prazos, dentro das estimativas de custo.
Além da modelagem de dados, vamos abordar e explanar: As propriedades ACID de um banco de dados, que é um conjunto de procedimentos que é executado no mesmo, que para o usuário é visto como uma única ação; Sistemas operacionais nos quais o software web da Locadora pode ser desenvolvido; Estrutura de dados, que é o ramo da computação que estuda os diversos mecanismos de organização de dados para atender aos diferentes requisitos de processamento; Humanização e ética no ambiente de trabalho.
OBJETIVO
Esta produção textual interdisciplinar do 3º semestre do curso de Análise e Desenvolvimento de Sistemas, tem como objetivo aplicar e exercitar os conteúdos assimilados no período, abordando os diversos conceitos, técnicas e práticas sobre as propriedades ACID de uma transação, quais sistemas operacionais o exemplo da locadora pode ser desenvolvido, listas lineares (FIFO e FILO), alocações simplesmente encadeadas e duplamente encadeadas, diagramas de caso de uso e de classes, e por fim, humanização e ética no ambiente de trabalho.
DESENVOLVIMENTO
BANCO DE DADOS - PROPRIEDADES ACID
Para obtermos uma transação de sucesso, o BD deve respeitar as seguintes propriedades ACID: atomicidade, consistência, isolamento e durabilidade.
PROPRIEDADE A: ATOMICIDADE
Essa propriedade garante que qualquer operação deve ser realizada por completa, caso não seja, ela será desconsiderada. Isso evita falhas que ocorrem durante a manipulação de um BD.
Exemplo: Deseja-se fazer uma transferência bancária de uma conta A pra uma conta B e no meio da transferência há uma queda de energia total. E agora? A transferência foi realizada com sucesso ou a transferência foi descontada da conta A sem que B tenha recebido?
Se uma transação obedece a atomicidade, é muito fácil responder à essas perguntas. Caso a transferência não tenha sido concluída, essa propriedade garante que qualquer modificação do estado do BD seja desconsiderada, assim, a conta A e B permaneceriam do mesmo jeito que estavam antes de começar a transferência.
PROPRIEDADE C: CONSISTÊNCIA
O Banco de Dados é consistente quando permanece correto, íntegro, sem nenhum tipo de violação que possa acontecer quando se atualiza ou deleta algum dado desse BD. Quando uma transação é realizada, ela deve obedecer todas as restrições e requisitos de um BD, assim, quando mudarmos de um estado 1 pra um estado n, o BD permanecerá normal, correto, respeitando todas suas regras de definição.
Exemplo: Considere um BD de um curso de línguas que possui muitas relações. Observe a relação ALUNO e imagine que há um número bom de alunos cadastrados em algum curso dessa empresa.
	MATRICULA
	CPF
	NOME
	RG
	ENDEREÇO
	TELEFONE
Há alguma outra relação que referencia a entidade ALUNO através do seu atributo MATRICULA. Agora, imagine que TODOS os alunos desse curso de línguas resolvem abandonar o curso, de tal forma que fôssemos obrigados a deletar a instância "ALUNO". Quando mudarmos o estado desse BD, o mesmo não permanecerá consistente, já que há outras tabelas e atributos fazendo referência à essas instâncias, quebrando a restrição de integridade referencial de chave.
PROPRIEDADE I: ISOLAMENTO
Acontece quando nos deparamos com transações concorrentes, ou seja, mudanças simultâneas sobre um mesmo conjunto de dados, transação multiusuário. O resultado final deve ser o mesmo se as operações estivessem sendo feitas uma de cada vez. A transação por ser um processo ou programa executável, garante que uma tarefa não interfira na outra.
Exemplo: Imagine um Banco de Dados de uma empresa de aviões JV Air Lines e ela fornece transações on-line, ou seja, você pode consultar, fazer reservas, comprar passagens e etc., via internet e multiusuário. Seria possível dois ou mais clientes fazer uma reserva de uma mesma poltrona em uma mesma classe do avião? Quando um BD respeita a propriedade de isolamento, ele garante que apenas um dos clientes conseguirá a reserva da poltrona desejada. Assim, ao mudarmos o estado de um BD, não violaremos nenhum tipo de restrição e inconsistência.
PROPRIEDADE D: DURABILIDADE
Essa operação garante que todas as mudanças de estado, isso se realizadas com sucesso, sejam validadas, persistentes, definitivas, mesmo que depois de concluídas, haja alguma falha no sistema. Essas alterações permanentes são visíveis a outras transações a serem realizadas.
Exemplo: Em um Banco de Dados do Google, há inúmeros dados, deseja-se colocar mais dados nesse BD. Depois de concluída a inserção, o servidor cai ou há algum problemas mais grave de hardware. Não precisaríamos nos preocupar, porque a transação já tinha sido concluída, sendo assim, continuam existindo e permanecem inalterados.
SISTEMAS OPERACIONAIS NOS QUAIS A LOCADORA PODE SER DESENVOLVIDA
Com base na escolha da linguagem e banco de dados, estes escolhidos na produção textual interdisciplinar do 2º semestre, o Sistema da Nossa Locadora de Livros será desenvolvido na linguagem PHP, permitindo o seu desenvolvimento rápido e visual nas plataformas Windows, Linux/Unix, Mac OS, sistema operacional disponível na Internet - computação em nuvem (em inglês, cloud computing), sistemas mobile, ex: android, dentre outros sistemas operacionais, bastando apenas ter um navegador de internet e acesso a rede mundial de computadores.
O Sistema da Locadora pode ser desenvolvido também em um servidor local, o chamado localhost, o que permite criar o mesmo sem uma conexão com a internet. Para o desenvolvimento local, é necessário instalar php, mysql e apache no sistema operacional. Outros bancos de dados são suportados pelo PHP, entre eles pode-se citar; PostgreSQL, Sybase, Oracle e SQLServer.
Já para o desenvolvimento em um servidorweb, basta ter o serviço contratado a disposição. Nessa modalidade de desenvolvimento o sistema da locadora pode ser criado/modificado a partir de qualquer sistema operacional que tenha acesso a rede mundial de computadores. Podendo até ser desenvolvido em sistemas mobile como: Android, Windows Phone Mobile, Mozilla OS, etc. Esta filosofia de desenvolvimento em ambiente WEB é possível porque o código é interpretado no lado do servidor (em inglês, server-side) pelo módulo PHP, que também gera a página web a ser visualizada no lado do cliente (em inglês, client-side).
Com o PHP, portanto, tem-se a liberdade para escolher o sistema operacional e o servidor web.
ESTRUTURA DE DADOS
Sobre as estruturas de dados veremos duas formas de estruturas a Fila (FIFO) e a Pilha (LIFO).
FILA - FIFO (FIRST IN FIRST OUT)
O primeiro elemento que entrou é o primeiro a sair. Cada elemento armazena um ou vários dados (estrutura homogênea ou heterogênea) e um ponteiro para o próximo elemento, permitindo o encadeamento e a linearidade. Temos as seguintes operações nesta estrutura: inserir na fila, consultar toda a fila, remover e esvaziá-la. Nas filas as remoções acontecem no ponteiro INÍCIO e as inserções no ponteiro FIM. Analogicamente, imaginemos uma fila de espera de um banco qualquer, todo cliente que chega é posicionado ao final da fila, e o primeiro a ser atendido sempre será o primeiro desta fila de espera.
Figura 1 – Esquema de Funcionamento de uma Fila - FIFO
Fonte: ASCENSIO, Estrutura de Dados, pág. 191 e 192
PILHA - FILO (FIRST IN LAST OUT)
O último elemento que entrou é o primeiro a sair. Cada elemento armazena um ou vários dados (estrutura homogênea ou heterogênea) e um ponteiro para o próximo elemento, permitindo o encadeamento e a forma linear. Temos as seguintes operações nesta estrutura: inserir na pilha, consultar toda a pilha, remover e esvaziá-la. Nas pilhas as remoções e inserções acontecem num único ponto, o TOPO. Analogicamente, pensemos numa pilha de pratos, onde um novo prato será sempre colocado no topo da pilha; para retirarmos um prato, escolhemos o do topo, ou seja, o último prato inserido.
Figura 2 – Esquema de funcionamento de uma Pilha - FILO
Fonte: ASCENSIO, Estrutura de Dados, pág. 185
VANTAGEM QUE ALOCAÇÃO DUPLAMENTE ENCADEADA TEM SOBRE ALOCAÇÃO SIMPLESMENTE ENCADEADA
Há uma questão que envolve performance, flexibilidade e requisitos de alocação de memória, relacionados com a opção que fazemos por uma ou outra estrutura de dados. No caso da lista simplesmente encadeada, os nós são menores (1 ponteiro por dado armazenado), mas a flexibilidade de deslocamento entre os nós é menor (só em um sentido) e mesmo a performance pode ser menor em operações como a inserção no final da lista. Já as listas duplamente encadeadas irão ocupar mais memória (2 ponteiros para cada dado), mas são muito mais flexíveis e podem ser mais eficientes na em certas operações (por exemplo, na inserção/remoção do final da lista). Portanto, como atualmente a abundância de recursos computacionais de hardware (memória) não é um gargalo para desenvolvedores, considero a alocação duplamente encadeada a mais recomendada.
ALOCAÇÃO SIMPLESMENTE ENCADEADA
Uma lista simplesmente encadeada é uma sucessão de nós onde cada nó aponta para o próximo nó da lista. O nó que possuir o valor NULL no ponteiro para próximo é o último nó da lista. É de extrema importância que seja mantida uma referência para o primeiro nó da lista, caso esta referência for NULL, significa que a lista esta vazia.
Figura 3 – Alocação Simplesmente Encadeada
ALOCAÇÃO DUPLAMENTE ENCADEADAS
São listas que, além de cada elemento indicar o elemento seguinte, também indicam aquele que o antecede, ou melhor, cada elemento é ligado ao seu sucessor e ao seu predecessor.
Figura 4 – Alocação Duplamente Encadeada
DIAGRAMAS
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, linguagem de modelagem (UML - Unified Modeling Language), pode ser visto como um conjunto de diagramas que podem ser examinados e modificados a fim de compreender e desenvolver um sistema de software.
VANTAGENS QUE OS DIAGRAMAS DE CASO DE USO E DE CLASSES PODEM TRAZER PARA UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE
A vantagem está na utilização para visualizar, especificar, construir e documentar o projeto de software. Visando um desenvolvimento com total habilidade e responsabilidade. Auxiliando o desenvolvedor a focar nas vantagens provenientes do uso do paradigma orientado a objetos, ou seja, com os diagramas de caso de uso e classes é possível elaborar a estrutura de sistemas simples e complexos de software.
A importância de se utilizar esses diagramas em um projeto é altamente recomendado e exigido, pois por mais que não queremos, temos que analisar o problema visto de um determinado cliente, e com isso devemos procurar um modo mais eficiente de se ter um bom desenvolvimento tendo esses diagramas para auxiliar no decorrer da “produção de software”. O modelo especificado deve ser claramente definido, de modo que o sistema evite passar por correções no decorrer de seu desenvolvimento.
Assim, antes mesmo de começar efetivamente a programação, pode-se ver se a esquematização do sistema está correta e de acordo com o que foi levantado previamente na análise de requisitos.
FINALIDADE DO DIAGRAMA DE CASO DE USO
Os casos de uso são utilizados para identificar os requisitos funcionais que o sistema deve atender, mas não especificam explicitamente estes requisitos. A finalidade ao se especificar um caso de uso é melhorar a compreensão dos requisitos do sistema, pois é um documento feito em forma de narrativa que descreve os processos do domínio. 
Um caso de uso descreve a sequência de eventos executados por um ator, isto é, processos do negócio que representam os casos de utilização de um sistema efetuados por um agente externo(o ator, que é o usuário do sistema). Os Modelos de casos de uso irão conter os diagramas de caso de uso do sistema. 
Os casos de uso são agentes externos ao sistema e não se deve esperar correlação entre eles e as classes do sistema. Os casos de uso não representam passos individuais nem operações ou transações. Não podemos ter um caso de uso que represente uma sequência como Imprimir comprovante de Empréstimo, Pagar Atraso de Devolução. O caso de uso descreve uma sequencia do início ao fim de um grande processo, que possui muitos passos ou transações. Podemos, entretanto, dividir um caso de uso extenso em subcasos, os quais serão casos de uso abstratos, podendo estes chegarem a descrever passos individuais, porém isto não é a regra.
Para a identificação dos casos de uso podemos fazer uso de brainstorming (ferramenta para geração de novas ideias) e revisões de documentos dos requisitos do sistema. O ideal é começarmos inicialmente identificando os atores e para cada ator identificar os processos que são iniciados por ele ou dos quais o ator participa. Outra forma de identificar os casos de uso é identificar os eventos externos aos quais o sistema deve responder e relacioná-los a atores e a casos de uso.
FINALIDADE DO DIAGRAMA DE CLASSES
O diagrama de classes é considerado por muitos autores como o mais importante e o mais utilizado diagrama da UML. Seu principal enfoque está em permitir a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as classes do sistema se relacionam, se complementam e transmitem informações entre si. Este diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em definir a estrutura lógica das mesmas. O diagrama de classe serve como base para a construção da maior parte dos demais diagramas da UML.
Basicamente, o diagrama de classes é composto por suas classes e pelas associações existentes entre elas, ou seja, os relacionamentos entre as classes. Segundo Guedes em seu livro “UML– Uma Abordagem Prática”, o objetivo do diagrama de classes é mostrar os relacionamentos existentes entre as classes que são abstraídas no projeto, e como esses relacionamentos colaboram para a execução de um processo específico.
QUEM UTILIZA ESSE DIAGRAMA?
O projetista de software, os analistas, desenvolvedores, dentre outros.
O diagrama serve como um meio de facilitar a padronizar o desenvolvimento e deixar todos os profissionais envolvidos se comunicando numa mesma linguagem em relação ao projeto.
Imagine se fossemos desenvolver um sistema de entrega sem termos uma boa especificação de como deverá ser feito, seria uma bagunça.
FASE DE ANÁLISE
A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema (o que deve ser feito). É uma atividade de investigação.
Consiste de todas as atividades feitas com ou para o conhecimento do cliente. A informação produzida é aquela que o cliente deve discutir e aprovar.
Figura 5 - Ex: 01 - Fases de Análise e Projeto
FASE DE PROJETO
O projeto modela a solução e consiste das atividades de criação (como pode ser feito).
O projeto inclui as atividades que resultam em informação que interessa apenas ao programador. 
Figura 6 - Ex: 02 - Fases de Análise e Projeto
HUMANIZAÇÃO NO AMBIENTE DE TRABALHO
Segundo Betts (2003), “…sem comunicação não há Humanização”, baseia-se na capacidade da troca de informação por comunicação (verbal ou não verbal) entre indivíduos. Esse compromisso, teoricamente firmado, com a pessoa que está sofrendo, passa por estágios de motivação individual ou de ambas as partes. Essa motivação pode resultar do sentimento de compaixão piedosa por quem sofre ou da ideia de que assim contribuímos para o bem comum e para o bem-estar em geral; pelo estímulo nato da objetividade da investigação científica que exclui a subjetividade (ex.: medicina baseada em evidências) e, por fim, a solidariedade genuína(10).
Baraúna (2005) afirma que “a humanização é um processo de construção gradual, realizada através do compartilhamento de conhecimentos e de sentimentos”(11). Nesse contexto, humanizar é ter uma pré disposição para contribuir (o sentimento e o conhecimento) com o outro de forma ética, individualmente e independente, reconhecendo os limites, seus e o dele, compondo uma empatia entre indivíduos, possibilitando troca de informações.
Um outro ponto de vista é que a tecnologia, antropologicamente falando, sempre foi humanizada. Pois fomos nós, homens, que a desenvolvemos. O problema é que ao invés de se manter humanizada no sentido "humano" da palavra, alguns usam pra fins bélicos, de destruição em massa, de atentados, de disseminação de doenças por bombas biológicas e afins.
Seja qual for, humanização pode ser compreendida como uma construção de conhecimentos e abordagens que emerge do indivíduo para indivíduos, conforme as necessidades individuais do outro.
ÉTICA NO AMBIENTE DE TRABALHO
A ética é um conjunto de crenças sobre certo e errado. Normalmente ensinada no âmbito ainda familiar, de pai para filho, com o exemplo de dentro de casa. Que depois se segue no exemplo na escola, e no trabalho. Tem um cunho educacional e de conscientização muito grande.
Vivemos uma época de transição. Estamos aderindo a novas tecnologias que mudam a forma de fazer as coisas, de trabalhar, de viver, bem como estamos também reavaliando o conjunto de valores sociais que precisam ser protegidos, por uma convenção social, não apenas no Brasil, mas global. 
 Sendo assim, como de fato ensinar que agora a regra é “não cobiçar o conteúdo do próximo”, que “copiar e colar” trabalhos alheios é uma vergonha e não uma esperteza, que a “liberdade de expressão” não confere o “direito de ofender”, que “o uso de um avatar ou apelido” não confere o “direito de ser anônimo”, proibido pela Constituição.
Como explicar que pirataria é tão grave quanto o furto, que o uso de imagem não autorizado gera mais danos que uma facada e nem sempre dá para consertar o estrago feito na reputação de um indivíduo, que deixar o computador aberto é tão arriscado quanto deixar a porta de casa aberta.
 No mundo corporativo, em que a governança em TI se passa justamente por estabelecer regras de conduta que tragam transparência, bem como garantam confidencialidade, acessibilidade, integridade às informações, a questão fica ainda mais agravada. Pois as equipes, muitas vezes, não estão com este conjunto de valores já estabelecidos.
 Então, não adianta apenas ter uma Política de Segurança da Informação e um conjunto de normas de uso de e-mail, internet, rede, dispositivos móveis, entre outras que são para os funcionários em geral, normalmente os com algum vínculo de trabalho. 
É preciso ter sim um Código de Ética de TI, que seja não apenas para funcionários ou colaboradores internos, mas com capítulo específico para abranger os terceirizados, que são muito comuns neste mercado, atuando dentro do ambiente da empresa, através de um fornecedor em projetos, como também fazendo suporte ou atendendo via externa, e muitas vezes até com acesso remoto.
 As equipes de TI possuem acesso privilegiado às informações, aos equipamentos, até mesmo às senhas, atuam na contenção, na contingência, nos incidentes, na proteção contra vulnerabilidades. Por isso, é fundamental que tenham regras próprias para reger sua atuação, com termo de responsabilidade específico, de confidencialidade e, se houver desenvolvimento interno, Termo de Cessão. E tudo isso, em seu nível mais estratégico, deve ser amarrado pelo Código de Ética e Conduta Profissional em TI.
CONCLUSÃO
Através da confecção deste trabalho observou-se o quanto amplo é a utilização das filas e pilhas, alocações simplesmente encadeadas e duplamente encadeadas na programação. E também a importância das propriedades ACID para um SGBD, pois é este conjunto de características que garante a qualidade e segurança (contra falhas do sistema) das transações. 
Foi observado a importância do desenvolvimento de um sistema voltado para web, exemplo da locadora, onde se pode trabalhar o projeto em vários sistemas operacionais. 
Sobre diagramas, discorremos dois que são a base para o desenvolvimento de um projeto de software, que é o diagrama de caso de uso e o diagrama de classes, nesse contexto foi possível mostrar as vantagens de cada modelagem e como utilizá-las em termos de projeto. Desenvolver um sistema utilizando estes diagramas para modelagem de dados é considerado fácil, mas necessita do domínio do ambiente e do paradigma a ser utilizado.
Por último, tratamos humanização e ética no ambiente de trabalho. A ética pode definir o correto e o incorreto, contudo cabe ao indivíduo tomar como referência os princípios éticos na hora de agir seja dentro da Tecnologia da Informação ou em qualquer outra área, mas concordamos que se faz necessário a criação de normas de condutas para o uso, que hoje é praticamente indiscriminado, das tantas ramificações na área de TI.
Foi bastante prazeroso e gratificante poder transformar em um documento prático e objetivo todos os conceitos ministrados no 3º período do curso de Análise e Desenvolvimento de Sistemas da UNOPAR e ter a certeza de que os mesmo nos ajudarão em nossas carreiras futuramente.
REFERÊNCIAS
BARRICO, Carlos. LINGUAGEM DE MODELAÇÃO UML. Disponível em: < http://www.di.ubi.pt/~cbarrico/Disciplinas/EngenhariaSoftware/Downloads/Cap%206%20-%20UML%20-%20Modelacao%20da%20Estrutura.pdf >. Acessado em: 04 de maio de 2013 às 20:15hs.
CARNEIRO, Eric. Ética na Tecnologia da Informação. Disponível em: < http://www.ebah.com.br/content/ABAAAA6zcAH/etica-na-tecnologia-informacao >. Acessado em: 04 de maio de 2013 às 19:00hs.
DELIBERADOR, Paulo de Tarso. Algoritmos e Estrutura de Dados: Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - 3. São Paulo: Person Prentice Hall, 2009.
FIGUEIREIDO, M. Leandro; SOARES, H. Rubens. Comparação entre a modelagem orientada a objeto e a modelagem estruturada relacional. Disponívelem: < http://online.unicaldas.edu.br/portal/publicacao/arq/modelagem.pdf >. Acessado em: 05 de maio de 2013 às 21:00hs.
GEPOLIVALENTE. SGBD - ACID - Transações. Disponível em: < http://wiki.gepolivalente.com.br/bin/view/SGBD/Transacoes >. Acessado em: 06 de maio de 2013 às 22:00hs.
MATEUS, Eloá Jane Fernandes. Sistemas Operacionais: Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - 3. São Paulo: Pearson Education do Brasil, 2009.
NISHIMURA, Roberto Yukio (org.). Banco de Dados II: Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - 3. São Paulo: Pearson Education do Brasil, 2009.
NISHIMURA, Roberto Yukio. Banco de Dados I: Curso superior de tecnologia em Análise e Desenvolvimento de Sistemas - 2. São Paulo: Pearson Education do Brasil, 2009.
TANAKA, Simone Sawasaki. Análise de Sistemas II: Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - 3. São Paulo: Person Prentice Hall, 2009.
UFCG. Análise e Projeto Orientados a Objeto. Disponível em: < http://www.dsc.ufcg.edu.br/~jacques/cursos/apoo/html/intro/intro1.htm >. Acessado em: 06 de maio de 2013 às 18:00hs.
Sobral
2013
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual
JOSÉ VIDAL DE ARAÚJO
JOSÉ VIDAL DE ARAÚJO
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual
Trabalho de Análise e Desenvolvimento de Sistemas, apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral nas disciplinas de: Análise de Sistemas II, Sistemas Operacionais, Banco de Dados II, Linguagem de Programação e Estrutura de Dados, Ética, Política e Sociedade, Compreensão e Raciocínio I e Seminários III.
Orientador: Profs. Polyanna P. Gomes Fabris
 Adriane Loper
 Roberto Nishimura
 Merris Mozer
 Anderson Macedo
 Sérgio de Goes Barboza
 Andréa Zômpedo
Sobral
2013
Sistema de Ensino Presencial Conectado
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS