CURSO
ENGENHARIA INFORMÁTICA
1º SEMESTRE
Desenho de Sistemas Informáticos
Docente: Carlos Alberto Messani
2015
APRESENTAÇÃO
O DOCENTE
Carlos Alberto Messani
Graduado em Ciência da Computação (IMES/BRASIL)
Mestre em Gestão de Redes de Telecomunicações (PUC/BRASIL)
Linha de pesquisa: Redes Ópticas (Criptografia em redes
ópticas)
Artigos publicados em revistas técnicas/Científicas
Internacionais
APRESENTAÇÃO
O DOCENTE
Artigos publicados em revistas técnicas/Científicas Internacionais
Título: All-Optical Narrowband Spectral Slicing Encryption with Supergaussian
Filter.
Evento: ITS 2014 - International Telecommunications Symposium (ITS)
Título: All-Optical Phase and Delay Spectral Encoding of Signals with Advanced Modulation Formats.
Evento: ICTON (15th International Conference on Transparent Optical Networks, 2014).
Título: A New All-Optical Cryptography Technique Applied To Wdm-Compatible Dpsk Signals.
Evento: ICTON (15th International Conference on Transparent Optical Networks,
2013).
APRESENTAÇÃO
O DOCENTE
Título: Transmission of Encrypted Optical Signals in a metropolitan WDM compatible TON with
Differential Phase-shift Keying Modulation.
Evento: IMOC (International Microwave and Optoelectronics Conference,
2013, Rio
de Janeiro. Evento conjunto do 15º SBMO Simpósio Brasileiro de
Micro-ondas e
Optoeletrônica e 10º CBMag Congresso Brasileiro de
Eletromagnetismo, 2013.)
Título: All-Optical Cryptography through Spectral Amplitude and Delay Encoding.
Evento: JMO (Journal of Microwaves, Optoelectronics and Electromagnetic
Applications, 2013.)
AVALIAÇÃO
Prova
Trabalhos
Listas de exercícios
Nota 70%
Trabalhos 20%
Listas de Exercícios 10%
DÚVIDAS?
Senão, Boa Sorte!
DESENHO DE SISTEMAS INFORMÁTICOS
Introdução
Objectivos da disciplina
Capacitar o estudante para:
Reconhecer os conceitos básicos de desenho de
software
Descrever problemas de desenho através de seus
elementos fundamentais
Objectivos da disciplina
Identificar princípios de desenho de software e
explicar seus benefícios
Diferenciar desenho de baixo-nível (detalhado)
de desenho de alto-nível (arquitetural) e saber
quando aplicar cada um
Extração, Transformação e Carga
(Extract, Transform, Load – ETL)
Conceitos
O processo de ETL (Extract, Transform and Load) destina-se à
extração, transformação e carga dos dados de uma ou mais bases de
dados de origem para uma ou mais bases de dados de destino (Data
Warehouse).
O ETL envolve:
A extração de dados de fontes externas;
A transformação dos mesmos para atender às necessidades de
negócios e
A carga dos mesmos no Armazém de Dados (Data Warehouse, DW).
ETL- EXTRAÇÃO DOS DADOS
Conceitos
A extração é a primeira tarefa que deve ser realizada
durante o processo de ETL, é nela onde são extraídas as
informações relevantes dos OLTPs (Online Transaction
Processing ou Processamento de Transações em Tempo Real)
para posteriormente serem transformadas e carregadas
para o DW.
{ A conversão é necessária devido a heterogeneidade existe nas
informações oriundas desses sistemas|
“Tarefa mais simples e demorada no processo de ETL”}
ETL- EXTRAÇÃO DOS DADOS
Processo de ETL através de diferentes origens de dados
ETL- EXTRAÇÃO DOS DADOS
Conceitos
Segundo (Lane, 2005), o método de extração dos
dados pode ser Lógico ou Físico.
A Extração Lógica;
Total: A extração dos dados é feita de modo
completo, ignorando as alterações dos dados nas
fontes desde a última extração.
Incremental: Este método extrai apenas as alterações
ocorridas nos dados de origem desde a última coleta.
ETL- EXTRAÇÃO DOS DADOS
Conceitos
A Extração Física: Os dados podem ser fisicamente
extraídos por dois mecanismos.
Extração Online: Os dados são extraídos diretamente
da fonte para processamento na Staging Area, ou seja,
os dados são extraídos diretamente do sistema fonte
(Lane (2005) .
ETL- EXTRAÇÃO DOS DADOS
Conceitos
Extração Offline: Os dados são obtidos a partir de
uma área externa, que mantém a cópia dos dados de
origem. Neste caso, não é necessário um sistema
intermediário para fazer a coleta.
Exemplos de fontes externas:
Flat files;
Dump files;
Logs;
ETL- TRANSFORMAÇÃO DOS DADOS
Conceitos
A Transformação dos dados é a fase subsequente à
sua extração. Esta fase não só transforma os dados, mas
também realiza a limpeza dos
mesmos. A correção
de erros de digitação, a descoberta de violações de
integridade, a substituição de caracteres desconhecidos,
a padronização de abreviações podem ser exemplos
desta limpeza.
ETL- TRANSFORMAÇÃO DOS DADOS
No processo de transformação de dados, são aplicadas
uma série de regras ou funções aos dados extraídos,
afim de facilitar a manipulação de algumas fontes. Em
alguns casos, as seguintes transformações podem ser
necessárias:
1. Seleccionar apenas determinadas colunas para
carregar (ou nenhuma delas).
ETL- TRANSFORMAÇÃO DOS DADOS
2 - Tradução de valores codificados (se o sistema de
origem armazena 1 para sexo masculino e 2 para
feminino, mas o data warehouse armazena M para
masculino e F para feminino), também conhecido
como limpeza de dados.
3 -Junção de dados provenientes de diversas fontes.
4 - Resumo de várias linhas de dados (total de vendas
para cada loja e para cada região).
ETL- TRANSFORMAÇÃO DOS DADOS
5 - Transposição ou rotação (transformando múltiplas
colunas em múltiplas linhas ou vice-versa).
6 - Derivação de um novo valor calculado
(montante_vendas = qtde * preço_unitário, por
exemplo).
... Entre outros.
ETL- TRANSFORMAÇÃO DOS DADOS
Br
Angola
Peso
(lb)
Produtos
Peso (kg)
Produtos
USA
Produtos
Peso (oz)
C
o
n
v Peso (gr)
e
r
s
ã
o
Data
Warehouse
Produtos
ETL- CARGA DOS DADOS
O Processo de Carga ocorre posteriormente ao de
transformação. É onde os dados são carregados para o DW. A
duração deste processo depende da organização.
Oracle
Extrair
SQLServer
DB2
InterBase
Arquivos
Dados
operacionai
s
 Dados
externos

Transformar
Limpar
 Reconciliar
 Aprimorar
 Sumarizar
 Agregar

Carregar
Organizar
 Combinar
várias
fontes
 Popular sob
demanda

Data
Warehouse
FERRAMENTAS ETL
Ferramentas ETL são aplicações de software cuja
função, de modo geral, é extrair dados de diversas
fontes, transformar esses dados para garantir a
padronização e consistência das informações para
posteriormente carregá-las para um ambiente de
consulta e análise (Data Werehouse).
Tarefa para casa
Liste algumas ferramentas ETL, separando as open source
das pagas. Descreva cada uma delas.
ALGUNS CONCEITOS
Para leitura e/ou pesquisarem
OLTP (Online Transaction Processing ou Processamento De
Transações em Tempo Real)
Conceitos
São sistemas que se encarregam de registrar todas as
transações contidas em uma determinada operação
organizacional. Por exemplo: sistema de transações
bancárias que registra todas as operações efetuadas
em um banco, caixas de multibanco, reservas de viagens
ou hotel on-line, Cartões de Crédito.
OLTP (Online Transaction Processing ou Processamento De
Transações em Tempo Real)
Processamento Operacional (OLTP)
Funcionalidades do negócio
Processamento de transações: inserção, atualização,
consulta e deleção
Reflete valor corrente, não-redundante e
actualizável
Altamente voláteis
26
Processamento Analítico (OLAP)
CONCEITOS
OLAP é um conceito de interface com o usuário que
proporciona a capacidade de ter ideias
sobre os dados, permitindo analisálos profundamente em diversos ângulos. As funções
básicas do OLAP são:
Visualização multidimensional dos dados;
Exploração;
 Rotação;
Vários modos de visualização.
27
Processamento Analítico (OLAP)
CONCEITOS
Processamento Analítico (OLAP)
Suporte à tomada de decisão
Dados históricos, não voláteis, ready-only
Integram informações de diversos sistemas operacionais
Permitem identificações de perfis, tendências e padrões
{ usado para consultar dados em um DW}
CENTRO DE INFORMÁTICA - UFPE
28
Processamento Analítico (OLAP)
CONCEITOS
O OLAP e o Data Warehouse são destinados a trabalharem
juntos, enquanto o DW armazena
as informações de forma eficiente, o OLAP deve recuperál
com a mesma eficiência,porém com muita rapidez. As duas te
cnologias se complementam, ao ponto de que um Data
Warehouse para ser bem sucedido, já na sua concepção, dev
e levar em consideração o que
se deseja apresentar na interface OLAP.
29
Processamento Analítico (OLAP)
CONCEITOS
A aplicação OLAP tem como função a análise e
consolidação de dados, pois é o processamento
analítico online dos dados. Tem capacidade de
visualizações das informações a partir de perspectivas
diferentes, enquanto mantém uma estrutura de dados
adequada e eficiente. A visualização é realizada em
dados agregados, e não em dados operacionais
porque a aplicação OLAP tem por finalidade apoiar os
usuários finais a tomar decisões estratégicas.
30
Processamento Analítico (OLAP)
CONCEITOS
O OLAP é uma interface com o usuário e não uma forma de
armazenamento de dados, porém, utilizase do armazenamento para poder apresentar as informações.
Os métodos de armazenamento são:
ROLAP (OLAP Relacional):
Os dados são armazenados de forma relacional.
MOLAP (OLAP Multidimensional):
Os dados são armazenados de forma multidimensional.
31
Processamento Analítico (OLAP)
CONCEITOS
HOLAP (OLAP Híbrido):
Uma combinação dos métodos ROLAP e MOLAP
DOLAP (OLAP Desktop): conjunto de dados multidimensionais
deve ser criado no servidor e transferido para o
desktop. Permite portabilidade aos usuários OLAP que não
possuem acesso direto ao
servidor
32
Processamento Analítico (OLAP)
CONCEITOS
Os métodos mais comuns de armazenamento de dados utilizados pelos sistema
s OLAP são:
ROLAP e MOLAP, a única diferença entre eles é a tecnologia de banco de dad
os. O ROLAP
usa a tecnologia RDBMS (Relational DataBase Management System), na qual o
s dados são
armazenados em uma série de tabelas e colunas. Enquanto o MOLAP usa a tec
nologia MDDB
(MultiDimensional Database), onde os dados são armazenados em arrays
multidimensionais.
33
Processamento Analítico (OLAP)
CONCEITOS
Os dois fornecem uma base sólida para análise e apresentam tanto
vantagens quanto
desvantagens. Para se escolher entre os dois métodos devese levar em consideração os
requisitos e a abrangência do aplicativo a ser desenvolvido.
ROLAP é mais indicado para DATA WAREHOUSE pelo grande volum
e de dados, a
necessidade de um maior número de funções e diversas regras de ne
gócio a serem aplicadas.
34
Processamento Analítico (OLAP)
CONCEITOS
MOLAP é mais indidado para DATA MARTS, onde os dados são
mais específicos e o
aplicativo será direcionado na análise com dimensionalidade limitad
a e pouco detalhamento
das informações.
Para se fazer uma comparação básica entre os dois métodos, as regr
as mais importantes
são desempenho da consulta e desempenho do carregamento.
35
Processamento Analítico (OLAP)
OLTP X OLAP
OLTP
Orientados a aplicações
As Vezes de Grande tamanho
Dados granulados
Dados de pouca fontes
Suporta consultas e atualizações
Dados que mudam constantemente
Dados atuais
OLAP
Orientados a assuntos
Quase sempre grandes
Dados constituídos de sumarizações
Dados de múltiplas fontes
Atualizações em modo batch
Dados mais estáveis
Dados históricos
CENTRO DE INFORMÁTICA - UFPE
36
Processamento Analítico (OLAP)
OLTP X OLAP
37
DATA WAREHOUSE
Definição I:
“ É uma coleção de dados orientados por assuntos,
integrados, variáveis no tempo e não voláteis, para dar
suporte ao processo gerencial de tomada de decisão ”
[ Inmon ]
38
DATA WAREHOUSE
Definição II:
 “ É um processo em andamento que aglutina dados de
fontes heterogêneas, incluindo dados históricos e
dados externos para atender às necessidades de
consultas estruturadas, relatórios analíticos e de
suporte a decisão ” [Harjinder ]
39
DATA WAREHOUSE
Definição III:
 “ É uma coleção de técnicas e tecnologias que juntas
disponibilizam um enfoque pragmático e sistemático
para tratar com o problema do usuário final de
acessar informações que estão distribuídas em vários
sistemas da organização ”
[ Barquini ]
40
DADOS OPERACIONAIS VS. DATA WAREHOUSE
Características BD Operacional
Data Warehouse
Objetivo
Operações diários do negócio Analisar o negócio
Uso
Operacional
Informativo
Tipo de processamento
OLTP
OLAP
Unidade de trabalho
Inclusão, alteração, exclusão
Carga e consulta
Número de usuários
Milhares
Centenas
Tipo de usuário
Operadores
Comunidade gerencial
Interação do usuário
Somente pré-definida
Pré-definida e ad-hoc
Condições dos dados
Dados operacionais
Dados Analíticos
Volume
Megabytes - gigabytes
Gigabytes - terabytes
Histórico
60 a 90 dias
5 a 10 anos
41
DADOS OPERACIONAIS VS. DATA WAREHOUSE
Características BD Operacional
Data Warehouse
Granularidade
Detalhados
Detalhados e resumidos
Redundância
Não ocorre
Ocorre
Estrutura
Estática
Variável
Manutenção desejada
Mínima
Constante
Acesso a registros
Dezenas
Milhares
Atualização
Contínua (tempo real)
Periódica (batch)
Integridade
Transação
A cada actualização
Número de índices
Poucos / simples
Muitos / complexos
Intenção dos índices
Localizar um registro
Aperfeiçoar consultas
42
COMPONENTE DE UM DATA WAREHOUSE
Data Warehouse não é o fim, ele é um meio que as empresas dispõem
para analisar informações podendo utilizá-las para a melhoria dos
processos atuais e futuros
Qualquer fonte
Qualquer Dado
Qualquer acesso
Ferramentas
de consultas
(relatórios)
Dados
Operacionais
Dados
Externos
Ferramentas
de OLAP
Data
Warehouse
Aplicativos
43
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
44
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
45
DATA WAREHOUSE
CARACTERÍSTICAS
Orientação por assunto
 Um DW sempre armazena dados importantes sobre temas específicos da
empresa e conforme o interesse das pessoas que irão utilizá-lo.
Exemplo:
 Uma empresa pode trabalhar com vendas de produtos alimentícios no
varejo e o seu maior interesse ser o perfil de seus compradores, então o DW
será voltado para as pessoas que compram seus produtos e não para os
produtos que ela vende.
46
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
47
DATA WAREHOUSE
CARACTERÍSTICAS
Integração
Aplicação B
Aplicação A
Incompatibilidade: mesmo
elemento, nomes diferentes
Aplicação C
Incoerência: diferentes elementos,
mesmo nome
48
DATA WAREHOUSE
CARACTERÍSTICAS
Integração de dados
OPERACIONAL
Plano de Saúde
Clínica
Laboratório
de Exames
- Maria Silva
- Feminino
- 01/12/68
- Maria Silva
- Duas internações em 2000
- Equipe médica
- Duração média das
internações
- Maria Silva
- Exames requeridos
- Resultados
DATA WAREHOUSE
- Maria Silva
- Feminino
- Nascida em 01/12/68
- Duas internações em 2000
- Equipe médica
- Duração média das internações
- Exames requeridos
- Resultados dos exames
- Casada
- 2 filhos
49
DATA WAREHOUSE-CARACTERÍSTICAS
Integração de dados
OPERACIONAL
DATA WAREHOUSE
Aplicação A: m,f
Aplicação B: 1,0
Aplicação C: masculino, feminino
sexo: m, f
Aplicação A: caminho - centímetros
Aplicação B: caminho - pés
Aplicação C: caminho - jardas
Aplicação A: descrição
Aplicação B: descrição
Aplicação C: descrição
Aplicação A: chave char(10)
Aplicação B: chave dec fixed(9,2)
Aplicação C: chave char(12)
caminho:
centímetros
?
descrição
Chave
char(12)
50
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
51
DATA WAREHOUSE
CARACTERÍSTICAS
Variante no Tempo
Os DW armazenam dados por um período de tempo
de 5 a 10 anos
Refere-se a algum momento específico
 não é atualizável
No DW haverá sempre uma tabela dimensão ou fato,
cuja estrutura registrará o elemento tempo
17
DATA WAREHOUSE
CARACTERÍSTICAS
Variante no Tempo
Operacional
Maria Silva
Rua XV, 02
Medicação: X, Y
Entrada: 05/11/00
Alta: 10/11/00
Ex: Quais são
medicamentos
ministrados à
Maria Silva
neste momento?
Atômico
Maria Silva
Rua 24 horas, 12
Medicação: X, Z
Entrada: 01/03/98
Alta: 10/03/98
Maria Silva
Rua XV, 02
Medicação: X, Y
Entrada: 10/11/00
Alta: 10/11/00
Quais foram os
medicamentos
ministrados à
Maria Silva nos
últimos 5 anos?
Departamental
Janeiro 4101
Fevereiro 4209
Março 4175
Abril 4215
....
....
....
Estamos
atendendo mais
ou menos
pacientes ao
longo do tempo?
Individual
Pacientes desde
1980 tomando o
medicamento X e
com período de
internação superior
à 5 dias
Quais são os riscos
(tendências) em
relação aos
pacientes que foram
vitimas de infeção
hospitalar?
53
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
54
DATA WAREHOUSE
CARACTERÍSTICAS
Não volátil
Permite o "load-and-access”
Os dados após serem extraídos, transformados e
transportados para o DW estão disponíveis aos
usuários somente para consulta
16
DATA WAREHOUSE
CARACTERÍSTICAS
Não volátil
OPERACIONAL
DATA WAREHOUSE
incluir
alterar
acessar
carregar
excluir
acessar
excluir
incluir
alterar
56
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
57
DATA WAREHOUSE
CARACTERÍSTICAS
Localização
Formas de armazenamento:
• único local (centralizado)
• por área de interesse
(distribuído)
• por nível de detalhes
Dados altamente
resumidos
Dados levemente
resumidos
Dados detalhados
atuais
Dados detalhados
antigos
58
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
59
DATA WAREHOUSE - CARACTERÍSTICAS
Credibilidade dos dados
É o mais importante para o sucesso de
qualquer
projeto
Discrepâncias simples de todo tipo podem causar sérios
problemas quando se quer extrair dados para suportar
decisões estratégicas para o negócio das empresas;
Dados não dignos de confiança podem resultar em
relatórios inúteis, que não tem importância alguma
por exemplo, uma lista de pacientes do sexo masculino
e grávidos;
60
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
61
DATA WAREHOUSE-CARACTERÍSTICAS
Granularidade
Baixa
 é possível responder a praticamente qualquer consulta
 porém, grande quantidade de recursos computacionais
é necessária para responder perguntas específicas
Alta
 ocorre uma significativa redução da possibilidade de
utilização dos dados para atender consultas detalhadas
 porém, reduz-se muito o espaço em disco e o número de
índices necessários
62
DATA WAREHOUSE
CARACTERÍSTICAS
Exemplo de níveis de granularidade
Baixa
Prod.
A1
B1
A1
A1
Data
13/9/00
14/9/00
16/9/00
16/9/00
Qtda.
10
15
20
90
Alta
Valor
100,00
150,00
200,00
890,00
mês/ano
09/00
09/00
Prod.
A1
B1
Qtda. Valor
1201190,00
15
150,00
63
DATA WAREHOUSE- CARACTERÍSTICAS
1.
2.
3.
4.
5.
6.
7.
8.
Orientação por assunto
Integração
Variação no tempo
Não volatilidade
Localização
Credibilidade dos dados
Granularidade
Metadados
64
DATA WAREHOUSE- CARACTERÍSTICAS
Metadados
Três diferentes camadas:
 Operacionais, Centrais do Data Warehouse, nível do usuário
Três diferentes componentes:
 Mapeamento: descrevem como os dados de sistemas operacionais são
transformados antes de entrarem no DW
 Histórico: descrevem as regras corretas a serem aplicadas nos dados
corretos quando as regras de negócio mudam
 Algoritmos de sumarização: mostram a relação entre os diferentes
níveis de detalhes dos dados, indicando inclusive que nível de
sumarização é mais adequado para um dado objetivo.
65
DATA WAREHOUSE- CARACTERÍSTICAS
Metadados
O conceito metadado é considerado como sendo os "dados sobre dados",
isto é, os dados sobre os sistemas que operam com estes dados. Um
repositório de metadados é uma ferramenta essencial para o
gerenciamento de um Data Warehouse no momento de converter dados em
informações para o negócio. Entre outras coisas, um repositório de
metadados bem construído deve conter informações sobre a origem dos
dados, regras de transformação, nomes e alias, formatos de dados, etc. Ou
seja, esse "dicionário" deve conter muito mais do que as descrições de
colunas e tabelas: deve conter informações que adicionem valor aos dados.
66
DATA WAREHOUSE- CARACTERÍSTICAS
Metadados
Data marts
DATA MARTS são pontos específicos de acesso a subconjuntos
do data warehouse. Os data marts são construídos para
responder prováveis perguntas de um tipo específico de usuário.
Por exemplo: um data mart financeiro poderia armazenar
informações consolidadas dia a dia para um usuário gerencial e
em periodicidades maiores (semana, mês, ano) para um usuário
no nível da diretoria. Um data mart pode ser composto por um ou
mais cubos de dados.
67
PADRÃO ARQUITETURA EM CAMADAS
Estimula a organização da arquitetura do sistema em um
conjunto de camadas coesas com fraco acoplamento entre elas.
• Cada camada possui um propósito bem definido.
• A camada superior conhece apenas a camada imediatamente
inferior (que fornece seus serviços através de uma interface)
PADRÃO ARQUITETURA EM CAMADAS
Cada camada é formada por um conjunto de classes com um
determinado propósito.
PADRÃO ARQUITETURA EM CAMADAS
PROPÓSITO DE CADA CAMADA
UI: agrega as classes do sistema com as quais os usuários
interagem.
Negócio: mantém as classes do sistema responsáveis pelos
serviços e regras do negócio.
Dados: camada responsável pelo armazenamento e
recuperação dos dados persistentes do sistema.
Comunicação: responsável pela distribuição do sistema em
várias máquinas.
PADRÃO ARQUITETURA EM CAMADAS
VANTAGENS E DESVANTAGEM
Vantagens:
• Separação de código relativo a interface com o usuário (UI),
comunicação, negócio e dados.
• Permite a mudança de implementação de uma camada sem afetar a
outra, desde que a interface entre as mesmas seja mantida.
• Possibilita que uma camada trabalhe com diferentes versões de outra
camada.
Desvantagens
•Aumento no número de classes existentes no sistema
PADRÃO ARQUITETURA EM CAMADAS
Exemplos de diferentes configurações do padrão arquitetura
em camadas usando tecnologias Java.
PADRÃO ARQUITETURA EM CAMADAS
Arquitetura em 3 camadas
Possui as camadas: UI, Regras de Negócio e Acesso a Dados
A camada de UI: agrega as classes de fronteira
Exemplo: GUIAluno
A camada de Regras de Negócio: agrega as classes de controle e
entidade
Exemplos: ControladorAluno e Aluno
A camada de Acesso a Dados: agrega as classes de persistência
dos dados
Exemplo: RepositorioAluno
PADRÃO ARQUITETURA EM CAMADAS
ARQUITETURA EM 3 CAMADAS
Entre as camadas UI e Negócio haverá sempre uma interface
Java que uma classe Fachada do sistema implementará.
A classe Fachada é utilizada para oferecer um caminho único
para acesso aos serviços da camada de regras de negócio.
As classes da UI, portanto, comunicam-se apenas com a classe
Fachada, que por sua vez colabora com as outras classes internas
da camada de regras de negócio para oferecer os serviços
PADRÃO ARQUITETURA EM CAMADAS
ARQUITETURA EM 3 CAMADAS
O Controlador pode conter regras de controle do sistema e
delega ações da fachada para a camada de acesso a dados.
Entre as camadas Negócio e Dados haverá sempre uma interface
Java que uma classe Repositório implementará.
O Repositório armazena os objetos persistentes do sistema em
algum meio de armazenamento físico (banco de dados, arquivo,
etc.).
PADRÃO ARQUITETURA EM CAMADAS
Arquitetura em 3 camadas - Visão Arquitetural
MODEL-VIEW-CONTROLLER (MVC)
Model-view-controller
(MVC)
é
um
padrão
de
arquitetura que divide a aplicação em Controladores que
tratam as entradas dos usuários, no Modelo que prove as
funcionalidades principais, e nas Visões que mostram as
informações para os usuários.
MODEL-VIEW-CONTROLLER (MVC)
Modelo (MODEL): Lógica de negócio;
Visão (VIEW): Camada de interface com o usuário. Nesta camada o
usuário vê o estado do modelo e pode manipular a interface, para
ativar a lógica do negócio;
Controlador (CONTROLLER): Transforma eventos gerados pela
interface em ações de negócio, alterando o modelo.
MODEL-VIEW-CONTROLLER (MVC)
(continuação):
Controller (Controle): utilizado para que haja comunicação entre
a camada de View do Utilizador e a camada de Modelo do
Servidor, por exemplo:
Caso o Utilizador A tenha permissão para visualizar as
informações da Entidade B, buscar no Modelo a Entidade B e
seus atributos.
View (Visualização) camada apresentável para o usuário
contendo componentes como listas, botões, menus, etc. Utiliza a
camada de Controle para se comunicar com o Modelo.
MODEL-VIEW-CONTROLLER (MVC)
PRESENTATION-ABSTRACTION-CONTROL (PAC)
Presentation-Abstraction-Control
(PAC):
define
uma
estrutura para o sistemas na forma de uma hierarquia de
agentes cooperativos. Adequado para sistemas interativos,
onde cada agente é responsável por um aspecto
específico da funcionalidade da aplicação e é composto
por três componentes: apresentação, abstração e controle.
PRESENTATION-ABSTRACTION-CONTROL (PAC)
A parte Apresentação de um agente define sua imagem na tela
por meio de um objecto interactivo da toolkit. Esse objecto é
escolhido pela aplicação de regras ergonômicas, que são
deduzidas de recomendações ergonômicas estudadas pela
ergonomia cognitiva. Um agente pode ter várias apresentações.
Ergonomia Cognitiva: também conhecida engenharia
psicológica, refere-se aos processos mentais, tais
como percepção, atenção, cognição, controle motor e
armazenamento e recuperação de memória, como
eles afetam as interações entre seres humanos e
outros elementos de um sistema. Tópicos relevantes
incluem carga mental de trabalho, vigilância, tomada
de decisão, desempenho de habilidades, erro
humano, interação humano-computador e treinamento.
Fonte: http://pt.wikipedia.org/wiki/Ergonomia
PRESENTATION-ABSTRACTION-CONTROL (PAC)
A parte abstração de um agente corresponde a um dado ou
tarefa da aplicação. Se um agente precisa trocar dados com
a aplicação, é definido na sua parte abstração um
mecanismo que permite esta troca.
PRESENTATION-ABSTRACTION-CONTROL (PAC)
A parte do Controle é responsável por manter a coerência
entre os dados mostrados na tela (objectos interactivos) e os
dados da aplicação e por efetuar o tratamento dos eventos
do usuário sobre esses objectos.
ARQUITECTURA PIPE AND FILTER
O Padrão arquitectural Pipes and Filters oferece uma
estrutura para processamento de stream de dados. Cada
passo do processamento é encapsulado em um
componente filtro. Os dados são transportados por meio
de tubos (pipes) que estão entre filtros.
Stream pode ser definido como um fluxo
de dados em um sistema computacional
PADRÃO PIPES E FILTROS
Estrutura
Filtro: Obtém dados de entrada, Executa uma função sobre os
dados de entrada, Fornece dados de saída.
Pipe: Transfere dados, Bufferiza dados, Sincroniza componentes
Pipes
vizinhos ativos.
Qqq sdfgds bfdg
dfgsdf gvb thrt rtw
ewerty yery wert
dfghs.
Asd sdf dsf fasdfjn
df g poenig dfaf
kondfg ia oi rwei wi
Fonte de dados
Buffer (ciência da computação) - Uma região de memória
temporária utilizada para escrita e leitura de dados
Receptor de dados
Filtros
86/55
PADRÃO PIPES E FILTROS
Estrutura (cont.)
Fonte de dados
Fornece entrada para processamento no pipeline.
Receptor de dados
Consome saída.
87/55
[email protected]
1.17-Arquitectura Invocacao Inplicita(Implicit invocation)
1.19-Arquitectura Blackboard system
1.20-Arquitectura Ponto a Ponto(Peer-to-peer )
1.21-Arquitectura orientanda a servico (Service-oriented architecture)
DESENHO DETALHADO
Desenho de Software
Objectivos „
Problemas „
Qualidades „
Técnicas
DESENHO DETALHADO
Desenho de Software
Objectivos
„Desenho é o processo da passagem do espaço do problema
para o espaço da solução. À descrição da solução também se
chama desenho. „
O desenho descreve uma solução para o problema que
satisfaz os seus requisitos
note-se que muitas outras soluções satisfazendo os mesmo requisitos
são possíveis
DESENHO DETALHADO
Arquitectura e Desenho
O processo de desenho deve considerar dois aspectos:
Descrever para os clientes o que o sistema faz- Arquitectura
de Software
•Descreve as funções do sistema
•Está relacionado com os documentos de requisitos
Descrever para a equipa de desenvolvimento como o sistema
faz – Desenho de Programa
 Uma descrição dos principais algoritmos
As estruturas e os fluxos de dados
DESENHO DETALHADO
„Qualidades
Qualidades do desenho
Coesão
Ligação
Implicações„
DESENHO DETALHADO
Qualidades dos “Bons” desenhos
Intelegibilidade (understandability)
Qualidade que determina o esforço necessário para
compreender o desenho (a finalidade de cada
componente e as suas interacções).
Robustez (robustness)
Até que ponto as alterações aos componentes são
estanques (isto é, não impactam outros).
DESENHO DETALHADO
Qualidades dos “Bons” desenhos
Flexibilidade (flexibility)
Mede até que ponto se pode alterar o software com
um custo baixo.
Reutilizabilidade (reusability)
Mede até que ponto um os componentes do desenho
podem ser utilizados para outras finalidades.
DESENHO DETALHADO
Qualidades dos “Maus” desenhos
Mau
Incompreensível (incomprehensible)
A finalidade dos componentes não é compreensível
Frágil (fragile)
Alterar um componente tem implicações imprevisíveis
noutros pontos do desenho.
DESENHO DETALHADO
Qualidades dos “Maus” desenhos
Mau
Rígido (rigid)
Qualquer alteração implica um número muito grande de
ajustes
Imóvel (immutable)
A reutilização é impedida pela impossibilidade de
desacoplar um componente do resto do sistema
DESENHO DETALHADO
Independência
Qualidade que determina a capacidade de
reutilização (reusability);
A independência entre componentes é uma qualidade
do desenho que permite ainda
Entendimento
Concretização código
Concretização de testes
Adaptações
Rastreabilidade dos requisitos
DESENHO DETALHADO
Independência
Para aferir a independência entre componentes
usam-se duas medidas:
Coesão intra-componente
Ligação inter-componentes
DESENHO DETALHADO
Coesão
Medida de proximidade de componentes com
determinada finalidade
Coesão Funcional
Coesão Comunicacional
Coesão de Objecto
DESENHO DETALHADO
Coesão
Medida de proximidade de componentes com
determinada finalidade
Coesão Funcional
Coesão Comunicacional
Coesão de Objecto
DESENHO DETALHADO
Coesão Intra-Componente
Um componente é coeso se todos os seus elementos estão
envolvidos na satisfação dos objectivos do componente.
Quando não existe coesão, ao modificar uma
determinada função é necessário procurar em todos os
componentes as partes relativas à função
DESENHO DETALHADO
Coesão Intra-Componente
A coesão determina a localidade das alterações
DESENHO DETALHADO
Coesão de Objecto
Coesão = cada método e atributo é essencial para
cumprir a responsabilidade do objecto.
O Desenho com objectos promove a coesão.
DESENHO DETALHADO
Ligação
Ligação forte quando existe uma grande dependência
entre componentes;
Ligação fraca quando existe uma fraca dependência;
Desligados quando são completamente independentes;
DESENHO DETALHADO
Ligação Inter-Componentes
A ligação entre componentes depende de:
As referências entre componentes
Os dados passados entre componentes
O controlo entre componentes
O nível de complexidade da interface entre componentes
DESENHO DETALHADO
Ligação Inter-Componentes
Níveis de ligação
Ligação de conteúdo
Ligação de Partilha
Ligação de Controlo
Ligação de Estrutura
Ligação de Dados
Sem ligação
COMPLEXIDADE DE SOFTWARE
A colecção de requisições é crucial para o sucesso no
desenvolvimento de sistemas. E para realizá-los com qualidade, é
essencial que seu desenvolvimento seja de forma sistemática e
compreensível; pois ele deverá ter o que o usuário necessita e se
não o faz, provavelmente não se ajustará às suas especificações;
podendo levar à crise do software. Esta crise se manifesta através
do custo acima do planejado; da insatisfação do usuário final com
o produto; do software com defeitos e da falta de confiabilidade
no mesmo.
COMPLEXIDADE DE SOFTWARE
É importante que se entenda as medidas de complexidade na teoria,
para aplicá-las na prática, principalmente porque as pessoas lidam
com complexidade abstraindo detalhes desnecessários.
COMPLEXIDADE DE SOFTWARE
As razões que levam à complexidade do software são: Tamanho, número de
variáveis e funções; restrições de tempo; gerenciamento de memória, concorrência e
interface orientada a eventos. Assim, Booch [BOOCH90] identificou algumas
características comuns a todos os sistemas complexos:
 Existe alguma hierarquia ;
 Os componentes são mais acoplados internamente que externamente;
 Existem padrões comuns que usam componentes simples, capazes de
representar componentes complexos;
 Geralmente sistemas complexos são construídos a partir de sistemas básicos.
COMPLEXIDADE DE SOFTWARE
Complexidade de Modelos Baseados em Processos
O processo de desenvolvimento pode ser dividido em: análise, projecto
e implementação; onde a análise objectivas entender o problema
como preparação para o projecto; seguido pela modelagem do
sistema com conceitos do mundo real de uma forma que possa ser
entendido. Daí o analista interage intensamente com o requisitante, a
fim de esclarecer ambiguidades e mal entendidos.
COMPLEXIDADE DE SOFTWARE
Complexidade de Modelos Baseados em Processos
O PROJECTO é, essencialmente, um processo de refinamento e
acréscimo de detalhes, onde o projectista irá: combinar os três
modelos de análise, obter as operações sobre as classes, projectar
algoritmos para implementar tais operações, optimizar o caminho de
acesso aos dados, implementar controles para as interações externas,
ajustar a estrutura de classes para aumentar a herança, projetar
associações adequadas, determinar a representação dos objectos, e
empacotar classes e associações em módulos
PRINCÍPIOS E TÉCNICAS DE DESENHO DE SOFTWARE
Principio de Divisão e conquista
Divisão e Conquista consiste em dividir o problema a ser resolvido em
partes menores, encontrar soluções para as partes, e então combinar as
soluções obtidas em uma solução global. O uso do paradigma para resolver
problemas nos quais os subproblemas são versões menores do problema
original geralmente leva a soluções eficientes e elegantes, especialmente
quando é utilizado recursivamente” (ZIVIANI, 2007)
A Divisão e Conquista emprega modularização de programas e
frequentemente conduz a um algoritmo simples e eficiente. Esta técnica é
bastante utilizada em desenvolvimento de algoritmos paralelos, onde os
subproblemas são tipicamente independentes um dos outros, podendo assim
serem resolvidos separadamente.
PRINCÍPIOS E TÉCNICAS DE DESENHO DE SOFTWARE
Principio de Divisão e conquista
A técnica de Divisão e Conquista consistem em 3 passos:
• Divisão: dividir a instância do problema original em duas ou mais
instâncias menores, considerando-as como subproblemas.
• Conquista: resolver cada subproblema recursivamente.
• Combinação: combinar as soluções encontradas em cada subproblema,
compondo uma solução para o problema original.
PRINCÍPIOS E TÉCNICAS DE DESENHO DE SOFTWARE
Principio de Divisão e conquista
Vantagens
• Indicado para aplicações que tem restrição de tempo.
• É de fácil implementação.
• Simplifica problemas complexos.
Desvantagens
• Necessidade de memória auxiliar.
• Repetição de Subproblemas.
• Tamanho da pilha (número de chamadas recursivas e/ou armazenadas
pode causar estouro de memória).
PRINCÍPIOS E TÉCNICAS DE DESENHO DE SOFTWARE
Principio de Divisão e conquista
Algumas aplicações
• Multiplicação de inteiros longos.
• Menor distância entre pontos.
• Ordenação rápida (quicksort) e por intercalação
• Pesquisa em árvore binária.
(mergesort).
PRINCÍPIOS E TÉCNICAS DE DESENHO DE SOFTWARE
Principio de Divisão e conquista
Um exemplo para ilustrar o uso dessa técnica é o algoritmo de
ordenação de um vetor por intercalação (MergeSort). Sua
representação pode ser feita através de uma árvore binária.
ABSTRAÇÃO
ABSTRAÇÃO é o princípio de ignorar os aspectos de um assunto
não relevantes para o propósito em questão, tornando possível
uma concentração maior nos assuntos principais; selecção que um
analista faz de alguns aspectos, ignorando outros.
Tipos de abstração
•Abstração de procedimentos
•Abstração de dados
ABSTRAÇÃO
A abstração de procedimentos é uma forma de abstração usada
por analistas de requisitos, projectistas e programadores e é
caracterizada como uma abstração função/subfunção; é o
princípio de que qualquer operação com efeito bem definido
poderá ser tratada como entidade única, mesmo que a operação
seja realmente conseguida através de alguma sequência de
operações de nível mais baixo.
ABSTRAÇÃO
A abstração de dados consiste na definição de um tipo de dado
conforme as operações aplicáveis aos objetos deste tipo; assim, os
objetos podem ser modificados e observados através destas
operações. Este tipo de abstração é mais poderoso que a abstração
de procedimentos e pode ser usado como base para a organização
do pensamento e a especificação das responsabilidades de um
sistema.
Ao se aplicar uma abstração de dados, um analista define os
atributos e os serviços que manipulam exclusivamente estes atributos
que podem ser tratados como um todo intrínseco.
ABSTRAÇÃO
O programador pode usar abstração para notar que duas
funções tem tarefas comuns e podem ser combinadas em uma
simples função. É uma técnica importante em Engenharia de
Software, sendo relatada com outra técnica conhecida como
encapsulamento, que será discutida a seguir. Assim, o
programador poderá focar-se em novos objetos, sem se
preocupar com a ocultação dos detalhes.
ENCAPSULAMENTO
Encapsulamento é o agrupamento de idéias relacionadas em
uma unidade; uma técnica poderosa de programação que reduz a
complexidade e previne contra mudanças intencionais ou não de
partes do programa; agrupamento de procedimentos em torno de
ideias. Já o encapsulamento orientado a objecto é o
agrupamento de procedimentos em torno dos dados, revelando
informações e escondendo a implementação. Então, pode–se
concluir que o encapsulamento pode ser uma poderosa técnica
para domesticar a complexidade do sistema.
ENCAPSULAMENTO
Algumas vantagens do encapsulamento podem ser descritas como
a diminuição de trabalho no desenvolvimento de um novo sistema;
o agrupamento de aspectos relacionados; a minimização do fluxo
entre as diferentes partes do trabalho e a separação de certos
requisitos específicos que outras partes da especificação podem
usar.
MODULARIZAÇÃO DO PROJECTO
A modularidade contribui muito para a manutenabilidade, sendo,
então, um fator importante na prevenção de manutenção corretiva
e aperfeiçoamento do código. Sendo que sua meta é fazer cada
rotina como uma caixa preta que tem uma interface simples e uma
funcionalidade bem definida. Porém, o objectivo da perfeita
modularidade é difícil de se realizar com rotinas individuais, pois
elas não especificam perfeitamente o porque particionam os
dados com outras rotinas.
ACOPLAMENTO
Método para medir a qualidade de um projeto , ou seja, o grau
de interdependência entre os módulos. Assim, é importante
minimizar o acoplamento, indicando um sistema bem particionado.
Um baixo acoplamento entre os módulos pode ser obtido eliminando
relações desnecessárias , reduzindo o número de relações necessárias e
enfraquecendo a dependência das relações necessárias. Existem cinco tipos
de acoplamento que são:
•Acoplamento de dados, Acoplamento de Imagem, Acoplamento de
Controle, Acoplamento Comum, Acoplamento de Conteúdo, Acoplamento
patológico .
ACOPLAMENTO
Acoplamento de dados onde os módulos se comunicam por parâmetros . É a
comunicação de dados necessária entre os módulos.
Acoplamento de Imagem onde os módulos são ligados por imagem se eles
se referem à mesma estrutura de dados. Tende a expor o módulo a mais
dados do que realmente necessita, com possíveis consequências ruins.
Acoplamento de Controle onde um módulo passa para o outro um grupo de
dados que controle a lógica interna do outro. O módulo subordinado não é
uma caixa preta .
O Acoplamento de Controle às vezes está disfarçado em uma forma
denominada Acoplamento Híbrido, que pode causar problemas desastrosos
na manutenção, pois resulta na indicação de vários significados para várias
partes do domínio de um grupo de dados.
ACOPLAMENTO
Acoplamento Comum onde dois módulos se referem à mesma área de
dados. Não é aconselhável pois o excesso de uso de dados comuns degrada
a ideia de modularidade ao deixar os dados abandonarem os limites
escritos de um módulo.
Acoplamento de Conteúdo (ou Patológico)onde um módulo faz referencia
ao interior do outro. Assim, um módulo sabe o conteúdo e implementação do
outro, assim, a maioria das linguagens de alto nível não permitem este tipo
de acoplamento.
Dois módulos podem estar acoplados em mais de uma maneira, sendo então,
definidos pelo pior tipo de acoplamento que representem. Por exemplo, se
dois módulos são ligados por acoplamento de imagem e comum, a
característica deles será o acoplamento comum.
TPC
Principio de Separação de políticas da execução de
algoritmos
Principio de Separação de interfaces de suas implementações
Principio de localidade.
QUALIDADE DE SOFTWARE
O factor qualidade é um dos aspectos importantes que deve ser
levado em conta quando do desenvolvimento do software. Para isto,
é necessário que se tenha uma definição precisa do que é um
software de qualidade ou, pelo menos, quais são as propriedades
que devem caracterizar um software desenvolvido segundo os
princípios da Engenharia de Software.
QUALIDADE DE SOFTWARE
Primeiramente, é importante discutir o conceito de software de
qualidade. Segundo a Associação Francesa de Normalização,
AFNOR, a qualidade é definida como "a capacidade de um
produto ou serviço de satisfazer às necessidades dos seus usuários".
Esta definição, de certa forma, é coerente com as metas da
Engenharia de Software, particularmente quando algumas
definições são apresentadas.
É o caso das definições de Verificação e Validação introduzidas
por Boehm, que associa a estas definições as seguintes questões:
QUALIDADE DE SOFTWARE
• Verificação: "Será que o produto foi construído corretamente?"
• Validação: "Será que este é o produto que o cliente solicitou?"
O problema que surge quando se reflete em termos de qualidade
é a dificuldade em se quantificar este factor.
QUALIDADE DE SOFTWARE
Fatores de Qualidade Externos e Internos
Algumas das propriedades que poderíamos apontar de imediato
são a correção, a facilidade de uso, o desempenho, a legibilidade,
etc... Na verdade, analisando estas propriedades, é possível
organizá-las em dois grupos importantes de fatores, que vamos
denominar fatores externos e internos.
QUALIDADE DE SOFTWARE
Fatores de Qualidade Externos
Os fatores de qualidade externos, são aqueles que podem ser
detectados principalmente pelo cliente ou eventuais usuários. A
partir da observação destes fatores, o cliente pode concluir sobre a
qualidade do software, do seu ponto de vista. Enquadram-se nesta
classe fatores tais como: o desempenho, a facilidade de uso, a
correção, a confiabilidade, a extensibilidade, etc...
QUALIDADE DE SOFTWARE
Factores de Qualidade Interno
Os fatores de qualidade internos são aqueles que estão mais
relacionados à visão de um programador, particularmente aquele que
vai assumir as tarefas de manutenção do software. Nesta classe,
encontram-se
fatores
como:
modularidade,
legibilidade,
portabilidade, etc...
Não é difícil verificar que, normalmente, os fatores mais considerados
quando do desenvolvimento do software são os externos. Isto porque,
uma vez que o objetivo do desenvolvimento do software é satisfazer
ao cliente, são estes fatores que vão assumir um papel importante na
avaliação do produto (da parte do cliente, é claro!!!).
No entanto, também não é difícil concluir que são os fatores internos
que vão garantir o alcance dos fatores externos.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Correção
Robustez
Extensibilidade
Reusabilidade
Compatibilidade
Eficiência
Portabilidade
Facilidade de uso
QUALIDADE DE SOFTWARE
Factores de Qualidade
Correção
É a capacidade dos produtos de software de realizarem suas
tarefas de forma precisa, conforme definido nos requisitos e na
especificação. É um factor de suma importância em qualquer
categoria de software. Nenhum outro factor poderá compensar a
ausência de correção. Não é interessante produzir um software
extremamente desenvolvido do ponto de vista da interface homemmáquina, por exemplo, se as suas funções são executadas de forma
incorreta.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Correção
É preciso dizer, porém, que a correção é um factor mais facilmente
afirmado do que alcançado. O alcance de um nível satisfatório de
correção vai depender, principalmente, da formalização dos
requisitos do software e do uso de métodos de desenvolvimento que
explorem esta formalização.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Robustez
A robustez é a capacidade do sistema funcionar mesmo em
condições anormais. É um fator diferente da correção. Um sistema
pode ser correto sem ser robusto, ou seja, o seu funcionamento vai
ocorrer somente em determinadas condições. O aspecto mais
importante relacionado à robustez é a obtenção de um nível de
funcionamento do sistema que suporte mesmo situações que não
foram previstas na especificação dos requisitos.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Robustez
Na pior das hipóteses, é importante garantir que o software
não vai provocar consequências catastróficas em situações
anormais. Resultados esperados são que, em tais situações, o
software apresente comportamentos tais como: a sinalização da
situação anormal, a terminação "ordenada", a continuidade do
funcionamento "correto" mesmo de maneira degradada, etc...
Na literatura, estas características podem ser associadas
também ao conceito de confiabilidade.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Extensibilidade
É a facilidade com a qual se pode introduzir modificações nos
produtos de software. Todo software é considerado, em princípio,
"flexível" e, portanto, passível de modificações. No entanto, este
factor nem sempre é muito bem entendido, principalmente quando
se trata de pequenos programas.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Extensibilidade
Por outro lado, para softwares de grande porte, este fator atinge uma
importância considerável, e pode ser atingido a partir de dois critérios
importantes:
 A simplicidade de projeto, ou seja, quanto mais simples e clara a
arquitetura do software, mais facilmente as modificações poderão ser
realizadas;
 A descentralização, que implica na maior autonomia dos diferentes
componentes de software, de modo que a modificação ou a retirada de
um componente não implique numa reação em cadeia que altere todo o
comportamento do sistema, podendo inclusive introduzir erros antes
inexistentes.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Reusabilidade
É a capacidade dos produtos de software serem reutilizados,
totalmente ou em parte, para novas aplicações. A necessidade vem
da constatação de que muitos componentes de software obedecem
a um padrão comum, o que permite então que estas similaridades
possam ser exploradas para a obtenção de soluções para outras
classes de problemas.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Reusabilidade
Este fator permite, principalmente, atingir uma grande economia e
um nível de qualidade satisfatórios na produção de novos
softwares, dado que menos programa precisa ser escrito, o que
significa menos esforço e menor risco de ocorrência de erros. Isto
significa de fato que a reusabilidade pode influir em outros fatores
de qualidade importantes, tais como a correção e a robustez.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Compatibilidade
A compatibilidade corresponde à facilidade com a qual produtos
de software podem ser combinados com outros. Este é um fator
relativamente importante, dado que um produto de software é
construído (e adquirido) para trabalhar convivendo com outros
softwares. A impossibilidade de interação com outros produtos
pode ser, sem dúvida, uma característica que resultará na não
escolha do software ou no abandono de sua utilização.
QUALIDADE DE SOFTWARE
Factores de Qualidade
Compatibilidade
Os contraexemplos de compatibilidade, infelizmente, são maiores
que os exemplos, mas podemos citar, nesta classe, principalmente, a
definição de formatos de arquivos padronizados (ASCII, PostScript,
...), a padronização de estruturas de dados, a padronização de
interfaces homem-máquina (sistema do Macintosh, ambiente
Windows, ...), etc...
QUALIDADE DE SOFTWARE
Factores de Qualidade
Eficiência
A eficiência está relacionada com a utilização racional dos
recursos de hardware e de sistema operacional da plataforma
onde o software será instalado. Recursos tais como memória,
processador e co-processador, memória cache, recursos gráficos,
bibliotecas (por exemplo, primitivas de sistema operacional) devem
ser explorados de forma adequada em espaço e tempo
QUALIDADE DE SOFTWARE
Factores de Qualidade
Portabilidade
A portabilidade consiste na capacidade de um software em ser
instalado para diversos ambientes de software e hardware. Esta
nem sempre é uma característica facilmente atingida, devido
principalmente às diversidades existentes nas diferentes
plataformas em termos de processador, composição dos periféricos,
sistema operacional, etc…
QUALIDADE DE SOFTWARE
Factores de Qualidade
Eficiência
Alguns softwares, por outro lado, são construídos em diversas
versões, cada uma delas orientada para execução num ambiente
particular. Exemplos disto são alguns programas da Microsoft, como
por exemplo o pacote Microsoft Office, que existe para
plataformas Macintosh e microcomputadores compatíveis IBM
QUALIDADE DE SOFTWARE
Factores de Qualidade
Facilidade de uso
Este fator é certamente um dos mais fortemente detectados
pelos usuários do software. Atualmente, com o grande
desenvolvimento dos ambientes gráficos como Windows, XWindows e o Sistema Macintosh, a obtenção de softwares de
fácil utilização tornou-se mais frequente. A adoção de
procedimentos de auxílio em linha (help on line) é, sem dúvida,
uma grande contribuição neste sentido.
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
Apresentados alguns factores de qualidade de software, a
dificuldade que se apresenta é como medir a qualidade do
software. Ao contrário de outras disciplinas de engenharia, onde os
produtos gerados apresentam características físicas como o peso, a
altura, tensão de entrada, tolerância a erros, etc..., a medida da
qualidade do software é algo relativamente novo e alguns dos
critérios utilizados são questionáveis.
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
A possibilidade de estabelecer uma medida da qualidade é um
aspecto importante para a garantia de um produto de software
com algumas das características definidas anteriormente. A
Metrologia do Software corresponde ao conjunto de teorias e
práticas relacionadas com as medidas, a qual permite estimar o
desempenho e o custo do software, a comparação de projetos e a
fixação dos critérios de qualidade a atingir.
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
As medidas de um software podem ser as mais variadas, a
escolha da medida devendo obedecer a determinados critérios: a
pertinência da medida (interpretabilidade); o custo da medida
(percentual reduzido do custo do software); utilidade
(possibilidade de comparação de medidas).
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
As medidas de um software podem ser organizadas segundo
duas grandes categorias:
Medidas dinâmicas
Medidas estáticas
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
Medidas dinâmicas
São as medidas obtidas mediante a execução do software, como, por
exemplo, os testes, as medidas de desempenho em velocidade e
ocupação de memória, os traços, etc...
Estas medidas podem assumir um interesse relativamente grande pois
elas permitem quantificar fatores que podem implicar em retorno
econômico ou que representem informações sobre a correção do
programa; por outro lado, estas medidas só podem ser obtidas num
momento relativamente tardio do ciclo de desenvolvimento de um
software, ou seja, a partir da etapa de testes.
QUALIDADE DE SOFTWARE
A Metrologia da Qualidade do Software
Medidas estáticas
São aquelas obtidas a partir do documento fonte do software, sem a necessidade de
execução do software. Dentre as medidas estáticas, podemos destacar:
• As medidas de complexidade textual, a qual é baseada na computação do número
de operadores e do número de operandos contidos no texto do software;
• A complexidade estrutural, a qual se baseia na análise dos grafos de controle
associadas a cada componente do software;
• As medidas baseadas no texto, como o tamanho do programa, a taxa de linhas de
comentários, etc...
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
O processo de software é visto por uma sequência de atividades
que produzem uma variedade de documentos, resultando em um
programa satisfatório e executável.
Os níveis e arquitectura do processo de software é formada por:
Nível Universal: possa utilizar em qualquer projeto;
Nível Mundial: Específico para um determinado projeto;
Nível Atômico: Sequência algorítmica do projeto,
específico para as tarefas do processo.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
O desenvolvimento de software tem-se caracterizado por uma
sobreposição de atividades necessárias para especificar, projectar e
testar retorno dos resultados do software que está sendo criado.
O feedback dessa atividade nos ajuda a compreender o que é
necessário para criar um produto.
A partir do feedback obtido em experiências com protótipos, podemos
efetuar mudanças na forma e na construção conceitual Modelos de
Processos 5 do software.
O feedback possui quatro formas básicas:
Medições da entidade do software: número derivado de resultados
produzidos por processos executores;
Corretiva: erros, faltas e falhas cometidas no software;
Mudança: Modificar o software para eliminar defeitos;
Aprimoramento: Aperfeiçoar o software.
MODELOS DE PROCESSO DE SOFTWARE
Existem vários modelos de processo de software (ou
paradigmas de engenharia de Modelos de Processos 6
software).
Cada um representa uma tentativa de colocar ordem em uma
atividade inerentemente caótica.
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Sequencial Linear

Também chamado Modelo Cascata
O Modelo de Prototipação
O Modelo RAD (Rapid Application Development)
Modelos Evolutivos de Processo de Software
Modelos de Processos 7
 O Modelo Incremental
 O Modelo Espiral
 O Modelo de Montagem de Componentes
Técnicas de Quarta Geração
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Sequencial Linear
também chamado Modelo Cascata
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
 Modelo mais antigo e o mais amplamente usado da
engenharia de software
 Modelado em função do ciclo da engenharia convencional
 Requer uma abordagem sistemática, sequencial ao
desenvolvimento de software
 O resultado de uma fase se constitui na entrada da outra
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Exploração de Conceitos / Informação e Modelagem
Envolve a elicitação de requisitos do sistema, com uma
pequena quantidade de projeto e análise de alto nível;
Preocupa-se com aquilo que conhecemos
engenharia progressiva de produto de software;
como
Iniciar com um modelo conceitual de alto nível para um
sistema e prosseguir com o projeto, implementação e teste
do modelo físico do sistema.
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Análise de Requisitos de Software
O processo de elicitação dos requisitos é intensificado e
concentrado especificamente no Software.
Deve-se compreender o domínio da informação, a função,
desempenho e interfaces exigidos.
Os requisitos (para o sistema e para o software) são
documentados e revistos com o cliente
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Análise de Requisitos de Software
O processo de elicitação dos requisitos é intensificado e
concentrado especificamente no Software.
Deve-se compreender o domínio da informação, a função,
desempenho e interfaces exigidos.
Os requisitos (para o sistema e para o software) são
documentados e revistos com o cliente
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Projecto
tradução dos requisitos do software para um conjunto de
representações que podem ser avaliadas quanto à qualidade,
antes que a codificação inicie.
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Implementação
Tradução das representações do projeto para uma linguagem
“artificial” resultando em instruções executáveis pelo computador e
implementado num ambiente de trabalho.
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Testes
Concentra-se:
nos aspectos lógicos internos do software, garantindo que todas
as instruções tenham sido testadas;
nos aspectos funcionais externos, para descobrir erros e garantir
que a entrada definida produza resultados que concordem com os
esperados.
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
Manutenção
Provavelmente o software deverá sofrer mudanças depois que for
entregue ao cliente,
causas das mudanças: erros, adaptação do software para
acomodar mudanças em seu ambiente externo e exigência do cliente
para acréscimos funcionais e de desempenho.
MODELOS DE PROCESSO DE SOFTWARE
Problemas com o Modelo Cascata
Projetos reais raramente seguem o fluxo sequencial que o
modelo propõe;
Logo no início é difícil estabelecer explicitamente todos os
requisitos. No começo dos projetos sempre existe uma incerteza
natural;
O cliente deve ter paciência. Uma versão executável do software
só fica disponível numa etapa avançada do desenvolvimento (na
instalação);
Difícil identificação de sistemas legados (não acomoda a
engenharia reversa).
MODELOS DE PROCESSO DE SOFTWARE
Problemas com o Modelo Cascata
MODELOS DE PROCESSO DE SOFTWARE
O Modelo Cascata
O Modelo de processo em Cascata trouxe contribuições
importantes para o processo de desenvolvimento de software:
Imposição de disciplina, planeamento e gerenciamento,
a implementação do produto deve ser postergada até que os
objetivos tenham sido completamente entendidos;
Permite gerência do baseline, que identifica um conjunto fixo
de documentos produzidos ao longo do processo de
desenvolvimento;
Baseline: É um conceito de gerenciamento de configuração que
nos ajuda a controlar as mudanças realizadas nos itens de
configuração de uma empresa. Ao aprovarmos uma determinada
configuração, seja de hardware ou de software, estaremos criando
uma baseline. Toda vez que houver uma alteração em um item de
configuração, uma nova baseline é gerada, para fins de
comparação com a anterior e consequente aprovação (ou não) das
mudanças