Resumo - Seminários integrados em SI - aula 8

Prévia do material em texto

SEMINÁRIOS INTEGRADOS EM SISTEMA DE INFORMAÇÃO 
Aula 8
Você sabe em função de que uso de modelo no processo de desenvolvimento de software se
dá? Da necessidade de facilitar a comunicação com os usuários na obtenção das necessidades, na
formação de uma documentação, garantindo a continuidade do projeto, e também no suporte para a
equipe de desenvolvimento.
 
Sendo assim, são propostos os modelos conceituais de dados e os modelos apresentados pela
UML. Veremos cada um deles com mais detalhes.
Modelos conceituais de dados
Os modelos conceituais de dados partem da premissa que as informações representam o
ponto central de todo negócio e com isso sua importância é fundamental no sucesso de construção
do software. No início do desenvolvimento, a identificação era realizada a partir do levantamento da
lista de informações. Tais dados permeavam o negócio em estudo e, a partir desta lista, foram
definidas as regras de normalização, pois já se verificava a necessidade de minimizar redundância e
de buscar organização das informações a fim de se ter consistência e qualidade.
Portanto, normalização é o processo formal passo a passo que examina os atributos de uma
entidade, com o objetivo de evitar anomalias observadas na inclusão, exclusão e alteração de tuplas
exclusivas.
Os objetivos são os seguintes:
• Redução de redundância e inconsistências;
• Facilidade de manipulações do banco de dados;
• Facilidade de manutenção do sistema de informações;
• Dar mais estabilidade para a implementação física do banco de dados.
Exemplo: Em um sistema de vendas, quais seriam os conjuntos de informações para movimentar o
negócio? Quais seriam as informações? Podemos considerar os dados do cliente e do produto?
 
Pedido: {numero, data, CNPJ, razsoc, end, contatos*(1-3), (cód_produto, desc_produto, qt, unidade,
valor_unit, valor item, valor total)*15}
1FN – Primeira forma normal - Se todos os domínios básicos contiverem somente valores
atômicos, ou seja, se não contiver grupos repetitivos.
 
Procedimento:
• Identificar a chave primária da entidade;
• Identificar o grupo repetitivo;
• Criar uma nova entidade com a chave primária da entidade anterior e o grupo repetitivo.
Exemplo 1FN:
 
Pedido: {numero, data, CNPJ, razsoc, end, valor_total, contatos*(1-3)}
Item: {numero, cod_produto, desc_prod, qt, unidade, valor_unit, valor_item}
2FN – Segunda forma normal - Uma relação R está na 2FN se e somente se ela estiver na 1FN e
todos os atributos “não chave” forem totalmente dependentes da chave primária.
Procedimentos:
• Identificar os atributos que não são funcionalidades dependentes de toda a chave primária;
• Remover da entidade todos esses atributos identificados e criar uma nova entidade com eles.
 
Exemplo 2FN:
Pedido: {numero, data, CNPJ, razsoc, end, contatos*(1-3)}
Item: {numero, cód_prod, qt, valor item, valor_total}
Produto: {cód_prod, desc_prod, unidade, valor_unit}
3FN – Terceira forma normal - Uma relação R está na 3FN se somente estiver na 2FN e se todos
os atributos “não chave” forem dependentes, não transitivos da chave primária, ou seja, se cada
atributo for funcionalmente dependente apenas dos atributos componentes da chave primária ou se
todos os seus atributos “não chave” forem independentes entre si.
Procedimentos:
• Identificar todos os atributos que são funcionalmente dependentes de outros atributos não
chave;
• Removê-los e criar uma nova entidade com os mesmos.
Exemplo 3FN:
Pedido: {numero, data, cnpj, valor_total}
Item: {numero, cód_prod, qt, valor_item}
Produto: {cód_prod, desc_prod, unidade, valor_unit}
Empresa: {cnpj, razsoc, end}
Contatos: {cnpj, contato}
FNBC – Forma normal de Boyce-Codd:
• Para casos não cobertos na 2FN e 3FN;
• Entidade tem várias chaves candidatas;
• Estas chaves candidatas precisam ser concatenadas;
• Chaves concatenadas compartilham pelo menos um atributo comum.
Exemplo:
 
Nome_escola + num_sala + nome_professor + endereço_escola
 
Escola: {nome_escola + endereço_escola}
Sala: {nome_escola + num_sala + nome_professor}
4FN – Quarta forma normal - Uma entidade que esteja na 3FN também está na 4FN se ela não
contiver mais do que um fato multivalorado a respeito da entidade descrita.
 
Procedimentos:
• Realizar uma divisão da entidade original em duas ou mais;
• Ambas herdam a chave principal de elo;
• Cria novas entidades, concatenando as chaves anteriores.
5FN – Quinta forma normal
Quando uma relação de 4FN estará em 5FN? Quando seu conteúdo não puder ser
reconstruído (existir perda de informações) a partir das diversas relações menores que não possuam
a mesma chave primária. Trata de relacionamentos múltiplos. prática e a evolução sugerem a
construção de modelos para facilitar o entendimento e minimizar distorções. Sendo assim, em se
tratando de modelos de dados, é proposto o MER, representados nos níveis: conceitual, lógico e
físico.
Modelo conceitual 
Especifica as regras de negócio e estruturas de dados através das entidades e seus relacionamentos.
Baseia-se no nível de envolvimento do usuário, pois o objetivo é representar os aspectos do
negócio. Não envolve tecnologia.
 
Modelo lógico 
Especifica os atributos considerando as regras de normalização e integridade referencial, definindo
as chaves primárias e estrangeiras.
 
Modelo físico 
Representa a modelagem física do banco de dados, considerando as características e limitações do
banco de dados.
Qual o objetivo da modelagem de dados?
Utilizar uma forma de representação que possibilite representar os dados e os
relacionamentos entre esses dados de forma equivalente àquela da situação real a ser representada.
Ela se caracteriza pela tentativa de, através de um modelo, tentar expressar exatamente os dados e
relacionamentos identificados no mundo real. O MER representa as informações através de
conjuntos que se relacionam entre si.
UML
A UML é uma linguagem de modelagem que se associa ao processo para formar método. A
representação é desenvolvida a partir da aplicação de técnicas que, cada uma com características
próprias, atende a natureza da aplicação a ser estudada. Portanto, as técnicas possuem uma
comunicação direta e se completam. Para utilizar a UML, devemos acima de tudo quebrar
paradigmas e ter uma visão sistêmica. 
A figura abaixo apresenta os diversos modelos propostos pela UML a partir da análise de
viabilidade elaborada para o negócio.
Diagrama de caso de uso
Sua finalidade é representar a funcionalidade dos requisitos. Utilizamos a Descrição de Caso
de Uso para detalhar o requisito e conhecer os detalhes necessários para atingir o objetivo. A
descrição registra a funcionalidade lógica e é o documento comprobatório do levantamento, onde o
usuário poderá validar o entendimento. A descrição poderá ser desenvolvida de duas formas:
Descrição não Expandida e Descrição Expandida. 
Diagrama de classe
Sua finalidade é representar as informações e suas características, a associação e as
restrições. Para representação de um diagrama de classe teremos que aprender o que significa cada
elemento que o compõe, mas principalmente como identificar um objeto. Um objeto é todo
elemento que representa ou compõe algum conceito dentro de nosso projeto. O conjunto de objetos
em nosso diagrama é representado pela CLASSE.
Diagrama de Interação
O Diagrama de Interação apresenta a relação entre os objetos e a troca de mensagens que são
necessárias para efetivar a realização do comportamento. O Diagrama de Interação representa um
único caso de uso.
Mas quando ele deve ser utilizado? Quando se deseja visualizar os comportamentos utilizados pelos
vários objetos dentro do caso de uso.
 
Diagramas de interação são apresentados sob duas formas na UML,através do diagrama de
sequência e através do diagrama de colaboração. 
Diagrama de sequência
Representa a sequência lógica dos comportamentos dentro do caso de uso. Portanto a leitura
é realizada de cima para baixo e, da esquerda para direita. Dentro do mesmo Caso de Uso o
Diagrama de Sequência deve ser elaborado para o curso normal e para cada curso alternativo.
Diagrama de colaboração
Apresenta objetos e classes envolvidas no cenário e a ligação entre eles apresentando a
forma de navegação e visibilidade.
Diagrama de Estado
O Diagrama de Estado na UML é utilizado para apresentar os estados, a mudança de estado
e o processo que faz mudar o estado de um Caso de Uso ou de uma classe. Esta é mais uma técnica
para validarmos o tratamento das restrições sistêmicas impostas pelos requisitos.
Diagrama de Atividades
O diagrama de atividade permite escolher a ordem pela qual as coisas devem ser feitas, isto
é, indica meramente as regras essenciais de sequência que necessitam ser seguidas . Esse é um
aspecto fundamental para diferenciar um diagrama de atividade de um fluxograma. Fluxogramas
são limitados a processos sequenciais enquanto Diagramas de Atividade podem manipular
processos paralelos. Frequentemente, o mesmo objeto é manipulado por várias atividades
sucessivas sendo possível desenhar setas para todas as atividades pertinentes. 
E quanto à sua implementação? A arquitetura física descreve a decomposição do hardware e
software que cercam a implementação de um sistema. 
 
Na UML, aspectos de implementação física são modelados através de diagramas de implementação.
* O ponto forte do diagrama de atividade reside no fato de suportar e encorajar comportamento
paralelo, tornando-se uma boa técnica para a modelagem de fluxo de trabalho e programação para
multiprocessamento.
Exemplo de diagrama de atividades
Diagramas de componentes
Componentes modelam coisas físicas que podem residir em um nó, como: executáveis,
bibliotecas, tabelas, arquivos e documentos. Assim como na análise, para a implementação de um
software é necessário estabelecer qual a modelagem física do sistema executável. Um diagrama de
componentes mostra as dependências entre componentes de software, incluindo componentes de
código fonte, componentes de código binário e componentes executáveis. Um diagrama de
componente é um grafo de componentes conectado por relacionamentos de dependência.
Diagrama de implantação
Os diagramas de implantação são utilizados para a modelagem da visão estática de
funcionamento de um sistema. Esta visão é direcionada para a distribuição, entrega e instalação das
partes que formam o sistema físico. 
São utilizados para visualizar, especificar e documentar sistemas embutidos, cliente/servidor
e distribuídos.
 
• Envolvem a topologia do sistema, descrevendo a estrutura de hardware.
• Esses diagramas mostram a configuração de nós de processamento em tempo de execução e
os componentes que neles existem.
• Componentes que não existem em tempo de execução não aparecem nestes diagramas.
• São diagramas úteis também para a engenharia reversa.