curso engenharia informÁtica 1º semestre desenho de sistemas informáticos docente: carlos alberto...

CURSOENGENHARIA INFORMÁTICA1º SEMESTRE

Desenho de Sistemas Informáticos

Docente: Carlos Alberto Messani

2015

APRESENTAÇÃOO 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ÇÃOO DOCENTE Artigos publicados em revistas técnicas/Científicas InternacionaisTí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).

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.)

APRESENTAÇÃOO DOCENTE

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

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

Objectivos da disciplina

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 eA carga dos mesmos no Armazém de Dados (Data Warehouse, DW).

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


ConceitosSegundo (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.


ConceitosA 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) .


ConceitosExtraçã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;


ConceitosA 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).


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).


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.



Produtos

Angola

Produtos

USAProdutos

Produtos

Br Conversão

Peso (lb)

Peso (kg)

Peso (oz)

Peso (gr)

Data Warehouse

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.

ETL- CARGA DOS DADOS

SQL Server

Oracle

DB2

Arquivos

InterBase

Extrair Transformar

Carregar

Dados operacionais

Dados externos

Limpar Reconcilia

r Aprimorar Sumarizar Agregar

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 casaListe 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.

26

Processamento Operacional (OLTP)Funcionalidades do negócio Processamento de transações: inserção, atualização, consulta e deleçãoReflete valor corrente, não-redundante e actualizávelAltamente voláteis

OLTP (Online Transaction Processing ou Processamento De Transações em Tempo Real)

Kharlus

É o processamento realizado por sistemas computacionais que têm a finalidade de capturar as transações dos negócios do empreendimento e dar suporte as atividades diárias de uma empresaou corporação. OLTP (On-Line Transaction Processing - Processamento de Transações On-Line) As transações realizadas normalmente afetam um único registro de cada vez. Como os registros são atualizados continuamente, os bancos de dados operacionais armazenam pouca quantidade de dados históricos.Em conseqüência, diz-se que os dados operacionais são altamente voláteis.

27

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.

Processamento Analítico (OLAP)

Kharlus

É o processamento realizado para dar suporte à tomada de decisão. Processamento analítico, também chamado de informacional ou processamento de suporte à decisão, permite ao usuário analisar uma grande quantidade de dados, normalmente históricos, verificando problemas e situações, de modo a identificar perfis, tendências e padrões.Os sistemas analíticos não atualizam continuamente as informações, mas as mantêm como um registro específico do tempo, chamado também de instantâneos de dados (snapshot of data), acarretando, normalmente, o armazenamento de grande quantidade de dados históricos. Com isso, os dados analíticos adquirem a característica de não serem voláteis. Os bancos de dadoscorrespondentes, ao nível de usuário, são ditos somente leitura (read-only), ou seja, somente é permitido ao usuário a realização de consultas sobre os dados e não a sua atualização [POE98], servindo basicamente para a geração de relatórios [KIM98b]. Dessa forma, dependendo do projeto e o nível de detalhes do banco de dados (dados históricos diários, semanais, mensais e anuais,dentre outros), é possível analisar uma grande massa de dados e obter informações que auxiliem a comunidade de gerentes, administradores e executivos na tomada de decisões.Os bancos de dados analíticos possuem, ainda, a grande vantagem de poderem se tornar integradores das informações provenientes dos diversos sistemas operacionais, possibilitando umavisão global de toda a organização.

Centro de Informática - UFPE 28

CONCEITOS Processamento Analítico (OLAP)Suporte à tomada de decisãoDados históricos, não voláteis, ready-onlyIntegram informações de diversos sistemas operacionaisPermitem identificações de perfis, tendências e padrões

{ usado para consultar dados em um DW}


Kharlus


29

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 tecnologias se complementam, ao ponto de que um Data Warehouse para ser bem sucedido, já na sua concepção, deve levar em consideração o que se deseja apresentar na interface OLAP.


Kharlus


30

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.


Kharlus


31

CONCEITOS O OLAP é uma interface com o usuário e não uma forma de armazenamento de dados, porém, utiliza-se 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.


Kharlus


32

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


Kharlus


33

CONCEITOS Os métodos mais comuns de armazenamento de dados utilizados pelos sistemas OLAP são: ROLAP e MOLAP, a única diferença entre eles é a tecnologia de banco de dados. O ROLAP usa a tecnologia RDBMS (Relational DataBase Management System), na qual os dados são armazenados em uma série de tabelas e colunas. Enquanto o MOLAP usa a tecnologia MDDB (MultiDimensional Database), onde os dados são armazenados em arrays multidimensionais.


Kharlus


34

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 deve se levar em consideração os requisitos e a abrangência do aplicativo a ser desenvolvido. ROLAP é mais indicado para DATA WAREHOUSE pelo grande volume de dados, a necessidade de um maior número de funções e diversas regras de negócio a serem aplicadas.


Kharlus


35

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 limitada e pouco detalhamento das informações. Para se fazer uma comparação básica entre os dois métodos, as regras mais importantes são desempenho da consulta e desempenho do carregamento.


Kharlus


Centro de Informática - UFPE 36

OLTP X OLAP


OLTP OLAP Orientados a aplicações Orientados a assuntos As Vezes de Grande tamanho Quase sempre grandes Dados granulados Dados constituídos de sumarizações Dados de pouca fontes Dados de múltiplas fontes Suporta consultas e atualizações Atualizações em modo batch Dados que mudam constantemente Dados mais estáveis Dados atuais Dados históricos

Kharlus


37

OLTP X OLAPProcessamento Analítico (OLAP)

Kharlus


38

DATA WAREHOUSEDefiniçã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 ]

39

DATA WAREHOUSEDefiniçã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 ]

40

DATA WAREHOUSEDefiniçã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 ]

41

DADOS OPERACIONAIS VS. DATA WAREHOUSE

Características BD Operacional Data WarehouseObjetivo Operações diários do negócio Analisar o negócioUso Operacional InformativoTipo de processamento OLTP OLAPUnidade de trabalho Inclusão, alteração, exclusão Carga e consultaNú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-hocCondições dos dados Dados operacionais Dados AnalíticosVolume Megabytes - gigabytes Gigabytes - terabytesHistórico 60 a 90 dias 5 a 10 anos

42

DADOS OPERACIONAIS VS. DATA WAREHOUSECaracterí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

43

COMPONENTE DE UM DATA WAREHOUSE

DadosOperacionais

DadosExternos

Qualquer fonte

DataWarehouse

Qualquer Dado Qualquer acesso

Ferramentasde OLAP

Aplicativos

Ferramentasde consultas(relatórios)

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

44

DATA WAREHOUSE- CARACTERÍSTICAS1. Orientação por assunto2. Integração3. Variação no tempo4. Não volatilidade5. Localização6. Credibilidade dos dados7. Granularidade8. Metadados

45


46

DATA WAREHOUSE CARACTERÍSTICAS Orientação por assuntoUm 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.

47


DATA WAREHOUSE CARACTERÍSTICAS Integração

48

Incompatibilidade: mesmo elemento, nomes diferentes

Incoerência: diferentes elementos, mesmo nome

Aplicação A

Aplicação B

Aplicação C

DATA WAREHOUSE CARACTERÍSTICAS

49

DATA WAREHOUSEOPERACIONAL

- 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

Plano de Saúde

Clínica

Laboratório de Exames

- 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

Integração de dados

DATA WAREHOUSE-CARACTERÍSTICAS Integração de dados

50

OPERACIONAL DATA WAREHOUSEAplicação A: m,fAplicação B: 1,0Aplicação C: masculino, feminino

Aplicação A: caminho - centímetrosAplicação B: caminho - pés Aplicação C: caminho - jardas

Aplicação A: descriçãoAplicaçã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)

sexo: m, f

caminho: centímetros

Chave char(12)

?descrição

51


DATA WAREHOUSECARACTERÍSTICAS

Variante no TempoOs DW armazenam dados por um período de tempo de 5 a 10 anosRefere-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


53

Operacional

Atômico Departamental Individual

Maria SilvaRua XV, 02Medicação: X, YEntrada: 05/11/00Alta: 10/11/00

Janeiro 4101Fevereiro 4209Março 4175Abril 4215............

Pacientes desde1980 tomando o medicamento X e com período de internação superior à 5 dias

Ex: Quais são medicamentosministrados à Maria Silvaneste momento?

Quais foram osmedicamentos ministrados à Maria Silva nos últimos 5 anos?

Estamos atendendo mais ou menos pacientes ao longo do tempo?

Quais são os riscos(tendências) em relação aos pacientes que foram vitimas de infeção hospitalar?

Maria SilvaRua 24 horas, 12Medicação: X, ZEntrada: 01/03/98Alta: 10/03/98

Maria SilvaRua XV, 02Medicação: X, YEntrada: 10/11/00Alta: 10/11/00

Variante no Tempo

54


DATA WAREHOUSECARACTERÍSTICAS

Não volátilPermite 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


56

OPERACIONAL

alterarincluir

acessar

excluirincluir

alterar

excluir

DATA WAREHOUSE

carregaracessar

Não volátil

57



58

Dados detalhadosantigos

Dados detalhadosatuais

Dados levementeresumidos

Dados altamenteresumidos

Formas de armazenamento:• único local (centralizado)• por área de interesse

(distribuído)• por nível de detalhes

Localização

59


60

DATA WAREHOUSE - CARACTERÍSTICAS Credibilidade dos dadosÉ o mais importante para o sucesso de qualquer projetoDiscrepâ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 algumapor exemplo, uma lista de pacientes do sexo masculino e grávidos;

61


62

DATA WAREHOUSE-CARACTERÍSTICAS

GranularidadeBaixa é 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

63


Exemplo de níveis de granularidade

Prod. Data Qtda. ValorA1 13/9/00 10 100,00B1 14/9/00 15 150,00A1 16/9/00 20 200,00A1 16/9/00 90 890,00

mês/ano Prod. Qtda. Valor09/00 A1 120 1190,0009/00 B1 15 150,00

Baixa Alta

64


65

DATA WAREHOUSE- CARACTERÍSTICAS

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.

Metadados

66


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.

Metadados

http://pt.wikipedia.org/wiki/Metadado

67


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.

Metadados

http://pt.wikipedia.org/wiki/Data_mart

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)

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.


VANTAGENS E DESVANTAGEMVantagens: • 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

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.).

ARQUITETURA EM 3 CAMADAS


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.

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.


(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.


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.


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


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.


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

86/55

PADRÃO PIPES E FILTROS

Filtros

Pipes

Asd sdf dsf fasdfjn df g poenig dfaf kondfg ia oi

rwei wi

Qqq sdfgds bfdg dfgsdf gvb thrt rtw ewerty yery wert dfghs.

Fonte de dados Receptor de dadosBuffer (ciência da computação) - Uma região de memória temporária utilizada para escrita e leitura de dados

EstruturaFiltro: 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 vizinhos ativos.

http://pt.wikipedia.org/wiki/Buffer_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)

87/55

PADRÃO PIPES E FILTROS Estrutura (cont.)Fonte de dadosFornece entrada para processamento no pipeline.

Receptor de dadosConsome saída.

[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 SoftwareObjectivos �Problemas �Qualidades �Técnicas

DESENHO DETALHADO Desenho de SoftwareObjectivos 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 DETALHADOArquitectura e DesenhoO 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 desenhoCoesãoLigaçãoImplicações �

DESENHO DETALHADOQualidades dos “Bons” desenhosIntelegibilidade (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 DETALHADOQualidades dos “Bons” desenhosFlexibilidade (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 DETALHADOQualidades dos “Maus” desenhosMauIncompreensí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 DETALHADOQualidades dos “Maus” desenhosMauRígido (rigid)Qualquer alteração implica um número muito grande de ajustesImóvel (immutable)A reutilização é impedida pela impossibilidade de desacoplar um componente do resto do sistema

DESENHO DETALHADOIndependênciaQualidade que determina a capacidade de reutilização (reusability); A independência entre componentes é uma qualidade do desenho que permite aindaEntendimentoConcretização códigoConcretização de testesAdaptaçõesRastreabilidade dos requisitos

DESENHO DETALHADOIndependência

Para aferir a independência entre componentes usam-se duas medidas:Coesão intra-componenteLigação inter-componentes

DESENHO DETALHADOCoesãoMedida de proximidade de componentes com determinada finalidadeCoesão FuncionalCoesão ComunicacionalCoesão de Objecto

DESENHO DETALHADOCoesão Intra-ComponenteUm 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 DETALHADOCoesão Intra-ComponenteA coesão determina a localidade das alterações

DESENHO DETALHADOCoesão de ObjectoCoesão = cada método e atributo é essencial para cumprir a responsabilidade do objecto.O Desenho com objectos promove a coesão.

DESENHO DETALHADOLigaçãoLigaçã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 DETALHADOLigaçã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 DETALHADOLigação Inter-ComponentesNíveis de ligaçãoLigação de conteúdoLigação de PartilhaLigação de ControloLigação de EstruturaLigação de DadosSem 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.


É 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.


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 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 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.


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.


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).


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 (mergesort).

• Pesquisa em árvore binária.


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çõesPrincipio 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 Correção RobustezExtensibilidadeReusabilidadeCompatibilidadeEficiênciaPortabilidadeFacilidade de uso

Factores de Qualidade

QUALIDADE DE SOFTWARE 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 homem-máquina, por exemplo, se as suas funções são executadas de forma incorreta.


QUALIDADE DE SOFTWARE 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 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 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 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 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 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 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 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 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 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 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 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 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, X-Windows 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 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.

A Metrologia da Qualidade do Software

QUALIDADE DE 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 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

As medidas de um software podem ser organizadas segundo duas grandes categorias:Medidas dinâmicasMedidas estáticas


QUALIDADE DE 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 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


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 SOFTWAREO Modelo Cascata


Exploração de Conceitos / Informação e ModelagemEnvolve 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 como engenharia progressiva de produto de software;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.

O Modelo Cascata


Análise de Requisitos de SoftwareO 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

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.

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.

O Modelo Cascata


TestesConcentra-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.

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.

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).

Problemas com o Modelo Cascata

MODELOS DE PROCESSO DE SOFTWAREProblemas com o Modelo Cascata

MODELOS DE PROCESSO DE SOFTWAREO 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

curso engenharia informÁtica 1º semestre desenho de sistemas informáticos docente: carlos alberto...

Documents