Propriedades ACID em Bancos de Dados

Prévia do material em texto

3
Sistema de Ensino Presencial Conectado
Tecnologia em Análise e Desenvolvimento de Sistemas
ana carolina teixeira dos santos
Atividade Interdisciplinar - Individual
Gurupi - TO
2013
ana carolina teixeira dos santos
Atividade Interdisciplinar - Individual
Trabalho apresentado ao Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR
Professores: Polyanna Pacheco Gomes
	Roberto Y. Nishimura
Marcio Chiaveli
	Merris Mozer
Gurupi - TO
2013
SUMÁRIO
2.	INTRODUÇÃO	3
4	DESENVOLVIMENTO	5
5	CONCLUSÃO	21
REFERÊNCIAS	22
INTRODUÇÃO
Neste trabalho será abordada toda a matéria do 3º Semestre, dentro deste contexto serão apresentados os conceitos de listas lineares, FIFO, FILO, seus apontadores, ordens de inclusão, exclusão e pesquisa. Definirei também os conceitos de alocação simplesmente encadeada, alocação duplamente encadeada, com representações gráficas das duas.
Em relação a banco de dados, definirei os conceitos das propriedades ACID de uma transação e sua importância para um SGBD; e serão apresentadas duas ferramentas para se fazer ORM, bem como a explanação sobre o que é ORM e seus paradigmas.
No que tange a UML será mostrado os conceitos de polimorfismo e herança, bem como exemplos que os representem em diagramas de classe.
OBJETIVOS
Tem-se como objetivo desta produção textual o aprofundamento dos conteúdos estudados durante o semestre, bem como a aplicação prática de alguns conceitos vistos no decorrer das matérias.
 Desenvolvimento
4.1 COM RELAÇÃO A BANCO DE DADOS, DEINAS OS CONCEITOS DAS PROPRIEDADES ACID DE UMA TRANSAÇÃO.
ACID (atomicidade, consistência, isolamento, durabilidade) é um conjunto de propriedades que garantam as operações de banco de dados são processados de forma confiável. No contexto de bancos de dados, uma única operação lógica sobre os dados é chamada de transação. Por exemplo, uma transferência de fundos de uma conta bancária para outra, ainda que isto possa implicar várias alterações (como uma conta de débito e crédito da outra), é uma única transação.
Jim Gray definidas as propriedades de um sistema de transação de confiança no final de 1970 e as tecnologias desenvolvidas para alcançá-los automaticamente. Em 1983, Andreas Reuter e Theo Haerder cunhou a sigla ACID para descrevê-los.
Atomicidade
Atomicidade exige que as modificações do banco de dados devam seguir um tudo ou nada "regra". Cada operação está a ser dito atômica. Se uma parte da transação falhar, toda a transação e não o estado do banco de dados é deixado inalterado. É fundamental que o sistema de gerenciamento de banco de manter a natureza das operações atômicas, apesar de toda a aplicação, DBMS (Database Management System), sistema operacional ou falha de hardware.
Uma transferência atômica não pode ser subdividida e devem ser tratados na sua totalidade ou não em todos. Atomicidade significa que os usuários não precisam se preocupar com o efeito das transações incompletas.
As transações podem falhar por vários tipos de razões:
a) Falha de hardware: Um disco rígido falha, impedindo que algumas das alterações da operação de banco de dados em vigor.
b) Falha do sistema: O usuário perde sua conexão com o aplicativo antes de fornecer todas as informações necessárias.
c) insuficiência de dados: Por exemplo, o banco de dados é executado fora do espaço para guardar dados adicionais.
d) falta de aplicação: O aplicativo tenta enviar dados que viola uma regra que o próprio banco de dados impõe, tais como a tentativa de inserir um valor duplicado em uma coluna. Ele garante a veracidade do banco de dados.
e) A consistência propriedade garante que qualquer operação de banco de dados executa irá levá-lo de um estado consistente para outro.
f) Coerência estados que apenas dados válidos serão gravados no banco de dados. A propriedade de consistência não diz como o SGBD deve lidar com uma contradição do que garantir a banco de dados é limpa no final da transação. Se, por alguma razão, uma transação é executada que viola os dados de consistência regras, toda a transação poderia ser revertida para a transacional estado pré - ou seria igualmente válido para o DBMS para tirar algumas-up acção patch para obter o banco de dados em um estado consistente. Assim, se o esquema do banco diz que um determinado campo é para a realização de números inteiros, o SGBD pode decidir rejeitar as tentativas de colocar valores fracionários lá, ou pode arredondar os valores fornecidos para o número inteiro mais próximo: as duas opções de manter a consistência.
A regra aplica-se apenas a coerência com as regras de integridade que está dentro do seu âmbito. Assim, se um SGBD permite que os campos de um registro para atuar como referências para um outro registro, em seguida, a coerência implica o SGBD deve impor a integridade referencial : no momento qualquer transação termina, todos e cada referência no banco de dados deve ser válido. Se uma transação consistiu em uma tentativa de excluir um registro referenciado por outro, cada um dos seguintes mecanismos que manter a coerência:
a) anular a transação, a reversão para o Estado, de acordo prévio;
g) excluir todos os registros que fazem referência ao registro excluído (isso é conhecido como a exclusão em cascata ), ou,
h) anular os campos relevantes em todos os registros que apontam para o registro excluído.
Estes são exemplos de restrições de propagação , alguns sistemas de banco de dados permitem que o designer de banco de dados para especificar qual a opção de escolher, ao estabelecer o esquema para um banco de dados.
Os desenvolvedores de aplicativos são responsáveis por garantir nível de aplicação , consistência e mais acima daquele oferecido pelo SGBD. Assim, se um usuário retira fundos de uma conta eo novo equilíbrio é inferior a conta limite mínimo o equilíbrio, tanto quanto o SGBD está em causa, o banco de dados está em um estado consistente, embora esta regra (desconhecidos para o SGBD) tem sido violados
Isolamento refere-se à exigência de que outras operações não podem acessar os dados que foram modificados durante uma transação que ainda não foi concluída. A questão do isolamento ocorre em caso de transações simultâneas (várias transações que ocorrem ao mesmo tempo). Cada transação deve permanecer inconsciente de outras transações executando concorrentemente, exceto que uma transação pode ser obrigado a esperar a conclusão de outra transação que alterou os dados que a operação exige esperando. Se o sistema de isolamento não existe, então, os dados poderão ser colocados em um estado inconsistente. Isso pode acontecer, se uma transação está em processo de modificação de dados, mas ainda não concluída, e, em seguida, numa segunda operação que lê e modifica dados não confirmados da primeira operação. 
Se a primeira transação falhar e a segunda bem-sucedida, que a violação de isolamento transacional fará com inconsistência de dados. Devido ao desempenho e travado preocupações com múltiplas transações concorrentes, alguns bancos de dados modernos permitem leituras sujas que é uma maneira de contornar algumas das restrições do sistema de isolamento. Uma leitura sujo significa que uma transação tem permissão para ler, mas não modificar, os dados não confirmados de outra transação. Outra forma de fornecer isolamento para transações de leitura é através MVCC que começa em torno das questões de bloqueio de lê escreve o bloqueio. A leitura é feita em uma versão anterior de dados e não sobre os dados que está sendo bloqueado para a modificação proporcionando o necessário isolamento entre as transações.
Durabilidade é a capacidade do SGBD para recuperar as atualizações transação cometidos contra qualquer tipo de falha do sistema (hardware ou software). durabilidade é SGBD'sgarantia de que uma vez que o usuário tenha sido notificado da transação sucesso da transação não serão perdidos, a transação alterações de dados vai sobreviver falha do sistema, e que todas as restrições de integridade tenham sido cumpridos, para que o SGBD não precisará reverter a transação. Muitos SGBD’s implementam durabilidade por escrito operações em um log de transação que pode ser reprocessado para recriar o direito do estado do sistema antes de qualquer falha posterior. Uma transação é considerada comprometida somente depois que está inscrita no registro.
Durabilidade não implica um estado permanente de banco de dados. Uma operação subsequente poderá modificar os dados alterados por uma transação prévia, sem violar o princípio da durabilidade
Falha Atomicidade
A transação subtrai 10 da A e acrescenta 10 a B. Se for bem sucedido, seria válido, porque os dados continuarem a satisfazer a restrição. No entanto, supor que após a remoção de 10 a partir de A, a operação é incapaz de modificar B. Se o banco de dados retém o novo valor de A, a restrição de atomicidade e ambos seriam violados. Atomicidade exige que ambas as partes da transação completa ou não.
Falta de consistência
A consistência é um termo muito geral que exige os dados cumpre todas as regras de validação. No exemplo anterior, a validação é uma exigência que A + B = 100. Além disso, pode estar implícito que ambos A e B devem ser inteiros. O intervalo válido para A e B também pode ser implícita. Todas as regras de validação devem ser verificados para garantir consistência.
Suponha que uma transação tenta subtrair 10 de A sem alterar B. Como a consistência é verificada após cada operação, sabe-se que A + B = 100 antes da operação começa. Se a transação remove 10 a partir de um sucesso, atomicidade serão alcançados. No entanto, uma verificação de validação mostram que 90 = A + B. Isso não é coerente de acordo com as regras do banco de dados. Toda a transação deve ser desfeita.
Falha de isolamento
Para demonstrar o isolamento, assumimos executar duas operações ao mesmo tempo, cada um tentando modificar os mesmos dados. Um dos dois deve esperar até o outro termina, a fim de manter o isolamento.
Considere duas transações. T 1 transfere 10 de A para B. T duas transferências de 10 de B para A. combinado, existem quatro ações:
a) subtrair 10 a partir de um
i) adicionar 10 a B.
j) subtrair 10 do B
k) adicionar 10 a A.
Se estas operações são executadas em ordem, o isolamento é mantido, embora T 2 deve esperar. Considere o que acontece, se T 1 -falha a meio. O banco de dados elimina T 1 s efeitos ", e T 2 vê somente os dados válidos.
Intercalando as transações, a ordem real de ações pode ser: A - 10 , B - 10 , B + 10 , A + 10 . Novamente considerar o que acontece, se T 1 falhar. T 1 ainda subtrai 10 de A. Agora, T 2adiciona 10 a A restaurá-lo ao seu valor inicial. Agora T uma falha. Qual deve ser o valor de A? T 2 já mudou. Além disso, T 1 T nunca mudou B. 2 10 subtrai dela. Se T 2 é permitido concluir, de valor B será de 10 muito baixo, e de valor Um ficará inalterada, deixando um banco de dados inválidos. Isso é conhecido como uma escrita e gravação falha, porque duas operações tentou escrever para o mesmo campo de dados.
Falha Durabilidade
Suponha que uma transação de transferência de 10 de A para B. Ele remove 10 de A. Em seguida, adiciona 10 para B. Neste ponto, um "êxito" mensagem é enviada ao usuário. No entanto, as mudanças ainda estão em fila no buffer de disco à espera de ser comprometido com o disco. Power falha e as alterações são perdidas. O usuário assume que as mudanças tenham sido feitas.
4.2 PESQUISE E JUSTIFIQUE EM QUAIS SISTEMAS OPERACIONAIS O EXEMPLO LOCADORA PODE SER DESENVOLVIDO.
A evolução tecnológica tem-se destacado crescentemente em diferentes ramos. Trabalhos que eram realizados manualmente estão sendo hoje executados por computadores. Com isso, surgiu a necessidade do desenvolvimento de um sistema para vídeo locadora que possa aperfeiçoar os processos, deixando as locações, devoluções, cadastros, que antes eram feitos em blocos de papeis e fichas cadastrais, mais eficazes. Esta monografia tem como objetivo, analisar e conhecer o funcionamento e as funcionalidades de uma vídeo locadora, especificar um sistema que possa atender a estas funcionalidades e analisar o funcionamento desse sistema na locadora. O sistema foi implementado utilizando a linguagem Visual Basic 6.0, e o gerenciador de dados o SQL Server 2000. Com a implantação do sistema, o atendimento aos clientes tornou-se ágil e rápido. Facilitou o controle de locações, devoluções e a contabilização do acervo de filmes. Em virtude disso, aumentou a lucratividade da locadora.
4.3 A ESTRUTURAS DE DADOS DO TIPO FILA E PILHA MENCIONE QUAIS SÃO APONTADORES DE CADA ESTRUTURASUAS ORDENS PARA INCLUSÃO, EXCLUSÃO E PESQUISA.
a) Qual a vantagem que Alocação duplamente encadeada tem sobre Alocação simplesmente encadeada;
b) Represente graficamente as duas alocações de encadeamento; 
É uma lista linear em que todas as inserções de novos elementos são realizadas numa extremidade da lista e todas as remoções são feitas na outra extremidade. Uma fila é uma estrutura do tipo FIFO (“First In First Out”). Elementos novos são inseridos no lado In (fim da fila) e a retirada ocorre no lado Out (frente ou começo da fila). Num sistema operacional, os processos prontos para entrar em execução (aguardando apenas a disponibilidade da CPU) são geralmente mantidos numa fila. Existe um tipo de fila em que as retiradas de elementos da fila depende de um valor chamado prioridade de cada elemento. O elemento de maior prioridade entre todos os elementos da fila é o próximo a ser retirado. Tal fila recebe o nome de fila de prioridade.
Na vida real: pilhas de pratos numa cafeteria (acréscimos e retiradas de pratos sempre feitos num mesmo lado da pilha - lado de cima). Na execução de um programa: uma pilha pode ser usada na chamada de procedimentos, para armazenar o endereço de retorno (e os parâmetros reais). A medida que procedimentos chamam outros procedimentos, mais e mais endereços de retorno devem ser empilhados. Estes são desempilhados à medida que os procedimentos chegam ao seu fim. Na avaliação de expressões aritméticas, a pilha pode ser usada para transformar expressões em notação polonesa ou pós-fixa. A pilha também pode ser usada na avaliação de expressões aritméticas em notação polonesa.
FIFO refere-se a estruturas de dados do tipo fila. Tem uma estrutura diferente da estrutura de uma LIFO. As listas são amplamente utilizadas em programação para implementar filas de espera. Em uma fila de tipo FIFO os elementos vão sendo colocados na fila e retirados por ordem de chegada. A idéia fundamental da fila é que só podemos inserir um novo elemento no final da fila e só podemos retirar o elemento do início.
LIFO refere-se a estruturas de dados do tipo pilha. Usa-se os termos push e pop para denominar a inserção e remoção de elementos da pilha, respectivamente. Usa-se o termo top para consultar o elemento do topo da pilha, sem o remover.Uma pilha é uma lista linear na qual o primeiro elemento a entrar é o último elemento a sair. Ela possui apenas uma entrada, chamada de topo, a partir da qual os dados entram e saem dela
INCLUSÄO - Levando em consideraçäo o uso de um único ponteiro para o início
procedure InsereLista (var inicio : ponteiro ; info : InfoType);
No início 
No fim 
No meio 
INCLUSÄO - Levando em consideraçäo o uso de dois ponteiros (início e fim).
procedure InsereLista (var inicio, fim : ponteiro; info : InfoType);
No início
No fim
No meio (ordenada)
EXCLUSÄO - usa-se um procedimento recebendo o início da lista e os dados do nó ser excluído, então, através do campo identificado (chave) efetua-se uma pesquisa e localiza-se o nó anterior ao nó a ser excluído, e então devemos liberar o espaço alocado para o nó excluído e fazer o seu anterior apontar para o posterior.
procedure ExcluiLista (inicio : ponteiro ; info : InfoType);
No início 
Nomeio
No fim
PESQUISA - normalmente, usa-se uma função que, se encontrar, retornará o endereço do nó, caso contrário, retornará o valor NIL.
function Pesquisa Lista (inicio : ponteiro ; info : InfoType) : ponteiro;
Uma lista encadeada é um conjunto de elementos que estão dispostos em uma dada organização física não linear,isto é,estão espalhados pela memória.Para organizar a lista de maneira que possa ser utilizada como um conjunto linear,é necessário que cada elemento do conjunto possua informações sobre o seu elemento anterior e o seu elemento seguinte.
Alocação 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. Em certas situações também é útil possuir uma referência ao último nó.
Noção de nó, em uma lista encadeada, o principal elemento é denominado nó ou nodo. Um nó encontra-se em uma determinada posição da lista, sendo a lista uma sucessão de nós. Cada nó contém, no mínimo, dois campos: uma refere-se ao dado armazenado na lista naquela posição, a outra refere-se a um ponteiro a outro nó na mesma lista. O dado é a própria informação da aplicação, o ponteiro (ou ponteiros, pois podem existir dois ou mais ponteiros) permite o encadeamento da lista. Denomina-se o primeiro nó da lista de cabeça e o último de último.. 
Para solucionar esses problemas, podemos formar o que chamamos de listas duplamente encadeadas Semelhante à lista encadeada, mas contém dois ponteiros (ou links) na estrutura do nó. 
nó
anterior | |anterior | |anterior | |anterior | |dados | |dados | |dados | |dados | |Próximo | |próximo | |próximo | |próximo | | E1 | | E2 | | E3 | | En | |
ALGUMAS VANTAGENS DE ALOCAÇÃO
Isto trará novas oportunidades ao novo TAD; Dado um elemento, poderemos acessar ambos elementos adjacentes; o próximo e o anterior o ponteiro para o elemento anterior, bem como o endereço do próximo elemento serão manipulados. Diretamente inserção à direita e à esquerda de um nó qualquer. Se tivermos um ponteiro para o último elemento da lista, poderemos percorrê-la na ordem inversa Também utilizará a memória de maneira eficiente com alocação dinâmica como fez o TAD do módulo anterior. Este novo TAD possui semelhanças com TListaEnc.
4.4 NO ESTUDO DE CASO EM GRUPO ‘ NOSSA LOCADORA DE LIVROS’ FOI APRESENTADO O DIAGRAMA DE CASO DE USO E SOLICITADO O DIAGRAMA DE CLASSE. 
4.4.1 QUAIS VANTAGENS ESSES DIAGRAMAS PODEM TRAZER AO PROJETO DE DESENVOLVIMENTO DE SOFTWARE ? 
4.4.2 COM QUE FINALIDADE O DIAGRAMA DE CASO DE USO É CRIADO?
4.4.3 COM QUE FINALIDADE O DIAGRAMA DE CLASSE É CRIADO?QUEM UTILIZA ESTE DIAGRAMA?QUANTO À NOTAÇÂO DO DIAGRAMA, QUAIS INFORMAÇÕES SÃO APRESENTADAS NA FASE DE ANÁLISE E QUAIS SÃO APRESENTADAS NA FASE DE PROJETO?
Cada caso de uso foca-se numa característica do sistema. Para a maioria dos projetos de software isto significa que múltiplos, talvez dezenas, de casos de uso são necessários para especificar completamente um novo sistema.
O grau de conformidade de um projeto de software em particular pode influenciar o nível de detalhe requerido em cada caso de uso. É geralmente aceite que cada caso de uso seja curto o suficiente para ser implementado por um desenvolvedor de software num lançamento.
A engenharia de requisitos consiste num processo onde são identificados todos os diferentes requisitos que um sistema de software deverá satisfazer quando se encontrar funcional. Este processo recorre a diferentes técnicas, algumas delas complementares entre si. O objectivo final é obter todos os requisitos idealizados para o sistema, possivelmente classificados por ordem de importância, descritos o mais claramente possível e devidamente validados pelos interessados ou stakeholders do sistema.
A clareza com que os requisitos são descritos e a sua abrangência que é idealizada pelos stakeholder é a máxima prioridade do processo tendo em vista não só a necessidade de transição do conhecimento dos requisitos do sistema tanto para os programadores que o irão implementar quanto para os utilizadores que dele farão uso, mas também para garantir que todo o conteúdo pretendido esteja identificado antes do processo de implementação começar de modo a facilitar a arquitetura e planejamento de implementação da solução evitando retrabalho.
Entre as várias técnicas auxiliares à tarefa de levantamento de requisitos, as mais reconhecidas e aconselhadas são:
• Identificação de stakeholders: Determinação clara de quem irá usar o sistema e de quem o projetou, discernindo quais os objectivos iniciais por detrás da ideia, de modo a poder entender o que esperam que o sistema cumpra.
• Entrevistas com stakeholders do sistema: Consiste em efetuar entrevistas com os utilizadores e visionários do sistema tentando obter uma ideia das várias necessidades que o sistema deve satisfazer.
• Workshops de requisitos: Sessões de grupo com os utilizadores e visionários do sistema promovendo o debate e discussão de ideias sobre o sistema a desenvolver.
• Listagem contratual de requisitos: Consiste em elaborar uma listagem contendo todas as necessidades que o sistema deverá satisfazer.
• Prototipagem: Criação, apresentação e debate de modelos de interacção não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.
• Diagrama de Caso de Uso: Descreve a funcionalidade proposta para o novo sistema.
• Expansão de Diagrama de Casos de uso: Consiste na explicitação de todas as diferentes funcionalidades do sistema, que permitirá inferir e identificar mais claramente outras necessidades.
• Diagramas de casos de uso
Muitas pessoas introduziram os casos de uso via UML, que define uma notação gráfica para representar os casos de uso. O UML não define padrões para o formato escrito objetivando descrever casos de uso, e assim muitas pessoas compreendem erroneamente que a notação gráfica define a natureza do caso de uso; contudo a notação gráfica pode dar a visão geral mais simples de um caso de uso ou de um conjunto destes casos.
O diagrama de casos de uso fornece um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.
• Ator: Agente externo (uma pessoa ou um sistema) que interage com o sistema, dividindo-se em primário que interage diretamente e secundário que somente faz um serviço.
• Interação: Comunicação dos atores com o sistema.
• Associação entre casos de uso:
• Inclusão (Include): Um caso de uso pode ser aproveitado no contexto de outros casos de uso. Exemplo: "calcular o DV do CNPJ" é um comportamento que pode ser utilizado como mecanismo para validar a inclusão de um objeto cliente ("cadastrar cliente"), como pode ser utilizado para validar a inclusão de um objeto fornecedor ("cadastrar fornecedor"). Compartilhamento de uma ação por outras ações reutilização.
• Extensão (Extend): Um caso de uso pode ter seu comportamento requerido por outro caso de uso (e somente por este outro caso de uso). Dois motivos para a utilização do Extend: melhorar a estabilidade do modelo (i.e. redução do impacto de eventuais mudanças de comportamento) e diminuir a complexidade das operações (i.e. isolar os elementos que apresentem comportamentos mais complexos). Exemplo: "cadastrar funcionário" requer a chamada de uma operação para "cadastrar dependente do funcionário". O comportamento de "cadastrar dependente do funcionário" servirá apenas aos propósitos de "cadastrar funcionário" (i.e. não será compartilhado com outras ações). Modularização. Menor acoplamento e maior coesão.
Os atores
Ator é algo que interage com o sistema, mas sobre o qual não se tem controle. Ele está fora da influência do sistema. Os atores têm um papel externo e são quem iniciam(e quem respondem) aos casos de uso. Por exemplo: fazem o pedido num restaurante, comem, bebem ou pagam.
Tipicamente, um ator representa um papel que um ser humano, um outro processo, um outro sistema, ou até um dispositivo de hardware, desempenha ao interagir com o sistema.
Cada ator corresponde a um papel específico: uma mesma pessoa que desempenha diferentes papéis nas interações com o sistema é representada por diferentes atores; por outro lado, diversas pessoas que desempenham o mesmo papel correspondem a um único ator.
São eles quem:
• Utilizam o sistema.
• Inicializam o sistema.
• Fornecem os dados
• Usam as informações do sistema
Atributos dos Casos de Uso
Atributos obrigatórios:
• Nome
• Atores
• Objetivo
• Fluxo de eventos (cenário principal)
• Atitudes
Além destes atributos ainda podemos definir: prioridade, estado, pré-condições, pontos de extensão, identificador único, casos de uso usados, diagrama de atividade, diagrama de sequência, casos de uso subordinados, diagrama de colaboração e outros requerimentos.
BENEFÍCIOS E VANTAGENS DO CASO DE USO
A utilização de casos de uso é uma técnica relativamente recente, mais flexível apoiado num formato novo e mais ágil para capturar requisitos de software que contrasta com a documentação extensiva e "monolítica" que tenta, mas falha em registrar todos os requisitos possíveis de um sistema antes deste começar a ser construído.
Os casos de uso podem ser facilmente adicionados e removidos do projeto de software assim que as prioridades mudam. Os casos de uso podem também servir como base para estimar, escalonar e validar esforços. Uma razão porque os casos de uso se tornaram populares é que são fáceis de entender por pessoas da área de negócio, e assim provaram ser uma excelente ponte entre quem desenvolve o software e os usuários finais. Entre as vantagens da utilização no processo de engenharia de requisitos incluem-se:
• A modelagem de um caso de uso (incluindo a sua especificação) é geralmente aceita como uma excelente técnica para a captura dos requisitos funcionais de um sistema.
• Desencorajam o design prematuro.
• Podem ser usados a base para o esforço de estimação, planeamento e validação.
• São reutilizáveis dentro de um projecto. O caso de uso pode evoluir com cada interação, desde um método de levantamento de requisitos, para linhas gerais de desenvolvimento aos programadores, de um caso de teste, até a documentação.
• Caminhos alternativos de um caso de uso registram comportamentos adicionais que podem melhorar a robustez do sistema.
• São úteis para sondar o verdadeiro âmbito do sistema. Podem ser facilmente adicionados ou removidos consoante a mudança de prioridades no desenvolvimento do projecto do sistema.
• São facilmente entendidos por todos os tipos de utilizadores, criando uma ponte entre os que desenvolvem o software e os stakeholders do sistema.
• As especificações de um caso de uso não requerem a utilização de uma dada linguagem, podem ser escritos nos mais diversos estilos para encaixar com as necessidades do projecto.
• Permite descrever um requisito como se contasse uma história. Torna-se mais fácil descrever requisitos sob a forma de uma história ou cenário.
• Estão ligados diretamente com a interação do sistema, isto permite aos designers da interface um maior envolvimento no processo de desenvolvimento do projeto quer antes ou em paralelo com os programadores de software.
• Colocam os requisitos em contexto, são claramente descritos em relação às tarefas do negócio.
• Os diagramas de caso de uso ajudam os stakeholders a entender a natureza e escopo da área de negócio ou sistema em desenvolvimento.
• Diagramas de caso de uso podem ser gravados usando a notação UML e mantidos usando diferentes ferramentas CASE.
• Casos de uso e diagramas de caso de uso podem ser completamente integrados com outras hes delibera de análise e design criados usando uma ferramenta CASE para produzir requisitos, design e repositório de implementação mais completos.
4.5 EXISTE TRÊS TEMAS IMPORTANTES REFERENTES À ADMINISTRAÇÃO QUE DEVE SER LEVADO EM CONSIDERAÇÃO NA CRIAÇÃO DE UMA EMPRESA. (NO NOSSO CASO A LOCADORA): 1) HUMANIZAÇÃO; 2); RELACIONAMENTO INTERPESSOAL; E 3) ÉTICA. NA ATUALIDADE TEM-SE FALADO MUITO EM HUMANIZAÇÃO E ÉTICA NO AMBIENTE DE TRABALHO. DESCREVA-OS PARA QUE SERVE E QUAL SIGNIFICADO. PESQUISE SOBRE ESTES TEMAS NO CONTEXTO DA TECNOLOGIA.
Humanizar significa respeitar o trabalhador enquanto pessoa, enquanto ser humano. Significa valorizá-lo em razão da dignidade que lhe é intrínseca. Isso apresenta vários desdobramentos. Por exemplo, o relacionamento interpessoal1 - necessidade social. A dignidade jamais deve ser esquecida ou colocada em segundo plano. A prática da humanização deve ser observada ininterruptamente. O comportamento ético deve ser o princípio de vida da organização, uma vez que ser ético é preocupar-se com a felicidade pessoal e coletiva 1 Tem competência interpessoal quem saber ouvir o outro e colocar-se no lugar desse outro a fim de compreendê-lo.
RELACIONAMENTO INTERPESSOAL onde a empresa tem de mostrar ao colaborador que ele é necessário como profissional, e antes de qualquer As relações interpessoais tiveram como um de coisa que é um ser humano com capacidades que seus primeiros pesquisadores o psicólogo Kurt agregadas à produção da empresa, formarão uma Lewin.
“Humanização, relacionamento interpessoal e ética competência de seus membros, mas, sobretudo com imprescindível na pauta das discussões, porque, a solidariedade de suas relações interpessoais”. dentre as necessidades do homem contemporâneo, a necessidade ética desponta como uma das mais Schutz, um outro psicólogo, trata de uma teoria prementes das necessidades interpessoais: necessidade de ser aceito pelo grupo, necessidade de responsabilizar-se A intrincada teia de relacionamentos integra apela existência e manutenção do grupo, necessidade vida do ser humano, tornando inadaptável ade ser valorizado pelo grupo.
CONCLUSÃO
Em um mundo cujos problemas parecem ser agravados com o tempo, uma simplificação de seus "modelos" talvez seja bem vinda. Os bancos de dados e os servidores de Banco de dados serão definitivamente a parte principal da computação à medida que caminhamos para o século XXI. Independente de ser como extensões de banco de dados relacionais ou como produtos e empresas de SGBDOO "novéis", espera-se que uma percentagem substancial das tecnologias de SGBD seja orientada a objetos
REFERÊNCIAS
Análise de sistemas II, sistemas\Simone Sawasaki Tanaka-São Paulo: Pearson Prentice Hall, 2009.
Algoritmos e estrutura de dados; sistemas\Paulo de Tarso Deliberador-Sçao. Paulo; Pearson Pretice Hall, 2009.
Banco de dados II; sistemas\Roberto yukio nishimura;-Sçao Paulo;Pearson Prentici Hall,2009
Desenvolvimento orientado a objeto I,sistemas\Flávio de Almeida e Silva-Sçao Paulo;Pearson Prentice Hall,2009
UNIVERSIDADE FEDERAL DO PARANÁ. Biblioteca Central. Normas para apresentação de trabalhos. 2. ed. Curitiba: UFPR, 1992. v
SILVA, Flávio de Almeida e. Desenvolvimento orientado a objetos I. São Paulo. Editora Pearson, 2009.
TANAKA, Simone Sawasaki. Análise de sistemas II. São Paulo. Editora Pearson, 2009.